Subject: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Dec 2007 17:43:38 -0500

Howdy,

We just submitted an I-D for a mechanism to include the source URI information in ENUM queries, primarily targeted at including the From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup, so the ENUM server can provide a response based on that.  This is useful for performing source-based ENUM routing and filtering.

The I-D is available at:

http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt

We plan on presenting this in Philadelphia, but given the winding down of the ENUM WG we'd like to get comments now and see if there is interest in progressing this.

Thanks!

-hadriel

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Duane <[email-masked]>
Date: Wed, 12 Dec 2007 12:20:05 +1100

Hadriel Kaplan wrote:
> Howdy,
> 
> We just submitted an I-D for a mechanism to include the source URI
> information in ENUM queries, primarily targeted at including the
> From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM lookup,
> so the ENUM server can provide a response based on that.  This is useful
> for performing source-based ENUM routing and filtering.
> 

While you have focused on the implemtation in your draft, I feel there
is a number of privacy implications and you don't seemed to have covered
this subject or anything like it in your current draft.

Currently NAPTR/DNS requests, regardless if the informations is
privately or publicly accessible, has the potential for the source IP
and requested destination to be tracked in varying degrees. Source IP in
most cases will be a shared server such as an upstream provider and
depending on the time to live of DNS information may be requested by
multiple people but only having one internet request which limits the
ability for third parties to be able to identify the requester or
requesters.

This draft appears to make it trivial for a number of parties, such as
most governments and numerous commercial entities which are actively
researching ways to determine the caller. This proposal appears to make
identifying and tracking callers when they wouldn't normally be in the
call path or otherwise have access to such information.

Most if not all methods in use at present, to limit or at least reduce
unnecessary leaking of personal and organisational privacy, would fail
if source URI was included.

Such measures include, but aren't limited to, how DNS requests are sent
- via provider and other upstream server(s) or requested directly via a
local cache or using a public dns service, the number of users sharing
the same caching name server or name server path if IP links are being
monitored, the use of IP masquerading, the use of TOR or similar
anonymising services to hide the requesters public IP, the use of
encryption on VoIP packets but DNS requests/replies may not be using the
same path and as a result may not be encrypted, IP link in terms of
static or dynamic IP allocation.

-- 

Best regards,
 Duane

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 11 Dec 2007 20:45:53 -0500

The privacy issues here are central as you correctly point out. But I would
not assume that these queries are going to be used in the context of the
single root DNS. There have always been split views of the DNS and there
always will be.

The authors need to be very clear under what circumstances this class of
query is used and under what network elements actually use the query and
what are the security aspects that these queries are used in. 

Is this private ENUM implementation issue?

That said the larger issue is this document a ENUM WG or an DNSEXT document.

Upper IETF Management needs to address this issue ASAP.

However it is manifestly self evident the direction we have been going in
the ENUM WG is what is the use of RFC 3761 "technology" for a variety SIP
session related routing/signaling issues outside the general scope of
e164.arpa.

That decision has already been made with our ongoing drafts on LNP, CNAM and
trunk group data.

IMHO the document is clearly "in scope" the only issue is what WG scope is
it in.

>  -----Original Message-----
>  From: Duane [mailto:[email-masked]]
>  Sent: Tuesday, December 11, 2007 8:20 PM
>  To: Hadriel Kaplan
>  Cc: [email-masked]; Robert H. Walter; Creighton, Tom; Raja Gopal
>  Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
>  
>  Hadriel Kaplan wrote:
>  > Howdy,
>  >

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 11 Dec 2007 22:01:56 -0500

