Subject: RE: [Hipsec] WGLC draft-ietf-hip-dns-03.txt

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 6 Nov 2005 14:31:33 -0800

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Monday, October 24, 2005 5:36 AM
> To: HIP
> Cc: Julien Laganier
> Subject: Re: [Hipsec] WGLC draft-ietf-hip-dns-03.txt
> 
> While being an author of the draft and therefore considering 
> the draft pretty good, I'd like to get the WG's opinion on a 
> few issues on the draft:
> 
> 1. Is the introduction too long?  Would it be desirable to 
> cut some text from there, and if yes, what?

I don't think that paragraphs 2-7 (until you reach the paragraph
beginning "Currently, ...") are necessary

> 
> 2. Is the approach right?
> 
> Might it be better, for example, to define just a single new 
> RR, which would contain the HIT, HI, and RVS domain name?  
> Given the current design, the resolve needs to send DNS 
> queries for A, AAAA, HIPHI and HIPRVS in order to get all 
> data it needs.  With the alternative design, it would first 
> ask for HIPHI, and then based on whether there is an RVS 
> name, A and/or AAAA of either the host itself or its RVS server.

I would prefer fewer lookups and fewer round trip times.  It seems
possible that several lookups might be needed in cases involving RVS.
The alternative you mention seems like it could be better performing, at
the expense of a more complicated record.

As it presently reads, a querying host receiving the HIPHI does not know
whether the responder also has a HIPRVS that needs to be fetched; it
seems like HIPRVS always needs to be fetched anyway, just to make sure.
I was thinking that a flag in the HIPHI, denoting whether HIPRVS exists,
could be useful, but it may be better just to combine HIPHI and HIPRVS
records, such as something like:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Record type   |   PK algorithm|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             HIT               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                          Public Key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  preference   |     type      |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      rendezvous server        |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where "record type" can denote whether a RVS is appended after the
public key, and "PK algorithm" can be used to infer the HIT and public
key lengths.

> 
> 3. Are the details fine?
> 
> 4. Is there something unnecessary (beyond the introduction), 
> something that should be left out?
> 
> --Pekka
> 

The abbreviation ULP should be spelled out at the first occurrence.

Strictly speaking, all ULPs are not agnostic to IP address changes
(congestion control protocols, for example).  (this is stated in Section
3).

In section 6.1, s/HPIHI/HIPHI

Jeff raised an interesting question, whether the thrust of this draft
should be in providing DNS->HI or DNS->HIT lookup.  I think that section
8.5 addresses this question-- it is probably OK for now to trust the
HIT/HI binding, but perhaps not always in the future.

Tom

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 7 Nov 2005 13:09:45 -0800

> beginning "Currently, ...") are necessary

Agreed.  That was more or less what I was thinking myself, but I  
wanted to get a second independent opinion.

> the expense of a more complicated record.

I concur.

> records,

Again, I agree.

> such as something like:

I am not quite sure about this particular design; more thinking seems  
to be needed.  For example, with this there is no easy way for having  
multiple RVS with different preferences.  It may also become slightly  
harder to associate a DNS name with several HITs, depending on the  
exact semantics.  It may also be better to be explicit about the HIT  
and PK length, leaving less ambiguity.

If we embed RVS information to HIPHI, might it be better to include  
there always a domain name of the RVS server, and never IP  
addresses?  One could then get the IP addresses from the DNS name,  
using A and AAAA as usually.  If there is no RVS DNS name, the  
initial DNS name is used for getting A and AAAA too.  The drawback of  
that is that it would drop the possibility of having preference order  
of RVS servers, making all RVS servers equal.

Maybe something like the following?

   - DNS name of the RVS server, non-compressed FQDN in binary form
     - if NULL, use the present FQDN to fetch A and AAAA records
   - HIT length (bytes), HIT in binary
   - PK algorithm, PK length (multiple of 8), PK in binary

Explicit PK length allows other data to be appended to the record  
later, if need arises, but I don't know if we need it.

--Pekka