[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AD review of draft-ietf-shim6-proto -- section 5
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