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

[Jari Arkko <jari.arkko@piuha.net>]

Marcelo,

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

Its fine without new text. Thanks for the explanation.

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

Probably not needed.

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

Is there any chance of generation counters from two different
contexts (e.g., forking, re-establishment after reboot) be mixed
up somehow? If not, there's really no problem.

I don't recall if you said something anywhere about
how generation counters are searched; my assumption
is that you only do that check/search within the
context. I think it would be good to state that.


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

No, this explanation is fine.

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

Looks good, thanks.

Jari