RE: New I-D:draft-kaplan-enum-source-uri-00.txt
Hadriel Kaplan <[email protected]>
| Newsgroups | gmane.ietf.enum |
|---|---|
| Message-ID | <[email protected]> |
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. _______________________________________________ enum mailing list [email protected] https://www1.ietf.org/mailman/listinfo/enum