Yup, you're right, I should make that issue very explicit in the draft.  The purpose of this draft's extension is strictly for non-public ENUM use, and I should have said that (d'oh).

The requester can decide if it wants to include the extension or not, and whether to provide an anonymous URI or not.  If a device "in the network" wants to issue such a request, and has the source URI info with which to do so, then I'm afraid the government can already get that information - directly from that device.  In fact, without this extension, to perform routing for certain types of application messages, such as SIP, would instead require using SIP and sending the entire SIP request (bodies and all) to the routing service and it would get far more information than just the source URI.

-hadriel

---

From: Duane <[email-masked]>
Date: Wed, 12 Dec 2007 14:20:57 +1100

Hadriel Kaplan wrote:
> Yup, you're right, I should make that issue very explicit in the
> draft.  The purpose of this draft's extension is strictly for
> non-public ENUM use, and I should have said that (d'oh).

I acknowledged this was the case, however even for non-public only enum
use I feel privacy issues should still be mentioned, as I can almost
garentee some peers somewhere at some point in time will end up, for
what ever reasons, using the public internet to locate routing
information. Perhaps you could go so far as forbidding this explicitly
and suggesting VPN or private links or what not.

> The requester can decide if it wants to include the extension or not,
> and whether to provide an anonymous URI or not.  If a device "in the
> network" wants to issue such a request, and has the source URI info
> with which to do so, then I'm afraid the government can already get
> that information - directly from that device.  In fact, without this
> extension, to perform routing for certain types of application
> messages, such as SIP, would instead require using SIP and sending
> the entire SIP request (bodies and all) to the routing service and it
> would get far more information than just the source URI.

Actually the implications aren't limited to your own government now, all
it takes is a few misconfigurations and suddenly DNS requests are
hitting root and other name servers and sending all kinds of call meta
information to any number of providers, countries, who knows.

In any case, my primary concern is that this subject wasn't mentioned or
was brushed over as being "There are no specific security issues for
this mechanism, beyond those already applicable to DNS and ENUM." which
isn't accurate and extra care should be taken if/when using lookups and
sending more information then current/most NAPTR requests contain.

-- 

Best regards,
 Duane

---

From: Paul Erkkila <[email-masked]>
Date: Tue, 11 Dec 2007 22:53:14 -0500

I think this is interesting work in the process of rolling more SCP
functionality using ENUM as a building block.Implementations would
certainly ease the transition off of current routing methods and move us
closer to a "unified dip" model for routing. I definitely support it.

The first issue I can think of is that it _seems_ primarily targeted
towards the carrier ENUM/private peering space and might not see much
use in the open spaces.

The second issue is that I think some discussions with DNS folk about
securing the query information (and validation). At note should at least
be made of the possibility of using enumeration of the URI space to gain
access to different response data. (similar to domain/space walking).

-pee

Hadriel Kaplan wrote:
> We plan on presenting this in Philadelphia, but given the winding down
> of the ENUM WG we'd like to get comments now and see if there is
> interest in progressing this.
> 
> Thanks!
> 
>  
> 
> -hadriel
> 
>  
> 
> !DSPAM:475f12da304357515877532!
> 
> 
> ------------------------------------------------------------------------
> 
> !DSPAM:475f12da304357515877532!

---

From: Paul Erkkila <[email-masked]>
Date: Tue, 11 Dec 2007 22:54:36 -0500

-pee

---

From: Paul Erkkila <[email-masked]>
Date: Tue, 11 Dec 2007 22:53:14 -0500

-pee

---

From: Paul Erkkila <[email-masked]>
Date: Tue, 11 Dec 2007 22:54:36 -0500

-pee

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 12 Dec 2007 09:56:33 +0100

>call path or otherwise have access to such information.

Capturing this information is required by the EU
Data Retention Directive and its clones in many
other countries for VoIP use.

--tony

---

From: Paul Erkkila <[email-masked]>
Date: Wed, 12 Dec 2007 09:38:33 -0500

> other countries for VoIP use.

That doesn't really hold true for non licensed/corporate communications
in most instances (as much as some people would like that to be the
case). Taken into a public ENUM context (country sanctioned or not) the
concerns seem valid to me.

Lets say I have a border/gateway appliance in my Internet connected cave
and and my friend has one in his. Both have a DNS implementation running
on them capable of understanding this type of query, and both have a
chunk of an ENUM tree delegated to them. Shouldn't we be able to make
use of this same extra query data to make decisions and enforce policy,
while still maintaining privacy? (Use crypto/IPSEC is probably a valid
counter argument)

-pee

---

From: Paul Erkkila <[email-masked]>
Date: Wed, 12 Dec 2007 09:48:04 -0500

> for performing source-based ENUM routing and filtering.

Just to add another topic into this thread, do we think the DNS is the
appropriate place for this type of decision to be made?

There is certainly precedence if this is taken as an extension of the
DNS "views" concept. However the argument can be made that this is
better handled  by not doing it in DNS, but instead handling it at the
endpoint that pops out at the end of DDDS processing. If we ignore
re-targeting and evilbox manhandling of the messaging we need to
transmit the same information anyway correct?

I'm in the DNS camp for what it's worth, since the protocol is to my
knowledge lighter/faster and generally more efficient for these types of
stateless queries. However since this would add URI parsing and possibly
crypto elements into the mix I reserve the right to change that opinion ;).

-pee

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 12 Dec 2007 16:01:30 +0100

On 2007/12/11 23:12, Hadriel Kaplan <[email-masked]> wrote:
> From/PAI SIP/Tel URI of the SIP Request which triggered the ENUM
> lookup, so the ENUM server can provide a response based on that. This
> is useful for performing source-based ENUM routing and filtering.

I can see the motivation. As others have stated, this is not appropriate
for the public e164.arpa tree.

The DNS protocol makes some assumptions about the environment it
operates in. Caching, idempotent queries, public queries, ...
We have already layered a few additions on the base protocol, from DNS views 
(different answers for different clients), TSIG (authentication of clients)
to private roots.

With this proposal, the basic premise of DNS lookups (FQDN + RRTYPE => RRSET)
is extended once more. DNS is thus used as an almost generic lookup protocol.

Yes, the incremental change ist not that big. The question remains: 

Have we now reached the point where we should stop fiddling with the
DNS protocol and should instead look for a directory lookup protocol
which was designed from the beginning to support authenticated and
complex queries returning structured data?

As this is not for e164.arpa, but private trees instead, do you actually
need the sub-tree delegation feature of DNS/ENUM? Or is ENUM just used
as a simple query protocol into a single database?

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 12 Dec 2007 16:01:37 +0100

Hi Paul,

>concerns seem valid to me.

Article 1 of the Directive establishes the obligations of all
"...providers of publicly available electronic communications
services or of public communications networks."

Public availability rather than licensing is the operative
delimitation.  E.164 numbers by definition apply to public
telecommunication networks.  I suppose you could escape
the requirements by using your own numbering scheme
within networks not available to the public.

--tony

---

From: Paul Erkkila <[email-masked]>
Date: Wed, 12 Dec 2007 10:25:48 -0500

> complex queries returning structured data?

LDAP?

> as a simple query protocol into a single database?

Not to discount the vast deployment of DNS, but i think delegation is
one of the key draws for many implementations. Even data controlled by a
single entity can benefit from the hierarchy and scaling opportunities
that build from it.

-pee

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 12 Dec 2007 16:28:02 +0100

> within networks not available to the public.

That's not the interpretation that is operational in Austria. (at least
for similar laws; Austria has not yet implemented that directive, and
hopefully never will.)

