Pekka Savola: 5.1.1 Processing Rules for Senders The CGA option MUST be present in all Neighbor Solicitation and Advertisement messages, and in Router Solicitation messages not sent with the unspecified source address. ==> if I read this correctly, using CGA with RS messages is a MAY? (I guess the intent is a MUST) ==> is the non-unspecified source address a MUST? Might be good to make it an uppercase/clarify slightly in any case. (That is, which parts of the RS sentence is a MUST (or not) should be made clearer.) [[ Note: the intent is clearer from the rest of 5.1.1 and 5.1.2]] ..... A message containing a CGA option MUST be checked as follows: If the interface has been configured to use CGA, the receiving node MUST verify the source address of the packet using the algorithm described in Section 5 of [12]. The inputs for the algorithm are the contents of the Collision Cnt, Modifier, and the Key Information fields, the claimed address in the packet (as discussed in the previous section), and the minimum acceptable Sec value. If the CGA verification is successful, the recipient proceeds with the cryptographically more time consuming check of the signature. ==> as the CGA verification gives you no increase of security in itself, the last sentence should be more balanced, or add something like, "However, even if the CGA verification succeeds, no claims about the validity of the use can be made, until the signature has been checked." Similar in 3rd paragtaph of 9.3: When CGA protection is used, SEND deals with the DoS attacks using the verification process described in Section 5.2.2. In this process, a simple hash verification of the CGA property of the address is performed before performing the more expensive signature verification. ........... Pad Length An 8-bit integer field, giving the length of the Pad field in units of an octet. [...] ==> I see zero need for this option. Isn't it enough that the signature is padded up to 8 bytes automatically? (The same issue in 6.2.3 and 6.2.4 with Trust Anchor and Certificate options.) 5.3.2 Nonce Option ==> the padding requirement must be spelled out, if the nonce is not 6+8n bytes long. 5.3.3 Processing rules for senders All solicitation messages MUST include a Nonce. All solicited-for advertisements MUST include a Nonce, copying the nonce value from the received solicitation. [and:] 5.3.4.1 Processing solicited-for advertisements [...] Otherwise, if the message does not contain a Nonce option, it MAY be considered as a non-solicited-for advertisement, and processed according to Section 5.3.4.2. ==> note that for senders, putting in a Nonce is a MUST, but here the lack of it MAY be ignored. Is this intentional (could be)? 5.3.4.2 Processing all other messages [...] The receive time of the last received, accepted SEND message. This is called RDlast. The time stamp in the last received, accepted SEND message. This is called TSlast. ==> AFAICS, "receive time" has only defined in 5.3.4.1, which doesn't apply here. Further, it may be worth spelling out what exactly constitutes an "_accepted_ SEND message". 6.2.5 Processing Rules for Routers Routers SHOULD possess a key pair and a certificate from at least one certificate authority. ==> this is an operational requirement, not an implementation requirement, so I would use lower-case for this, or put it in an operational considerations section. (Same in the last paragraphs of section 7.3.) Hosts SHOULD store certificate chains retrieved in Delegation Chain Discovery messages if they start from an anchor trusted by the host. The certificate chains SHOULD be verified, as defined in Section 6.1, before storing them. [[and the similar in section 6.1]] ==> isn't the usefulness of these certificates nullified, unless it can be guaranteed that they have been verified? Why isn't this a MUST? If the reason is only to support temporary storage of certificate chains, those should be treated as separate from the rest of the certificates -- perhaps there should be a notion of verified certificate storage and unverified temporary storage. 7.1 CGA Addresses Nodes that use stateless address autoconfiguration, SHOULD generate a new CGA as specified in Section 4 of [12] for each new autoconfiguration run. ==> what is the definition of "each new autoconfiguration run"? o The node SHOULD have a configuration option that causes it to ignore insecure advertisements even when performing Duplicate Address Detection for the first tentative address. This configuration option SHOULD be disabled by default. This is recovery mechanism, in case attacks against the first address become common. ==> I'd lean towards a "MAY have".. because this seems irrelevant. You can optimize away the cost of just one CGA generation (unless Sec >> 0), which is a lightweight process, and then the insecure advertisements are ignored. So, I don't think this is really needed, but if it, we could strengthen the requirement later to a SHOULD (or the like) if we think this threat becomes significant. When a SEND node is used on a link that also connects to non-SEND nodes, the SEND node ignores any insecure Neighbor Solicitations or Advertisements that may be send by the non-SEND nodes. ==> Based on section 8 on transition, this is not 100% correct -- the SEND node will allow the first DAD response, correct? The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. ==> actually, there hasn't been. Only about CGA and the old send-ipsec. Is Send-IPSEC still valid for this document now that CGA is out? [26] International Organization for Standardization, "The Directory - Authentication Framework", ISO Standard X.509, 2000. [27] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, September 2001. ==> there are some references, at least these, which haven't been used in the body. Use or remove. ------------------- Thanks for the comments. I think I took into account all of them except for the following: - Pad length being unnecessary. The pad lengths are explicit since there are variable length fields. For instance, the Trust Anchor option has a name which may end at an 8-octet boundary. We could pad with zero bytes, but I feel better about an explicit pad length field. Similarly, the Signature and Certificate options have complicated ASN.1 data, and it may be easier to have an explicit field than to determine it from the encoding of a field. - Nonces being required for senders but the lack of a nonce can in some cases be ignored by receivers. I was unsure about this one. Perhaps Pekka N can explain as this part of the text came from him, I think. But I would classify this under "be conservative what you send, liberal what you accept". - IPR notices applying to an old draft version and name. I know. I can not speak for others but I like to avoid going to the IPR department more often than really necessary ;-). Since we are about to finish the SEND protocol and there are no more draft renamings (I hope!) I now go and ask for an update of the IPR notice too. See the new text in http://www.arkko.com/publications/send/issues/issue54diff.html ------------------- Pekka Nikander: > - Nonces being required for senders but the lack of a nonce can in > some cases be ignored by receivers. I was unsure about this > one. Perhaps Pekka N can explain as this part of the text came from > him, I think. But I would classify this under "be conservative what > you send, liberal what you accept". I'm sorry but I don't remember the details any more, and don't have time to dive in right now. I guess your explanation, Jari, is the right one. ------------------- ------------------- -------------------