Early Review of draft-ietf-hip-rfc6253-bis-05
review-ietf-hip-rfc6253-bis-05-intdir-early-thubert-2015-11-25-00

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:int-dir-bounces

 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 >

https://www.ietf.org/mailman/listinfo/int-dir