Here, all these regulations apply only to services which are offered to
the public, in the sense of "anyone can buy service from that provider
or network". They are not seen as applicable to PBXs (and mail-servers)
run by corporations (or private persons) for the own use.

This has nothing to do with E.164 numbers (for calls) and RFC822
addresses (for mail).

/ol

---

From: Otmar Lendl <[email-masked]>
Date: Wed, 12 Dec 2007 16:45:03 +0100

> > complex queries returning structured data?

Hold your horses.

All I want here is to step back and re-evaluate whether DNS is still
the appropriate baseline protocol on top of which you want to build
your application. We're piling extension upon extension here. At some
point, the foundations will crack and we can't patch over the
limitations (or better, assumptions) of the initial design any longer.

I'm not claiming (nor ruling out) we're there yet. I did not suggest alternative protocol.

We just need to think this through. 

/ol

---

From: Paul Erkkila <[email-masked]>
Date: Wed, 12 Dec 2007 10:54:03 -0500

> We just need to think this through. 

Was just pointing out your query protocol already exists, not suggesting
we use it ;). I completely agree that re-evaluation is needed here as we
use the DNS in unique ways.

-pee

---

From: Jim Reid <[email-masked]>
Date: Wed, 12 Dec 2007 15:55:33 +0000

On Dec 12, 2007, at 15:01, Otmar Lendl wrote:

> DNS protocol

Yes. The dnsext WG has gone to sleep and may never wake up. So, for  
the moment at least, it's time to stop fiddling with the DNS protocol.

> and should instead look for a directory lookup protocol

No. There are plenty of these already: LDAP, X.500, etc, etc. Why add  
another one? It'll only be as successful as its predecessors.

---

From: Peter Koch <[email-masked]>
Date: Wed, 12 Dec 2007 17:40:56 +0100

> That said the larger issue is this document a ENUM WG or an DNSEXT document.

on a more abstract level this is the counterpart to the NSID EDNS option
that now would enable the client to identify itself.  The extension is that
the server would be allowed to change the response based on this identity.
First, this would be a massive paradigm shift (I know that "views" and
src-addr based "tricks" exist, but they live ouside the architecture),
which should, if at all, be discussed in the main WG responsible for protocol
maintenance.

Second, this "identity" transported by EDNS is hop-by-hop, where what is
obviously intended here is end-to-end. Intermediates cannot be expected
to either transparently transmit or unpack and repack this option code.

This addition to (QNAME,QTYPE,QCLASS) also does not seem to interact too
well with DNSSEC.

>  The ENUM client MUST NOT cache responses for such queries, and 
>  instead MUST treat the TTL value as zero.  Otherwise the local cache 
>  would be used for subsequent queries, even if the originating info 
>  changed, which would lead to false results.  Clearly this could be 

This, albeit an obvious restriction, would have negative side effects.

And apart from the privacy issues raised by others,

>  There are no specific security issues for this mechanism, beyond 
>  those already applicable to DNS and ENUM.  

also would need to discuss how the "URI" (or in general: the option payload)
would be authenticated and/or authorized and what the security model behind
the different "views" is.

