Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc5203-bis-03.txt

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 8 Jan 2014 09:21:19 +0000

Hi,

not having discussed this with Julien, but I would not mind at all if a new co-author with energy came in and made any changes that need making...

Lars

On 2013-12-20, at 14:33, Ari Keranen <[email-masked]> wrote:

> Hi Julien and Lars,
> 
> Glad to see this draft being updated. Now since we have also STD track CERT draft, would it make sense to implement the changes we discussed earlier?: http://www.ietf.org/mail-archive/web/hipsec/current/msg03666.html
> 
> That is still blocking the Native NAT Traversal draft going forward.
> 
> 
> Cheers,
> Ari
> 
> On 12/11/13 5:00 AM, [email-masked] wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the Host Identity Protocol Working Group of the IETF.
>> 
>> 	Title           : Host Identity Protocol (HIP) Registration Extension
>> 	Author(s)       : Julien Laganier
>>                           Lars Eggert
>> 	Filename        : draft-ietf-hip-rfc5203-bis-03.txt
>> 	Pages           : 13
>> 	Date            : 2013-12-10
>> 
>> Abstract:
>>    This document specifies a registration mechanism for the Host
>>    Identity Protocol (HIP) that allows hosts to register with services,
>>    such as HIP rendezvous servers or middleboxes.  This document
>>    obsoletes RFC5203.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5203-bis
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-03
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5203-bis-03
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Hipsec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hipsec
>> 
>

---

From: Julien Laganier <[email-masked]>
Date: Tue, 14 Jan 2014 20:35:29 -0800

Hi Ari,

Sorry for the late answer. I've implemented the changes we discussed
earlier here <http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5203-bis-04>
.

Please let me know in case something is missing.

--julien

On Fri, Dec 20, 2013 at 5:33 AM, Ari Keranen <[email-masked]> wrote:
> Hi Julien and Lars,
>
> Glad to see this draft being updated. Now since we have also STD track CERT
> draft, would it make sense to implement the changes we discussed earlier?:
> http://www.ietf.org/mail-archive/web/hipsec/current/msg03666.html
>

---

From: Ari Keranen <[email-masked]>
Date: Thu, 16 Jan 2014 18:20:21 +0200

Hi Julien,

Thanks, that looks good to me. Although reading the draft again, I was 
wondering is it missing some text regarding the "Insufficient resources" 
error?

Cheers,
Ari

---

From: Julien Laganier <[email-masked]>
Date: Thu, 16 Jan 2014 19:50:05 -0800

Hi Ari,

> wondering is it missing some text regarding the "Insufficient resources"

Hmm... a registration failing because of "insufficient resources" is
quite explicit; it conveys enough information for a  requester to know
that there are no resources to create a registration at a given
registrar. Presumably a requester would try to register at a different
registrar if it knows one...

What else would the requester need to know?

--julien

---

From: Ari Keranen <[email-masked]>
Date: Fri, 17 Jan 2014 16:42:57 +0200

Hi Julien,

> What else would the requester need to know?

I mean that it looks a bit strange that there's only an error code 
defined but no text at all when to use it (even if the name of the code 
kinda gives it away). I would recommend to add a sentence or two about 
when/how to use it.

I spotted one (copy-paste) error in the draft, section 3.3:

    If the registrar knows the Host Identities (HIs) of all the hosts
    that are allowed to use the relaying service, it SHOULD reject
    registrations from unknown hosts.  However, since it may be
    unfeasible to pre-configure the relay with all the HIs, the relay
    SHOULD also support HIP certificates [I-D.ietf-hip-rfc6253-bis] to
    allow for certificate based authentication.

This should no longer be "relaying service" and "relay" (2 instances 
here) but in general the service for which one is registering for.

In the figures, at the end of the section, I was wondering why S3 is not 
announced by the registrar? Also the text is a bit unclear; almost as if 
RQ would try to register for S1 and S2 even if the figure shows only S1.

In section "4.5. REG_FAILED", it says "Failure types other than zero (0) 
and one (1) have not been defined." This is obviously not true anymore. 
Perhaps here would be a good place for some text on the insufficient 
resources error code.

And by the way, I guess you can have more than one REG_FAILEDs if there 
was more than one failure type? The text seems to now imply only single 
REG_FAILED.

Section 6 says:

    Registrars act on a voluntary basis and are willing to accept being a
    responder and then to create HIP associations with a number of
    previously unknown hosts.

Now with the HI/cert authentication this has actually improved (you only 
potentially do things with previously unknown hosts).

Otherwise I think the draft is in good shape and could move forward.

Cheers,
Ari