Subject: [Int-dir] Int-Dir review of draft-ietf-hip-rfc6253-bis-05

From: Jouni Korhonen <[email-masked]>
Date: Tue, 24 Nov 2015 09:29:12 -0800

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 24 Nov 2015 21:32:24 +0000

Thanks for doing the review for Int-Dir Jouni!

By the way and for what it may be worth to someone:

One item I noticed when quickly looking at this document while assigning
it to reviewers for the Int-Dir is that Appendix B “Change Log” is
probably not the best “report” of differences from RFC 6253? An example
that was better is in another document I was also in the process of
assigning at the same time - see
https://tools.ietf.org/html/draft-ietf-hip-rfc5203-bis-09#appendix-A:

—

Appendix A.  Changes from RFC 5203

   o  Updated references to revised HIP specifications.

   o  Added a new registration failure type for use in case of
      insufficient resources available at the HIP registrar.

   o  Added requester authorization based on certificates, and new
      registration failure type for invalid certificate.

—

Basically the detailed change log of rfc6253-bis draft is not as useful as
the key differences from the original RFC being “bis-ed”. There change log
is more often than not requested to be dropped by the RFC editor when
published as an RFC.

So, I would recommend reworking the draft to have a clear list of
differences from the RFC (you can leave the detailed log if you want, but
recommend it be removed by RFC editor on publication.)

- Bernie

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 25 Nov 2015 12:52:20 +0000

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

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

>> 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,

Pascal

> -----Original Message-----
> From: Int-dir [mailto:[email-masked]] On Behalf Of Jouni Korhonen
> Sent: mardi 24 novembre 2015 18:29
> To: <[email-masked]> <[email-masked]>; draft-ietf-hip-rfc6253-
> [email-masked]; Bernie Volz (volz) <[email-masked]>
> 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:
> 
> _______________________________________________
> Int-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-dir