It appears to me that not only are the saddlebags about to kill the
animal <http://www3.ietf.org/proceedings/00dec/slides/PLENARY-3/index.html>,
but in fact adding more protocol elements to ENUM (or DNS, for that matter)
only for use in "private infrastructure ENUM" scenarios urgently suggests
to revisit the applicability of the underlying infrastructure for this
use case.  Maybe it's time to replace the "ENUM" in "Infrastructure ENUM"
with another term.

-Peter

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Dec 2007 12:00:41 -0500

> From: Otmar Lendl [mailto:[email-masked]] On Behalf Of Otmar Lendl
> Sent: Wednesday, December 12, 2007 10:02 AM
>

DNS views are not an extensions to the protocol, AFAIK.  They're purely internal to the DNS server, based on who asked it a query, no?  In some ways this draft is making a view explicitly signaled.  ;)

> complex queries returning structured data?

Nope.  Several such protocols already exist and are available, if people want to use them.  DNS as a protocol still has advantages over the others.

You also make it sound like we "fiddle" with the DNS protocol constantly or consistently.  AFAIK, that hasn't been the case with respect to ENUM.  Unless you're saying new service types are extensions to the protocol itself.

> as a simple query protocol into a single database?

Both.  The sub-tree model is incredibly useful for scaling in bigger networks or handling federations/registries, and it's also the case that it sometimes is just a simple query protocol to a single DB.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 12 Dec 2007 13:05:06 -0500

Chair hat off..

It is worth noting again that this is NOT intended for e164.arpa or probably
any domain within the single root DNS. 

Adding a new protocol for this function would guarantee it would not be
used...ever.

The DNS protocols have been "fiddeled" with so long they are barely
recognizable as it is. I don't see what the problem is.

The issue of identifying where the query is coming from was an issue in my
CNAM draft. Though it did not require identification and authentication it
just as easily could have. The issue in using 3761 for CNAM queries was much
more practical. 

No vendor at this stage of ENUM deployments is ever going to put another
protocol stack in the softswitches or SMB's for this type of number
translation function. In order to deploy a working protocol to deal with a
specific use case like this you deal with the cards your dealt and in this
case again that is 3761.

Obviously people using SIP redirect for number translations don't have this
problem but we all know what the issues with SIP redirect are, for one you
get a 10X performance hit on query-response time.

The first order issue to resolve is,  does this proposal identify a
practical problem in ENUM deployments that needs to get fixed,  and IMHO the
answer to that is unquestionably YES.
 
>  Both.  The sub-tree model is incredibly useful for scaling in bigger
>  networks or handling federations/registries, and it's also the case
>  that it sometimes is just a simple query protocol to a single DB.
>  
>  -hadriel
>

---

From: "Dwight, Timothy M (Tim)" <[email-masked]>
Date: Wed, 12 Dec 2007 19:11:48 +0000

I agree with Richard as to the need.  There are many cases in which the
response to the ENUM query needs to be different, depending on "where
the query came from".  The latter phrase sometimes refers to the
caller's telephone number (e.g., in the case of selecting a PSTN gateway
to which to terminate the call, you need to determine whether calling
and called party are in the same rate center and if so, select an
ingress point to the appropriate class 5 exchange;  otherwise select an
ingress point to the long distance network) and sometimes to the
"administrative entity" from which you received the call (carriers may
have business arrangements that they need to honor, e.g., a special set
of ingress points for business partners).

Today there are products that can vary the ENUM query response based on
information not present in a standard DNS/ENUM query.  Usually they
combine an application server that supports both PSTN routing and SIP
redirect, and an ENUM server.  Sorta like this:

                      +--------------+
                      | PSTN routing |
                      | logic & DB   |
                      +--------------+
                              |
                              |     (augmented?)
+------------+ INVITE    +--------+ ENUM query      +--------+
| Call       | --------> | SIP    | --------------> | ENUM   |
| Processing |           | app    |                 | server |
| Device     | <-------- | server | <-------------- |        |
+------------+       302 +--------+   ENUM response +--------+

I suppose there must be a proprietary interface between the two; which
Hadriel's proposal might standardize.  That seems useful.

I agree that SIP redirect overhead is much higher than that of a
DNS/ENUM query.  As diagrammed above this wouldn't go away, because the
"dumb" call processing device still needs to talk to the "smart" app
server, and SIP redirect is typically the only way to do so.  However
obviously there are "smart" call processing devices that implement, or
can implement, PSTN routing logic.  In that case performance might
improve substantially.

Whether this has to be done by enhancing the DNS/ENUM query as the draft
suggests, I'm not close enough to the implementation to say.

Tim

> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Wednesday, December 12, 2007 12:05 PM
> To: 'Hadriel Kaplan'; 'Otmar Lendl'
> Cc: [email-masked]; 'Robert H. Walter'; 'Creighton, Tom'; 'Raja Gopal'
> Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt
> 
> 
> Chair hat off..
>

---

From: lconroy <[email-masked]>
Date: Wed, 12 Dec 2007 20:42:58 +0000

