Re: [Hipsec] A new I-D: HIP Registration Extension

Hi Pekka,

On Wednesday 22 June 2005 13:50, Pekka Nikander wrote:
> I read this document again, and in general it looks good to me.

Thanks for reviewing it. Please find answers, but also questions :) 
inlined below.

> The language could be improved, now it is a little bit too
> "abstract" or fluffy to my taste.  Changing some of the terminology
> and especially the definitions of terms would make it easier to
> read.  Also considering advice from draft-iab-model-XX.txt might
> help.  But content-wise, once a proper security considerations
> section is added, I think the document starts to be ready
> for a WG LC, though most probably we have to wait for the base spec
> to first advance to WG LC.

I will try to improve the terminology and definitions following 
advices from draft-iab-model-03.txt

> Major detail:
>
> Did we discuss using exponential seconds instead of seconds for
> the lifetimes?  I don't remember any more.  In general, I'm in
> favour of fixed point exponential times instead of integer
> times...

I don't think we discussed them yet. 

Right now the specification uses 32-bits integer lifetimes, with a 
MUST minimum of 10s and a SHOULD maximum of 120s.

First of all, even if we stick to integer lifetimes, I think we can at 
least reduce the field size from 32-bits (~136 years) to 16-bits (~18 
hours), that it is still enough, in my opinion.

Then yes, we can also use exponential times; with 8-bits fields (or 
perhaps even less, i.e. 4 bits) that would allow to pack most of the 
REG_* TLV parameter into 8-bytes.  For instance:

4.1  REG_INFO

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Min LifeT Exp | Max LifeT Exp |  Reg Type #1  |  Reg Type #2  |  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What does other people think about having a 2^(Lifetime exponent) 
lifetime then?

>
> Can a reply include both REG_RESPONSE and REG_FAILED params
> if some of the registrations succeeded and some failed?
>

Yes. I tried to clarify the current wording, please see later below.

> Minor details:
>
> Sec 3, bullet 3:
> >    3.  At this point, the registrar tries to authenticate the
> > requester based on currently available information.  The details
> > of this authentication procedure are not specified in this
> > document.  If
>
> It would be good to be more specific in the second statement, and
> refer directly to the base spec.  Also make the difference between
> authentication (as a part of the base exchange) vs. authorisation
> (which is a matter local to the registrar).

What about:

  At this point, the registrar is able to authenticate the requester
  based on the Host Identity it includes in I2. Then, it has to 
  verify that this Host Identity is in fact authorized to register for
  the requested service(s), based on policy local to the
  registrar. The details of this authorization procedure are dependent
  on the type of the requested service(s) and on the registrar local
  policy, and are therefore not specified in this document. Then, the
  registrar includes in its R2 response a REG_RESPONSE parameter 
  containing the service(s) type(s) for which the registration was
  authorized, and one or more REG_FAILED parameter containing the
  service(s) type(s) for which registration failed or was not
  authorized. In particular a REG_FAILED with a failure type of zero
  would contain the service(s) type(s) for which registration requires
  further credentials.

> Sec 3, second list, bullet 1:
> >        exchanges or later announces its capabilities by sending
> > the
>
> It might be good to discuss briefly when REG_INFO might be sent in
> an UPDATE; i.e., when the registrar changes its configuration.
> It would also be good to note that there may be a long time between
> R1 with REG_INFO and UPDATE with REG_REQUEST...

What about:

  A host that is capable and willing to act as a registrar includes
  a REG_INFO parameter in the R1 packets it sends during base
  exchanges, or later in an UPDATE packet when a change of its
  registar-related configuration occurs.

> Sec 3, second list, bullet 3:
>
> Please clarify the authenticate vs. authorise language.  I think
> the first sentence uses authenticate while it should use authorise.

How about:

   The registrar has to verify that the requester is in fact
   authorized to register for the requested service(s), based on
   policy local to the registrar. Then, the
   registrar includes in its UPDATE response a REG_RESPONSE parameter 
   containing the service(s) type(s) for which the registration was
   authorized, and one or more REG_FAILED parameter containing the
   service(s) type(s) for which registration failed or was not
   authorized. In particular a REG_FAILED with a failure type of zero
   would contain the service(s) type(s) for which registration 
   requires further credentials.

> Sec 3, 2nd para after second list:
> >   Both the requester and registrar can cancel the created
> >   registration before its expiration.
>
> I don't understand what that is trying to say.  I guess this is
> part of the language being too abstract or fluffy...  Or otherwise
> I just need more coffee....

What about:

  Both the requester and registrar can cancel a registration   
  before it expires, if the services afforded by this registration
  are no longer needed by the requester, or cannot be provided any
  longuer by the registrar (for instance because its configuration
  changed).

> Sec 4.2:
> >    REG_REQUEST parameter is in an UPDATE packet, the registrar
> > SHOULD NOT modify the registrations of registration types which
> > are not listed in the parameter.  Moreover, the requester SHOULD
> > NOT include
>
> IMHO these "SHOULD NOT"s should be "MUST NOT"s....  In the former
> case, violating the rule would lead to inconsistent state (enough
> for a MUST), in the latter case apply the "be strict in what you
> sent (and liberal in what you expect) principle".

I'll make the change.

> >    the parameter unless the registrar's I1 packet or an earlier
> > received
>
> s/an earlier/latest/
>
> >    signature.  The requester SHOULD support inclusion of multiple
> >    instances of the REG_REQUEST parameter in its I2 packets.
>
> What happens if it does not?

Hhmm... nothing :) So perhaps it is better to say:

   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.

> Sec 4.3:
> >    The registrar SHOULD include the REG_RESPONSE parameter in its
> > R2 or UPDATE packet only if a registration has successfully
> > completed.
>
> I don't understand why we have here a "SHOULD"??  What is the
> rationale? Doesn't the registrar just include it if and only if the
> rgistration has been succesfully completed?

Yep. What about:

   The registrar include the REG_RESPONSE parameter in its R2 
   or UPDATE packet when a registration has successfully completed.

And then if we apply the "be (strict in what you sent and) liberal in 
what you accept" principle once more, is it okay to modify the 
following paragraph like this:

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

> Sec 4.4:
> >    The registrar SHOULD include the REG_FAILED parameter in its
> > R2 or UPDATE packet if registering with registration types listed
> > has not completed successfully and a requester is asked to try
> > again with additional credentials.
>
> I don't understand the rationale for the SHOULD here either.

So let's remove it.

> Sec 5:
> >    REG_RESPONSE parameters.  Therefore, registration type
> > definitions MAY define dependencies for HIP parameters that are
> > not defined in
>
> ... specifications that define different registration types and
> corresponding services MAY define ...

I'll make the change.

Thank you very much for your comments, it surely helps to improve the 
document.

--julien

_______________________________________________
Hipsec mailing list
Hipsec@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hipsec