RE: 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.

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

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.


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

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