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

From: Pekka Nikander <[email-masked]>
Date: Mon, 4 Jul 2005 16:10:32 +0200

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

Based on the above, I think we should either used 16 bit integers
or, preferably, 8 bit integers with the value being interpreted
as, e.g.,

    2^((Lifetime - 64)/8) seconds.

That would then cover the range from 4 ms to 178 days, with the
granularity of about 0.4%.  If people consider that we should have
the ability to do longer registrations, the parameters could, of
course, be adjusted.

>> 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
                     zero
>   service(s) type(s) for which registration failed or was not
>   authorized. In particular a REG_FAILED with a failure type of zero
                              , (add a comma here)
>   would contain the service(s) type(s) for which registration requires
>   further credentials.

Very good.  Note the added missing comma and there may be zero
REG_FAILED parameters...

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

I would be more strict:

A host that is capable and willing to act as a registrar SHOULD
include a REG_INFO parameter in the R1 packets it send during base
exchanges.  If it is currently unable to provide any services, it
SHOULD include an empty REG_INFO, i.e., one with no services listed.
If the registrat-related configuration of such a host is later
changed, the host SHOULD send a new REG_INFO, indicating the new
set of services.

Consider adding a forward reference to the section explaining
cancellation policy.

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

I would rather make a common section on including both REG_RESPONSES
and REG_FAILEDs than copying the same text in multiple places...

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

Ok.

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

Good!

>
>> 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
                    includes an
>    or UPDATE packet when a registration has successfully completed.

Ok; note the verb form and article use.

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

Fine with me.

--Pekka

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

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 4 Jul 2005 16:10:32 +0200

zero
                              , (add a comma here)

I would be more strict:

                      zero

Ok.

Good!

                    includes an

Fine with me.

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Wed, 6 Jul 2005 18:16:07 +0200

On Wednesday 22 June 2005 15:50, Pekka Nikander wrote:
> 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.

Folks,

I have taken in account Pekka's comments, added security 
considerations and try to clarify the terminology. You will find it 
here:

<http://julien.laganier.free.fr/draft-koponen-hip-registration-01.txt>

Please let me know if you have any comments.

--julien

PS: there is also a htmlwdiff but it's messy cuz I've reorganized the 
text a lot.

<http://julien.laganier.free.fr/diff.html>