Hi Peter, folks,
  I agree with all of Peter's comments.
Also...
   Forget ENUM.
First, there is no such thing as an ENUM server - only a DNS server  
that acts authoritatively for domains associated (via ENUM) with E. 
164 telephone numbers.
Second, the fact that a modified ENUM client happens to be the source  
of these DNS queries is not significant to the DNS query itself, nor  
is it to the kind of response it receives.
This draft describes a general mechanism for carrying option data  
within a DNS query that MAY identify the source of that query. The  
intended reaction of a DNS server that supported this extension would  
be to select from its data based on this source identity data as well  
as the QNAME, QCLASS and QTYPE. It seems that the client is  
associated with a DNS recursive resolver, and it appears that this  
resolver partitions any local cache space cache space depending on  
the source identifying data as well as the QNAME, QCLASS and QTYPE.  
This seems to require (very) special treatment for the DNS responses,  
and this special treatment seems to be orthogonal to the QTYPE or  
QTYPE. However, it's a DNS issue, not an issue for a group that  
specifies the ENUM protocol/algorithm, Enumservices and the  
guidelines for development of Enumservices.

Considering process issues:
This draft proposes a DNS extension and requests an EDNS option code  
to be assigned for this purpose. Looking at the extension  
registration process in RFC 2671, it seems that an Informational RFC  
is all that is required for an EDNS option code to be allocated.  
However, I guess that as an extension to DNS, this would be "of  
interest" to the DNSEXT group or maybe DNSOPTS, if DNSEXT sleeps with  
the fishes.
Opinions requested - Peter?

Who's calling?
Vying as my biggest concern with this draft is authentication of the  
option data. How does one know whether the DNS user has any  
association with this data value? Authentication is not covered in  
the draft, and seems to be a REALLY REALLY hard problem using DNS.

Up there with this is the way that the draft discards name space  
partitioning as "proprietary" and requiring collusion of every  
involved party.
AFAICT, this draft needs the collusion of every involved party plus  
every intermediary DNS entity.

ISTM that "in the privacy of your own home", using a technique  
similar to ENUM but combining (say) the source number with the  
destination number would seem to require no changes to anything.  
There would seem to be little or no standardisation required, as this  
is merely a provisioning issue and so appropriate for other fora  
(maybe PEPPERMINT, possibly SPEERMINT for the use case, but agreeing  
a choice on the name space partitioning is something for other folk).

Please not in the ENUM WG - we have enough trouble using the DNS  
architecture as it is, without rewiring it (with special treatment)  
like this.

all the best,
   Lawrence

---

From: lconroy <[email-masked]>
Date: Wed, 12 Dec 2007 20:53:10 +0000

Hi Richard-without-WG-chair-hat-on, folks,
  Forgive me, but in the immortal words of Mandy Rice Davies:
    "well he would [say that], wouldn't he"?

I believe that a fair number of these units DO have LDAP interfaces -  
they will sure need
something to deal with authentication of querying user. Certainly a  
number of IMS components
do have (and use) LDAP. Whether that's wise I will leave to others,  
but they do.

However, with number portability, whatever cards you're dealt, this  
could mean different
answers for every single calling number, and each of those sets of  
answers could be large.
Is the RFID registry not enough for people?

all the best,
   Lawrence

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Dec 2007 16:39:27 -0500

> From: lconroy [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2007 3:53 PM
>

Yes, I know that some devices have LDAP interfaces (including mine for that matter).  But no, not many IMS components do - more have DIAMETER and that's what they would use if not ENUM.  Whether that's wise I will leave to others. :) But pretty much any device has ENUM, because all of them have DNS.

Regardless, authentication of a client querying DNS doesn't happen.  They get around it through other means, whether by having private or unadvertised DNS server IP addresses, or limiting who the requesters can be by IP, or whatever.  That's a problem they have to deal with for everyday ENUM use anyway.  Most service providers don't want to let just any random client query their ENUM DB's, even without this draft extension.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Dec 2007 16:56:04 -0500

Hey Lawrence,
Inline...

> Sent: Wednesday, December 12, 2007 3:43 PM
> To: Peter Koch
> Cc: [email-masked]

Ummm... you just defined the ENUM server: "a DNS server that acts authoritatively for domains associated (via ENUM) with E.164 telephone numbers".  Are you saying such devices don't exist?  I'm confused.

> is it to the kind of response it receives.

I think what you mean by this is it could be generalized to any/all DNS requests - but I think we're all in vehement agreement it doesn't make sense for the general use of DNS.  Ergo, I pointed it at ENUM (and private ENUM at that).

> However, it's a DNS issue, not an issue for a group that

Granted, it could be generalized, but I pointed it to the ENUM WG because it's trying to solve a problem found due to a specific use-case for DNS: namely ENUM.  I don't disagree it probably belongs better in DNSEXT/DNSOPTS.  The ENUM WG chair is waiting to hear back from the AD's if that's the case, I believe.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 12 Dec 2007 17:04:24 -0500

