Date: Mon, 18 Dec 2000 22:54:47 -0500
From: "Donald E. Eastlake 3rd" <dee3(_at_)torque(_dot_)pothole(_dot_)com>
If DNSSEC were deployed, I see no reason why SAs could not be
bound to domain names.
I disagree. IPSEC is about Security at the IP layer, and that means we
need a security association which is tied to an object which is
addressable at the IP layer --- an IP address.
A DNS name doesn't qualify; a single DNS name can resolve to many
different IP addresses, potentially representing multiple different
hosts. Some people do this for load-balancing purposes (to Randy Bushes
infinite digust, but this is the reality).
Also, riddle me this: What host is addressed by the DNS name
a456.g.akamai.net? For me at home, it happens to be 207.87.18.169.
Except when I'm logged into MIT, when it's *either* 18.7.0.12 *or*
18.7.0.10. Betcha it's different for you. :-)
When you add to this the problem that forwards and reverse name
resolution are not always the same, and that sometimes the in-addr names
don't even exist (for example, at the IETF terminal room in San Diego
initially), I believe that trying to use DNS names for SA binding just
isn't going to work in real life.
Kerberos tried to deal with this problem by talking about "canonical
domain name", which it tried to define as being the name that you got
when you took a DNS name, forward resolved it to get an A address, and
then reverse-resolved it to get a DNS name. But this didn't work in
many cases, sometimes we got back an unqualified name, and in many cases
this scheme totally failed due to load balancing DNS servers, etc. I
suspect the reason is that as our domain name friends would tell us,
there is no such thing as a "canonical domain name" for a host.
Kerberos tried to invent such a concept, but it didn't work all that
well. I would much rather have some real IP-level endpoint identifier.
If that's what we're securing, that's what we should be using.
- Ted