[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: questions about draft-ietf-shim6-proto-06.txt
Hi,
sorry for the late reply...
thank you very much for your careful review.
see below...
El 05/12/2006, a las 14:54, Matthijs Mekking escribió:
-----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.
agree
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?
this is what is stated in the current draft as you quote
Is this value solely used by a host acting as responder?
yes, the initiator does not use this constant afaict
If so, do you agree that this value should be used outside SHIM6?
not sure what you mean here....
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.
the idea here is to minimize the state associated to a new context
until we are sure that the initiator really wants to establish a
context (and this is not a DoS attack aimed to consume resources)
so the point is that there is no context information stored (but it is
ok to have host state, not associated to any not yet existent context)
The idea then is that the responder has only a Secret S and a Responder
nonce that he is incrementing each time it receives a new I1.
So i guess that in order to verify that the responder nonce and the
validator is recent, it will need to store the time each responder
nonce was generated. this would indeed imply a context specific state
that is what we are trying to avoid.
Another option would be that the responder nonces are simply the clock
value and so there is no need to store information about the generation
time of each responder nonce (this would work as long that the Secret S
is modified at least once each time the responder nonces are rollover)
In this case, we can obtain the same behaviour without requiring even
to store the time of generation of each responder nonce, what do you
think?
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)?
i don't think so, this is important to provide the security against DoS
and replay attacks, so i think it is needed and we should keep it.
However, as you mention, the current suggestion for generating the
responder validator would result in some state per received I1 afaict,
so i would suggest to change the way the responder nonce counter is
incremented....
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?
please note that section 7.10.1. Generating the R1 Validator where it
is mentioned that the responder nonce is generated by using a counter
value is a suggestion (just an example). a node can generate the
values as it plesases as long they are used as described in the other
sections of the spec.
3. In section 7.12, the host MAY retransmit I2. Why is this a MAY and
not a SHOULD?
because the important thing is that the initiator retries to establish
the context. However retrying with an I2 may not be a good strategy,
because the validator information may be expired. So, the host may
retransmit I2 (if he wants to take the risk that the validator
information is expired) but in any case it needs to fall back to send a
new I1 in any case, makes sense?
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?
E-Failed and No_support states are basically due to the fact that the
attempts to initiate a context have failed.
So, i guess that in case that some packets, like a payload packet or
similar, it should behave as idle, since the goal of the e failed and
no support states are simply to avoid the retrials of the initiator, in
case that it seems that is not possible to establish the context.
So i would say that the main characteristics of the efailed and no
support basically affect the behaviour of the node as an initator and
not as a reciver, so, it should behave as a normal receiver in idle
state
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.
with respect to init nonce, this value is only used during the context
exchange,
with respect to the responder nonce, if we rephrase as above, then the
only thing needed is a clock (and eventually the secret S value, but
this is implementation dependent) and it is not associated to any
specific context
otoh, the other information described in section 6.1. is stable context
information, so i guess we havent' included this info there is because
it is seen as transient information... otoh, i think it may be
interesting to include the information because it is critical to the
context exchange procedure... not sure...
the CT(R1bis) is generated from the payload packet received and it is
only stored during the context recovery phase, so i am not convinced it
would be so useful to describe it here...
please note that this section is a model and it is not mandatory
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 you want to retransmit the I2, then yes.
If so, than the
responder validator should also be stored (because this is also copied
from the R1 message, just like RESP nonce).
agree, need to add this to the table...
If this is the reason, than
I think RESP nonce, INIT nonce and the responder validator should also
be stored in state I2BIS-SENT.
yes, need to add the RESP nonce and INIT nonce and validator in the
I2BISSENT state
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).
the locators are included in the text afaict....
w.r.t. the S value, the validator needs to be verified in a coherent
way in which it was generated, but as i mentioned earlier, the
description f how to generate a validator is just an example, so the
secret S for instance is just a suggestion.
the init nonce should be added indeed
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)
the value S, the same consderation than above...
the ULID and FII, agree need to be removed from the verification, since
they are not availble for generation
the receiver context add should be added to the verification procedure.
Regards, marcelo
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-----