Yes exactly - it lets you do this:

                      +--------------+
                      | PSTN routing |
                      | logic & DB   |
                      +--------------+
                              |
                              |
+------------+ INVITE    +--------+ ENUM+EDNS query +--------+

OR, this:

                      +--------------+
                      | PSTN routing |
                      | logic & DB   |
                      +--------------+
                              |
                              |
+------------+ ENUM+EDNS +--------+
| Call       | --------> | ENUM   |
| Processing |           | server |
| Device     | <-------- |        |
+------------+ ENUM resp +--------+

-hadriel

> From: Dwight, Timothy M (Tim) [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2007 2:12 PM
> To: [email-masked]

---

From: [email-masked]
Date: Wed, 12 Dec 2007 17:26:37 -0500

How about a technical question?

I see in section 9: "The URI field is null-terminated, ASCII
representation of the URI."  Why is there a zero byte to mark the end
of the URI field?  Its length is already encoded in the OPTION-LENGTH
field of the RDATA name/value pair.  IIRC (and I may not), DNS
generally uses length-data format for variable length data, not an
end-marker format.

Dale

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 13 Dec 2007 10:27:23 -0500

Chair hat on ...

There has clearly been a fast and furious discussion of this draft so what
I'd like to get a sense of is two things.

A. Is the problem statement contained in this Document well understood by
the WG? Does it need more clarification?

B. Is this a problem that needs to be worked on?

I'm assuming that the authors will be incorporating some of the recent
comments into a new version.

Clearly the chairs are going to have to seek some guidance from the AD's on
how to address this document and where it properly belongs.

>  From: Hadriel Kaplan [mailto:[email-masked]]
>  Sent: Wednesday, December 12, 2007 5:04 PM
>  To: Dwight, Timothy M (Tim); [email-masked]
>  > From: Dwight, Timothy M (Tim)
>  [mailto:[email-masked]]
>  > > >  > As this is not for e164.arpa, but private trees instead, do
>  you
>  > > >  actually
>  > > >  > need the sub-tree delegation feature of DNS/ENUM? Or is ENUM
>  just
>  > > >  used

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 13 Dec 2007 10:29:27 -0500

Hmm. Yeah, that was from an earlier (not-published) version of the draft which talked about how one could possibly extend this thing in the future without breaking backwards compatibility, and used that zero byte as a backwards compatible delimiter.  But I forgot to fix that back when we removed that (ugly) idea.  We'll remove that going forward.
Thanks!

-hadriel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2007 5:27 PM
> To: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 13 Dec 2007 15:28:36 -0500

At 17:43 -0500 12/11/07, Hadriel Kaplan wrote:
http://www.ietf.org/internet-drafts/draft-kaplan-enum-source-uri-00.txt

Having read the draft and the thread that ensued I have two concerns.

One is using EDNS (Extended DNS) for what's described as an 
application-specific need.  The other is the already mentioned 
security of the data question.

I like this idea though.  The idea that it promotes is not alien to 
the operations of DNS although it is alien to the IETF architected 
version of DNS.  "Views" mentioned elsewhere is an 
implementation-specific feature of ISC's BIND but is one that is 
widely understood.  The notion of selecting an answer based on IP 
address of the querier or a signature has been floated and put into 
use.  Akamaization is a verb that has been used at times.

What might be more appropriate for an identifying mark in the EDNS 
field is a domain name[1].  DNS, when it does, can differentiate 
queriers by either an IP address, the source address, or the TSIG key 
name, which is syntactically (but not semantically) a domain name.  I 
think it is important that the identifying mark not be used as a 
domain name, I think it would be unwise to have recursive servers try 
to initiate lookups based on the identifying mark.  I am worried 
about a performance (and DoS?) hit.

A generic-to-DNS querier ID would be more acceptable in the DNS 
extended field than something specific to an application.

As far as securing the mark, I don't see any way to ever do that. 
TSIG doesn't cover the contents of the OPT record (it can't, TSIG is 
in there too) and it was the last hope.  A second OPT RR in the 
additional is not going to happen anytime soon.  But I bet that 
environments that will rely on the contents of this field will have 
other security mechanisms in place.

[1] When I had someone look over the message, he asked why I 
suggested this and the explanation is worthy of being included here.

I got the idea of using domain name syntax from the engineering 
behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The 
(secret, symmetric) key shared among two communicating parties - a 
client and server - is not present in the DNS data space yet is 
identified by a string that conforms to a domain name.

Until TSIG keys, there were no names assigned to clients in DNS 
although source  IP addresses were used in ACLs.  Today, BIND's views 
can match on IP ACLs and/or TSIG key names.  Let me stress that I 
mention BIND as an example of a DNS implementation, not as a protocol 
reference.

