[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.