marcelo bagnulo braun wrote:
Next the host verifies that the Responder Nonce is a recent one, and that the Responder Validator option matches the validator the host would have computed for the ULID, locators, responder nonce, and FII. ==> how do you define 'a recent one' ?this is also up to the implementations, but are you suggesting we provide some guidance about the lifetime of a responder nonce? like a maximum nonce lifetime or similar?
I think "recent" should capture the VALIDATOR_MIN_LIFETIME.Thus if the nonce is less than that constant (30 seconds), then it is recent. If we don't require that behavior then a retransmitted I2 might be silently ignored, which adds delay to the establishment.
==> you should probably apply the same policy for certain other ICMP errors,at least type 1 code 1 "Communication with destination administratively prohibited", implying the protocol may be filtered at the firewall.ok for that error code, do you have another one in mind?
Part of the issue with ICMP errrors generated by routers is that they only speak for one path between the hosts. In the case of a misconfigured site one path could result in type 1/code 1 but some other path does not. That's the motivation for only having host generated ICMPs to derive what the host actually supports.
==> but this is not an exhaustive list. Do you already specify somehow howyou will treat yet-to-be-specified options? How do you parse the options that are not on the lists?well, all the options have to have the format defined in section 5.14 whcih is basically a TLV format. In addition, it contains the C flag, that defines whether the option is criticial or not and if it must be recognized.what do you think that something is missing?
How about adding some text to the format section after the listed options for each message type that says: Future protocol extensions might define additional options for this message. The C-bit in the option format defines how such a new option will be handled by an implementation.
But I just realized that we don't seem to specify how an unknown option with C=1 should be handled (silently drop the message? Send some error such as an ICMP parameter problem??)
I'd suggest an ICMP parameter problem. Question is where we place this text. Does it make sense in secion 5.14?
If a host receives an option that it does not understand (an option that was defined in some future extension to this protocol) or is not listed as a valid option for the different message types above, then the Critical bit in the option determines the outcome. If C=0 then the option is silently ignored, and the rest of the message is processed. If C=1 then the host SHOULD send back an ICMP parameter problem (type 4, code ), with the Pointer referencing the first octet in the option Type field. When C=1 the message MUST NOT be processed.
==> at this point, I wondered, "how can the responder stay idle? it needsto remember _something_", so maybe a forward pointer to the security discussion (i.e., a global secret value) could be useful.ok
The point is that the host doesn't create or update any state per peer when receiving I1.
Erik