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

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jun 2005 17:13:10 +0200

Hi,

On Feb 15, 2005, at 18:51 , Teemu Koponen wrote:
>
> A new draft that is a spin-off from the rendezvous draft:
>
>     Title        : Host Identity Protocol (HIP) Registration Extension
>     Author(s)    : T. Koponen, et al.
>     Filename    : draft-koponen-hip-registration-00.txt
>     Pages    : 13
>     Date        : 2005-2-14

we haven't received much feedback on this ID and would much  
appreciate if some WG people could take a look at it. (FWIW, it's  
only a few pages long! :-)

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 22 Jun 2005 16:50:45 +0300

I read this document again, and in general it looks good to me.

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.

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

The parameter type values need to be checked against base-03.

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

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

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

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.

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

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

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

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?

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.

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

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Jun 2005 13:52:22 +0000

Hi Pekka,

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

> to first advance to WG LC.

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

> favour of fixed point exponential times instead of integer

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?

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

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.

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

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

> >   Both the requester and registrar can cancel the created
> >   registration before its expiration.
>

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

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

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
>

I'll make the change.

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

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Jun 2005 13:52:22 +0000

Hi Pekka,

4.1  REG_INFO

    0                   1                   2                   3

What about:

What about:

How about:

What about:

I'll make the change.

Yep. What about:

So let's remove it.

I'll make the change.

--julien

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Jun 2005 13:56:44 +0200

>> favour of fixed point exponential times instead of integer
...
> REG_* TLV parameter into 8-bytes.  For instance:
...
> What does other people think about having a 2^(Lifetime exponent)

In a recent tcpm draft, we used a "granularity" bit, i.e.:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Kind = X  |   Length = 4  |G|        User Timeout         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
    Granularity (1 bit)
       Granularity bit, indicating the granularity of the "User Timeout"
       field.  When set (G = 1), the time interval in the "User Timeout"
       field MUST be interpreted as minutes.  Otherwise (G = 0), the  
time
       interval in the "User Timeout" field MUST be interpreted as
       seconds.

    User Timeout (15 bits)
       Specifies the user timeout suggestion for this connection.  It
       MUST be interpreted as a 15-bit unsigned integer.  The  
granularity
       of the timeout (minutes or seconds) depends on the "G" field.

This may be another choice in this case as well.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 28 Jun 2005 13:56:44 +0200

...
...

       0                   1                   2                     3

    User Timeout (15 bits)

Lars