Re: AD review of draft-ietf-shim6-proto -- section 5

[marcelo bagnulo braun <[e-mail]>]

Hi Jari,

thanks for the review, see inline comments below

El 11/09/2007, a las 22:00, Jari Arkko escribió:

>
> Continuing with the review:
>
> Substantial:
>
>>    The following options are defined for this message:
>>
>>    Responder Validator:  Variable length option.  Typically a hash
>>                   generated by the responder, which the responder  
>> uses
>>                   together with the Responder Nonce value to  
>> verify that
>>                   an I2 message is indeed sent in response to a R1
>>                   message, and that the parameters in the I2  
>> message are
>>                   the same as those in the I1 message.
>
> (Appears in multiple places in the document).
>
> Is the use of this option mandatory?

this option is mandatory for R1 and I2 messages

I have added that to the description of R1 and I2 messages

> What about its copying
> on the other side, if it is present? Please clarify.
>


Yes, the initiator must copy it when receiving the R1 and generating  
the I2 message

i have added that to the document in the section describing the I2  
message

>> Locator List Generation:  32-bit unsigned integer.  Indicates a
>> generation number which is increased by one for each
>> new locator list.  This is used to ensure that the
>> index in the Locator Preferences refer to the right
>> version of the locator list.
>
> Are there requirements on keeping this generation counter
> unique across reboots, or would rolling back not cause
> a problem?

good point

I don't think so, because basically, when one end reboots, the  
established context is lost and needs to be recovered. The recovery  
procedure basically re runs the context establishment procedure  
(without requiring the I1 message) but in any case, a new locator  
list is exchanged and the locator list generation value is updated  
accordingly in the context recovery procedure.

So, i don't think the value must persists during reboots, so i guess  
it would be ok to leave the text as it is or would you prefer to  
include a comment explicitly stating the lack of need for persistence  
during reboots?

> Is there a window that one should be following?

I don't think so, because this option is exchanged in I2, R2 or  
UPDATE message, and all of them are acked, so if no ack is received  
the sender should stick to the old value. Same question than above,  
should we include something about this in the document?

> Are generation counters unique per context tag?
>

I don't think this is strictly needed, but i guess in practice they  
will be in most of the cases, since i doubt there will be more than  
2^32 different locator lists.
What is needed is to prevent that two locator lists are confused, so  
generating the locator list generation as described, this is avoided.  
However, it would be perfectly ok to repeat a number if both ends are  
certain that there is no confusion (for example the value was used a  
long time ago and both ends are certain that the value is no longer  
in use)

so i am not sure what is the best option here... i mean i don't think  
we need to require using every generation value only once during the  
lifetime of a context, because it would be hard to enforce  
(especially during reboots) One option would be to require uniqueness  
as long as there are no reboots


As it currently described in the document, generation values are  
increased each time a new locator list is exchanged, so they will not  
be repeated but there is no problem of repeating when there are  
reboots, since there is no explicity requirement to avoid repetition,  
which i think it is the right approach. However, i am not sure how to  
explain this clearly in terms of uniqueness requirements of the  
generation values...

>>                            +-------+----------+
>>                            | Value |  Method  |
>>                            +-------+----------+
>>                            |   0   | Reserved |
>>                            |       |          |
>>                            |   1   |    HBA   |
>>                            |       |          |
>>                            |   2   |    CGA   |
>>                            |       |          |
>>                            | 3-255 | Reserved |
>>                            +-------+----------+
>
> I'm reading on, but what if it is the kind of
> a combined HBA and CGA as described in the shim6-hba
> draft? Presumably you indicate HBA if the locator
> is in the fixed set and CGA if its in the dynamic,
> but it would be good to clarify this.
>

note that for a locator list of n locators there are n locator  
verification method octets, since it is stated that:

   Verification Method:  N octets.  The i'th octet specifies the
                   verification method for the i'th locator.

So each locator will have its associated verification method. So in  
case that a hybrid CGA/HBA is being used, the locators validated with  
HBA will have their verification method marked to HBA and in the case  
of those locators validated with CGA they will have its verification  
method marked are CGA.

This part it is a bit tricky, do you think it requires further  
clarification?

>>    This option contains the CGA Parameter Data Structure (PDS).  When
>>    HBA is used to verify the locators, the PDS contains the HBA
>>    multiprefix extension.  When CGA is used to verify the  
>> locators, in
>>    addition to the PDS option, the host also needs to include the
>>    signature in the form of a CGA Signature option.
>
> The Parameter Data Structure contains more than the
> multiprefix extension, e.g., the public key, the
> random bits instead of a public key for HBAs, and
> any options unrelated to Shim6 that the CGA might
> have. I would remove the second sentence above or
> reword it to make sure that you really do include
> the FULL CGA Parameter Data Structure.
>

reworded as follows:

    This option contains the CGA Parameter Data Structure (PDS). When
    HBA is used to verify the locators, the PDS contains the HBA
    multiprefix extension in addition to the PDS mandatory fields and
    other extensions unrelated to Shim6 that the PDS might have.
    When CGA is used to verify the locators, in
    addition to the PDS option, the host also needs to include the
    signature in the form of a CGA Signature option.


> Editorial:
>

done

regards, marcelo


>>    included, the packet would become larger than 1280 bytes.Another
>
> s/[.]/. /
>
>>     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
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |  Next Header  |  Hdr Ext Len  |0|     Type    |Type-specific|0|
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |            Checksum           |                               |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
>>    |                    Type-specific format                       |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>    Fields:
>>
>>    Next Header:   8-bit selector.  Normally set to NO_NXT_HDR (59).
>>
>>    Hdr Ext Len:   8-bit unsigned integer.  Length of the Shim6  
>> header in
>>                   8-octet units, not including the first 8 octets.
>>
>>    P:             Set to zero.  A single bit to distinguish this from
>>                   the Shim6 payload extension header.
>>
>>    Type:          7-bit unsigned integer.  Identifies the actual  
>> message
>>                   from the table below.  Type codes 0-63 will not
>>                   trigger R1bis messages on a missing context,  
>> while 64-
>>                   127 will trigger R1bis.
>>
>>    0:             A single bit (set to zero) which allows Shim6  
>> and HIP
>>                   to have a common header format yet telling Shim6  
>> and
>>                   HIP messages apart.
>
> Here I got confused about the two 0's. The first one is P in the list,
> the other one is "0". Maybe you need to set one of the zeroes in the
> picture to something else (P or R), or add some text to make this
> clearer.
>
> Jari