The significance of the name looking like a domain name but not being 
one (in the semantic sense) is meant to prevent an authoritative 
server from having to launch queries in support of answering a 
question.  Authoritative servers should never learn from the network 
as that opens a vulnerability in terms of learning poisoned data as 
well as participation in traffic abuses (like DDoS).  We don't want 
authoritative servers launching traffic for their sake and our sake.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Thu, 13 Dec 2007 18:43:24 -0500

This is an interesting concept. I tend to agree that a domain name
might be a better  key but for different reasons. In the kind of usage
I'm thinking of for infrastructure applications a specific URI
(equivalent to a calling number) is too molecular. I wouldn't want to
code to respond on what is essentially a per-calling number basis.
 
Penn Pfautz
AT&T National Access Management
+1-732-420-4962

________________________________

From: Edward Lewis [mailto:[email-masked]] 
Sent: Thursday, December 13, 2007 3:29 PM
To: Hadriel Kaplan
Cc: [email-masked]; Robert H. Walter; Creighton, Tom; Raja Gopal
Subject: Re: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

One is using EDNS (Extended DNS) for what's described as an
application-specific need.  The other is the already mentioned security
of the data question.

I like this idea though.  The idea that it promotes is not alien to the
operations of DNS although it is alien to the IETF architected version
of DNS.  "Views" mentioned elsewhere is an implementation-specific
feature of ISC's BIND but is one that is widely understood.  The notion
of selecting an answer based on IP address of the querier or a signature
has been floated and put into use.  Akamaization is a verb that has been
used at times.

What might be more appropriate for an identifying mark in the EDNS field
is a domain name[1].  DNS, when it does, can differentiate queriers by
either an IP address, the source address, or the TSIG key name, which is
syntactically (but not semantically) a domain name.  I think it is
important that the identifying mark not be used as a domain name, I
think it would be unwise to have recursive servers try to initiate
lookups based on the identifying mark.  I am worried about a performance
(and DoS?) hit.

A generic-to-DNS querier ID would be more acceptable in the DNS extended
field than something specific to an application.

As far as securing the mark, I don't see any way to ever do that.  TSIG
doesn't cover the contents of the OPT record (it can't, TSIG is in there
too) and it was the last hope.  A second OPT RR in the additional is not
going to happen anytime soon.  But I bet that environments that will
rely on the contents of this field will have other security mechanisms
in place.

[1] When I had someone look over the message, he asked why I suggested
this and the explanation is worthy of being included here.

I got the idea of using domain name syntax from the engineering behind
TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret,
symmetric) key shared among two communicating parties - a client and
server - is not present in the DNS data space yet is identified by a
string that conforms to a domain name.

Until TSIG keys, there were no names assigned to clients in DNS although
source  IP addresses were used in ACLs.  Today, BIND's views can match
on IP ACLs and/or TSIG key names.  Let me stress that I mention BIND as
an example of a DNS implementation, not as a protocol reference.

The significance of the name looking like a domain name but not being
one (in the semantic sense) is meant to prevent an authoritative server
from having to launch queries in support of answering a question.
Authoritative servers should never learn from the network as that opens
a vulnerability in terms of learning poisoned data as well as
participation in traffic abuses (like DDoS).  We don't want
authoritative servers launching traffic for their sake and our sake.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-
Edward Lewis
+1-571-434-5468
NeuStar

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 10:49:14 -0500

Interesting idea.  I assume you realize such a format could be used for calling number source info as well, simply by formatting the calling number in the ENUM notation:
2.1.2.1.5.5.5.1.8.7.1.e164.mydomain
Or some such.

But the idea of the source-URI info was not to limit it to domains only.  The ENUM server could well look at only the domain portion of the URI, or it could look at the username, or the scheme, or a uri-parameter, or whatever.  The client is merely giving it extra information (of its choosing), which the server can ignore or not.  Clearly that makes it a very private (closed environment) concept, for it to really work.

-hadriel

Cc: [email-masked]; Robert H. Walter; Creighton,Tom; Raja Gopal

One is using EDNS (Extended DNS) for what's described as an application-specific need.  The other is the already mentioned security of the data question.

I like this idea though.  The idea that it promotes is not alien to the operations of DNS although it is alien to the IETF architected version of DNS.  "Views" mentioned elsewhere is an implementation-specific feature of ISC's BIND but is one that is widely understood.  The notion of selecting an answer based on IP address of the querier or a signature has been floated and put into use.  Akamaization is a verb that has been used at times.

What might be more appropriate for an identifying mark in the EDNS field is a domain name[1].  DNS, when it does, can differentiate queriers by either an IP address, the source address, or the TSIG key name, which is syntactically (but not semantically) a domain name.  I think it is important that the identifying mark not be used as a domain name, I think it would be unwise to have recursive servers try to initiate lookups based on the identifying mark.  I am worried about a performance (and DoS?) hit.

