RE: 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
AT&T National Access Management
+1-732-420-4962
 

________________________________

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