Re: [IPSECKEY] new draft revision (00b)

[Rob Austein <sra+ipseckey@hactrn.net>]

At Sun, 30 Mar 2003 13:17:23 -0500, Michael Richardson wrote:
> 
> Paul Hoffman does not like the IP address represented as in-addr.arpa.
> name, and suggests that the IESG will rightfully reject that. I am just
> the editor. What does the working group think?

<hat wg-co-chair=off just-another-bozo-on-this-bus=on>

I started to say that I think this depends at least in part on why the
WG wants to have an address there (and on how well the WG explains its
reasoning), but ended up concluding that there's a better answer than
the in-addr hack no matter what we're trying to accomplish here.

Assuming no other constraints, the {in-addr,ip6}.arpa hack is just a
way of encoding an "immediate" address rather than using a DNS name.
Note that, when using a DNS name, one is free to use any DNS name at
all, including one that happens to be in the reverse tree, or that
happens to have the same as the owner name of the IPSECKEY RR itself.
Because there's nothing to forbid having an A or AAAA RRset in the
reverse tree, I tend to agree with Paul that this encoding hack isn't
going to fly.  That is, by using this encoding to represent an
immediate IP address, one turns a subset of the possible real DNS
names into magic cookies that mean something else.

There's a separate question of whether the distinction between DNS
name and address is meaningful to users of the IPSECKEY.  Is the point
of allowing both forms is to model IKE's behavior, and is the
distinction significant for the intended use?

Last, the nice thing about just using DNS names as opposed to any kind
of immediate addresses is that doing so decouples the IPSECKEY RR from
having to know how IP address are represented (A RR, AAAA RR,
foobar-du-jour RR, doesn't matter, it's just an address).

So I can see three ways to go here:

1) If plain DNS names are good enough, just drop the text about
   {in-addr,ip6}.arpa from the draft.

2) If it's important to distinguish between DNS names and IP addresses
   (eg, as a hint to IKE) but the WG wants to keep the IPSECKEY RR
   independent of the specific DNS representation of IP addresses,
   then add a one-octet field as the third octet of the RDATA, with
   semantics like:

     0 = use the DNS name for IKE
     1 = use the IP address one gets by resolving the name for IKE

   and remove the {in-addr,ip6}.arpa stuff.

3) If it's important to support immediate IP addresses in the IPSECKEY
   RR, add a one-octet field as the third octet of the RDATA, with
   semantics like:

     0 = no gateway (gateway field is zero length)
     1 = gatway field is a dns name (length implicit in DNS encoding)
     2 = gateway field is four octets of raw IPv4 address
     3 = gateway field is sixteen octets of raw IPv6 address

   and remove the {in-addr,ip6}.arpa stuff.

4) Something I haven't thought of.

In all three cases I seem to have concluded that we should drop the
{in-addr,ip6}.arpa encoding hack, because of the potential ambiguity
between the hack and a valid DNS name.  Sorry for not having spotted
this earlier.

Which of these options to take is of course up the the WG.  FWIW, my
guesses as to what the concerns would be:

- (1) & (2) have no issues that I can see unless one is so worried
  about efficiency that one wants to add DNS additional section
  processing to include the address records automatically, in which
  case expect pushback on that.  I don't think there's any real need
  for additional section processing here, it's not that much of a win.

- (3) might concern folks who don't want to see yet another piece of
  code that has to know about which kind of IP address is which.  If
  there's a strong reason why we need immediate addresses, we need to
  document it, otherwise I'd just avoid option (3).

Whichever option we take, we should document the reasons for doing so.

</hat>
-
This is the IPSECKEY@sandelman.ca list.
Email to ipseckey-request@sandelman.ca to be removed.