[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IPSECKEY] new draft revision (00b)
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Rob" == Rob Austein <sra+ipseckey@hactrn.net> writes:
Rob> Last, the nice thing about just using DNS names as opposed to any
Rob> kind of immediate addresses is that doing so decouples the IPSECKEY
Rob> RR from having to know how IP address are represented (A RR, AAAA
Rob> RR, foobar-du-jour RR, doesn't matter, it's just an address).
This was a major part of the reasoning behind the current version.
Rob> 1) If plain DNS names are good enough, just drop the text about
Rob> {in-addr,ip6}.arpa from the draft.
They are not. The literal/immediate IP address is there to avoid a round
trip. It's presence also means that no statements about trust in the forward
need exist.
So, if anything is "expendable", it is the FQDN.
Rob> 2) If it's important to distinguish between DNS names and IP
Rob> addresses (eg, as a hint to IKE) but the WG wants to keep the
Rob> IPSECKEY RR independent of the specific DNS representation of IP
Rob> addresses, then add a one-octet field as the third octet of the
Rob> RDATA, with semantics like:
Rob> 0 = use the DNS name for IKE 1 = use the IP address one gets by
Rob> resolving the name for IKE
I.e. leave the format there but disambiguate it.
Rob> 3) If it's important to support immediate IP addresses in the
Rob> IPSECKEY RR, add a one-octet field as the third octet of the RDATA,
Rob> with semantics like:
This is essentially what the richardson-01 document said.
Rob> Which of these options to take is of course up the the WG. FWIW, my
Rob> guesses as to what the concerns would be:
Rob> - (1) & (2) have no issues that I can see unless one is so worried
Rob> about efficiency that one wants to add DNS additional section
Rob> processing to include the address records automatically, in which
Rob> case expect pushback on that. I don't think there's any real need
Rob> for additional section processing here, it's not that much of a win.
Aside from the pushback, the odds of the A/AAAA record being in the same
zone are, in my opinion, low.
Rob> - (3) might concern folks who don't want to see yet another piece of
Rob> code that has to know about which kind of IP address is which. If
Rob> there's a strong reason why we need immediate addresses, we need to
Rob> document it, otherwise I'd just avoid option (3).
Rob> Whichever option we take, we should document the reasons for doing
Rob> so.
Agreed.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPoiSSIqHRg3pndX9AQHuSQQA6pdph7IxgNvvtLIReE8TDrx2TC8UzlMq
HZ5NqIDJyYRuAROnkqnmTnCeBtskfyWkF09q4GC4Hd2lA9KbJpabhM8KWDOS0LaA
Y3bCrAfaZvU4XYY0W9oDASj8XsaqRYuA76foFus3K9t4lrPu/nuk7+B5aOnmQm9g
5666TTl507s=
=4Ymb
-----END PGP SIGNATURE-----
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.