questions about draft-ietf-shim6-proto-06.txt

[Matthijs Mekking <matthijs@NLnetLabs.nl>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

My name is Matthijs, and I am doing research on shim6 for Radboud
University Nijmegen/NLnetLabs Amsterdam (Netherlands). I have a couple
of questions about draft-ietf-shim6-proto-06.txt that seem a bit unclear
to me. Some of them are maybe obvious comments, but I shall make them,
because I think it is good for a protocol description to allow only one
clear interpretation.

1. Wat is exactly meant with VALIDATOR_MIN_LIFETIME? According to the
draft, "the peer might reject Responder Validator options that are older
than VALIDATOR_MIN_LIFETIME to avoid replay attacks" and "Nonces that
are no older than VALIDATOR_MIN_LIFETIME SHOULD be considered recent".
Does this value apply to both nonces and responder validator options?

Is this value solely used by a host acting as responder?

If so, do you agree that this value should be used outside SHIM6?
Because a responder may not store state (yet) and thus can not verify if
a nonce in an I2 or I2bis message may be considered recent. If you
agree, can't this value be omitted from the document (since it is
independent of the correct working of SHIM6, but merely a security
consideration of the host)?




2. In addition, when generating a responder validator, the draft talks
abouot increasing a counter, and using the counter value as responder
nonce. Is this the same way how the responder and initiator computes
their other INIT nonces and RESP nonces?




3. In section 7.12, the host MAY retransmit I2. Why is this a MAY and
not a SHOULD?




4. The draft considers a context in state IDLE the same as a context
being non-existing. However, the state machine in appendix B says that
context in state E-FAILED of state NO-SUPPORT should behave the same as
if it was in IDLE. Does this mean when chapter 7 speaks of 'if no
context is found, the host should ... (do something useful)' this also
applies to if a context is found and the state is E-FAILED or
NO-SUPPORT? For example in section 7.9: "If no state is found (i.e., the
state is IDLE), then the host replies with a R1 message as specified
below." Does a host needs to reply with R1 if a context is found that is
in state E-FAILED or NO-SUPPORT?




5. In chapter 6, a conceptual model of the host is given. However, the
second table in section 6.2 introduces some new elements that are not
described in section 6.1: INIT nonce, RESP nonce and CT(R1bis). I
suggest that they (including a short description) are added to section 6.1.




6. Am I right that the RESP nonce in I2-SENT is stored so that the host
is able to create the correct I2 retransmission? If so, than the
responder validator should also be stored (because this is also copied
from the R1 message, just like RESP nonce). If this is the reason, than
I think RESP nonce, INIT nonce and the responder validator should also
be stored in state I2BIS-SENT.




7. In the text, computing a responder validator looks inconsistent with
generating the validator:

For R1 the secret S, the Initiator Context Tag and the locators are
omitted when computing the validator:

"use the following information concatenated as input to the one-way
function:
o  The the secret S
o  That Responder Nonce
o  The Initiator Context Tag from the I1 message
o  The ULIDs from the I1 message
o  The locators from the I1 message (strictly only needed if they are
different from the ULIDs)
o  The forked instance identifier if such option was included in the
I1 message"
(section 7.10.1, page 62)

and

"that the Responder Validator option matches the validator the host
would have computed for the ULID, locators, responder nonce, and FII."
(section 7.13, page 63).

For R1bis the secret S and Receiver Context tag are omitted when
computing the validator, but the ULID and FII are added:

"use the following information concatenated as input to the one-way
function:
o  The the secret S
o  That Responder Nonce
o  The Receiver Context tag included in the received packet
o  The locators from the received packet"
(section 7.17.1, page 68)

and

"the Responder Validator option matches the validator the host would
have computed for the ULID, locators, responder nonce, and FII as part
of sending an R1bis message."
(section 7.20, page 69)


With kind regards,

Matthijs Mekking
matthijs@NLnetLabs.nl
NLnetLabs/Radboud University
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFdXocNiaStnTWEtYRAo3nAKC+sB2E/8YxJQ6PR7AzORZ6gEKyOgCeJccj
UQAPF0SpqzlfSZT7smcf++k=
=P4tt
-----END PGP SIGNATURE-----