Early Review of draft-ietf-hip-rfc6253-bis-05

Request Review of draft-ietf-hip-rfc6253-bis
Requested rev. no specific revision (document currently at 09)
Type Early Review
Team Internet Area Directorate (intdir)
Deadline 2015-11-25
Requested 2015-11-20
Authors Tobias Heer, Samu Varjonen
Draft last updated 2015-11-25
Completed reviews Genart Last Call review of -06 by Dan Romascanu (diff)
Genart Telechat review of -08 by Dan Romascanu (diff)
Secdir Last Call review of -06 by Sean Turner (diff)
Secdir Telechat review of -08 by Sean Turner (diff)
Intdir Early review of -05 by Jouni Korhonen (diff)
Intdir Early review of -05 by Pascal Thubert (diff)
Opsdir Last Call review of -06 by Qin Wu (diff)
Assignment Reviewer Pascal Thubert
State Completed
Review review-ietf-hip-rfc6253-bis-05-intdir-early-thubert-2015-11-25
Reviewed rev. 05 (document currently at 09)
Review result Ready
Review completed: 2015-11-25


My additions to Jouni's review since I am also assigned INT directorate reviewer for draft-ietf-hip-rfc6253-bis-05:
The document reads well, appreciate that.

Generic problem: 
I see how the requester and the registrar can cancel registrations, but is unclear how a registrar can withdraw a service.
I think this should be clarified before publication, with possibly a validation from the WG.

More detailed stuff:

3. HIP Registration Extension Overview
This document does not specify the means by which a requester
discovers the availability of a service, or how a requester locates a

>> The fact that the lookup is not included in the method means potentially an additional round trip than if R1 could be send to some anycast address (like DHAAD is in MIPv6).

3.1. Registrar Announcing Its Ability
A requester that is capable and willing to act as a registrar vis-a-vis a
specific requester SHOULD include a REG_INFO parameter in the R1
packets it sends during all base exchanges with that requester. 
Also, the R1 could contain a certificate and a some signed stuff that includes I1 to prove it is whom the requester thinks. 

>> Why is this a SHOULD? I expected a MUST otherwise nothing happens, right?
>> I mean, the potential not to do it is contained in the words capable and willing.

If services can be provided later, it SHOULD send
UPDATE packets indicating the current set of services available in a
new REG_INFO parameter to all hosts it is associated with.

>> And if the registrar is no more capable (maybe temporarily) SHOULD it also UPDATE with a REG_INFO?

If the
requester does not have any suitable certificates, it SHOULD send the
registration request without the CERT parameter to test whether the
registrar accepts the request based on the host's identity.

>> The Registrar could have hinted the required Authentication method in R1, per service type if needed.
>> This is wasting a round trip if the host does not have a certificate and has to try multiple registrars in a row.

<several times>  the registrar MUST proceed with the registration.

>> MUST looks strong language now; e.g. what of the registrar can no more for whatever reason?
>> I'd not have expected lowercase "may".

Failure Type 0
>> Not that I mind so much but sometime it is good to avoid the value '0'. 
>> This makes software easier to test (did my code write the damn field ?) etc... 

If the registrar requires further authorization and the requester has
additional credentials available, the requester SHOULD try to
register again with the service after the HIP association has been

>> again the uppercase is not necessarily warranted.  A lowercase "may" would do. 
>> It may have other options like going somewhere else.

The requester MUST NOT include more than one REG_REQUEST parameter in
its I2 or UPDATE packets, while the registrar MUST be able to process
one or more REG_REQUEST parameters in received I2 or UPDATE packets.

>> Is this me or is the 'or more' is pointless? 
>> the registrar receiving more than one REG_REQUEST is a protocol error and the traditional way is to drop the packet.

The minimum lifetime both registrars and requesters MUST support is
10 seconds, while they SHOULD support a maximum lifetime of 120
seconds, at least.

>> I agree that there needs to be boundaries. But this text looks inconsistent with:

The requester MUST be prepared to receive any registration lifetime,
including ones beyond the minimum and maximum lifetime indicated in
the REG_INFO parameter.

A zero lifetime is reserved for canceling purposes.
>> This text should be in section 4.1

I hope this helps,


> -----Original Message-----
> From: Int-dir [


 at ietf.org] On Behalf Of Jouni Korhonen
> Sent: mardi 24 novembre 2015 18:29
> To: <int-dir at ietf.org> <int-dir at ietf.org>; draft-ietf-hip-rfc6253-
> bis at tools.ietf.org; Bernie Volz (volz) <volz at cisco.com>
> Subject: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05
> I reviewed this document as part of the Int-Dir reviews activity. You should treat
> the comments as any IETF LC comments.
> The document is ready for piblication  with minor nits. My comments follow the
> line numbering as seen in IDnits.
> Editorial Comments:
> * Line 28: s/extends/updates
> * Line 72: s/extends/updates
> * Line 269: replaces or obsoletes.. typically when following the
>    cover page terminology I would prefer "obsoletes" here as well.
> * Line 287: a verb is missing? e.g. "..are discussed.." etc
> * Lines 264-265: I cannot parse this sentence. "in order" meanning
>    the 2 octets contain first Cert Group and followed by Cert ID?
>    Please clarify.
> * Figure line 136: although text is clear about the padding
>    behavior the figure makes one think there is always 2 octets
>    of padding.. suggest coming up with slightly different ascii
>    art here.
> Other (substantial) comments:
> * Lines 95-98: I find the recommendation of not including the CERT
>    in the I1 packet odd. Actually, allowing it in I1 is a bit odd in
>    general. A well behaving initiator would not do that unless it has
>    a very good reason to do so but a hostile initiator would most
>    certainly do that just to cause more processing at the responder.
>    Why the CERT has to be possible in I1 if it is not recommended to
>    be added in the first place?
> * Lines 103-14: The "MUST be set" text is a bit strange. Why not
>    stating the same for Cert ID and type as well? Actually as these
>    fields are in fixed positions and cannot be "optionally" left out.
>    I suggest doing some rewording here.
> * Section 7 security considerations does not discuss the possible
>    hostile use of CERT payload in I1 packet.. this is already hinted
>    in Section 2.
> - Jouni
> _______________________________________________
> Int-dir mailing list
> Int-dir at ietf.org