A generic-to-DNS querier ID would be more acceptable in the DNS extended field than something specific to an application.

As far as securing the mark, I don't see any way to ever do that.  TSIG doesn't cover the contents of the OPT record (it can't, TSIG is in there too) and it was the last hope.  A second OPT RR in the additional is not going to happen anytime soon.  But I bet that environments that will rely on the contents of this field will have other security mechanisms in place.

[1] When I had someone look over the message, he asked why I suggested this and the explanation is worthy of being included here.

I got the idea of using domain name syntax from the engineering behind TSIG [ftp://ftp.rfc-editor.org/in-notes/rfc2845.txt].  The (secret, symmetric) key shared among two communicating parties - a client and server - is not present in the DNS data space yet is identified by a string that conforms to a domain name.

Until TSIG keys, there were no names assigned to clients in DNS although source  IP addresses were used in ACLs.  Today, BIND's views can match on IP ACLs and/or TSIG key names.  Let me stress that I mention BIND as an example of a DNS implementation, not as a protocol reference.

The significance of the name looking like a domain name but not being one (in the semantic sense) is meant to prevent an authoritative server from having to launch queries in support of answering a question.  Authoritative servers should never learn from the network as that opens a vulnerability in terms of learning poisoned data as well as participation in traffic abuses (like DDoS).  We don't want authoritative servers launching traffic for their sake and our sake.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 10:54:40 -0500

As a URI, it typically has a domain in it and you could always choose to look at that part only on the ENUM server, or look at it and only a portion of the username, or whatever you want.  So your server-side coding would only look at what you/it wants to look at.
-hadriel

________________________________
From: PFAUTZ, PENN L, ATTCORP [mailto:[email-masked]]
Sent: Thursday, December 13, 2007 6:43 PM
To: Edward Lewis; Hadriel Kaplan
Cc: [email-masked]; Robert H. Walter; Creighton, Tom; Raja Gopal
Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

This is an interesting concept. I tend to agree that a domain name  might be a better  key but for different reasons. In the kind of usage I'm thinking of for infrastructure applications a specific URI (equivalent to a calling number) is too molecular. I wouldn't want to code to respond on what is essentially a per-calling number basis.

Penn Pfautz

---

From: Edward Lewis <[email-masked]>
Date: Fri, 14 Dec 2007 18:07:11 -0500

The problem with URI's is that if they are the payload of an EDNS 
field then you are running into something like a layer violation. 
(URI's have domain names in them, so I don't want/recommend URI's in 
the DNS packet.)  It's not that I want domains in the payload, it's 
something that is syntactically the same as a domain name.

How the payload is interpreted is up to the end points of the 
message.  Like TSIG keys, which are entered into a DNS server via 
configuration (not via zonefiles).  In my use of TSIG I would encode 
some means of identifying the endpoints and the desired expiration 
date of the key.  So a key name might be "myorg-slave3.12.31.2005." 
In your use case, you could put the URI information into the payload.

Hope that makes things a bit clearer.

At 10:49 -0500 12/14/07, Hadriel Kaplan wrote:
Interesting idea.  I assume you realize such a format could be used 
for calling number source info as well, simply by formatting the 
calling number in the ENUM notation:
2.1.2.1.5.5.5.1.8.7.1.e164.mydomain
Or some such.

But the idea of the source-URI info was not to limit it to domains 
only.  The ENUM server could well look at only the domain portion of 
the URI, or it could look at the username, or the scheme, or a 
uri-parameter, or whatever.  The client is merely giving it extra 
information (of its choosing), which the server can ignore or not. 
Clearly that makes it a very private (closed environment) concept, 
for it to really work.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 14 Dec 2007 20:21:19 -0500

Right, but what limits me from just saying "they're syntactically like URIs but not semantically".  For example, one can't de-reference them.
-hadriel

________________________________
From: Edward Lewis [mailto:[email-masked]]
Sent: Friday, December 14, 2007 6:07 PM
To: Hadriel Kaplan
Cc: Edward Lewis; [email-masked]; Robert H. Walter; Creighton,Tom; Raja Gopal
Subject: RE: [Enum] New I-D:draft-kaplan-enum-source-uri-00.txt

The problem with URI's is that if they are the payload of an EDNS field then you are running into something like a layer violation.  (URI's have domain names in them, so I don't want/recommend URI's in the DNS packet.)  It's not that I want domains in the payload, it's something that is syntactically the same as a domain name.

How the payload is interpreted is up to the end points of the message.  Like TSIG keys, which are entered into a DNS server via configuration (not via zonefiles).  In my use of TSIG I would encode some means of identifying the endpoints and the desired expiration date of the key.  So a key name might be "myorg-slave3.12.31.2005."  In your use case, you could put the URI information into the payload.

-hadriel