Dave Thaler writes: 1) Section 6 states: > Similarly, the router, which is already connected to the network, can > if necessary communicate off-link and construct the certificate > chain. This should be clarified with "in some cases". If the router is not connected to the Internet, this may not be possible. 2) Sections 6.1 and 6.2 describe an Identifier field, but does not specify how it is set in a solicitation or in an unsolicited advertisement. E.g. if it is always set to 1, it doesn't seem very useful. Likewise, if each host starts with 1 and increments, it's also less useful since hosts can collide. I think it should be randomly generated if possible. 3) Sections 6.3 and 6.4 both specify options with a variable-length field followed by padding. However, they use two different encodings for no good reason. One specifies the length of the field, and the other specifies the length of the padding. Instead, both options should be consistent. 4) Section 6.4 says: > When the Name Type field is set to 1, the Name field contains the > Fully Qualified Domain Name of the trusted root, for example > "trustroot.operator.com". More guidance is needed to prevent interoperability problems. Is the string null-terminated (I assume no)? Are internationalized domain names legal? What is the encoding? (UTF-8? Unicode? ...) 5) Section 6.5 says: > RFC 3281. If the GeneralName attribute is a dNSName, it MUST be > resolvable to a global unicast address assigned to the router. If > the GeneralName attribute is an iPAddress, it MUST be a global > unicast address assigned to the router. For purposes of facilitating For people not familiar with X.509, is it easy to explain in 1-2 sentences what it is used for? (That is, why is it a MUST above?) As is, it sounds suspiciously like a security hole. 6) Section 6.5.1 says: > This field MUST contain a list of prefixes that the router is > authorized to route, or the unspecified prefix if the router This wording is particularly problematic. Routers route packets not prefixes. They _advertise_ prefixes in RA's and in routing protocols. It's similarly unclear whether the prefix list is what remote prefixes it's allowed to advertise as off-link routes in RA's (e.g. ::/0 if it can be a default router on the link), or whether the prefix list is what local prefixes it's allowed to advertise as on-link routes in RA's. I'm guessing the latter, but I can think of arguments for restricting both. 7) Sections 6.6 and 6.7 appear to contradict each other. 6.6 says: > SHOULD send an advertisement without any certificates. In this case > the router SHOULD include the Trusted Root options which were > solicited. Hence the Trusted Root option is legal in an advertisement. 6.7 says: > packet processed in the normal manner. The only defined option that > may appear is the Certificate option. An advertisement that passes Hence the Trusted Root option is not legal in an advertisement. 8) Section 7.1.2 and reference [27] contradict each other. 7.1.2 says: > CGAParameters ::= SEQUENCE { > publicKey SubjectPublicKeyInfo, > auxParameters CGAAuxParameters OPTIONAL } whereas [27] now has the opposite order. It would be better to not copy the definition here at all, and just refer to [27] for the definition. 9) Section 7.1.3 talks about a minbits parameter. It doesn't really say how the value should be determined. Some guidance would be helpful. --------------- Jari Arkko responds to Dave Thaler: > 1) Section 6 states: > > Similarly, the router, which is already connected to the network, can > > if necessary communicate off-link and construct the certificate > > chain. > > This should be clarified with "in some cases". If the router is > not connected to the Internet, this may not be possible. Right. > 2) Sections 6.1 and 6.2 describe an Identifier field, but does not specify how > it is set in a solicitation or in an unsolicited advertisement. E.g. > if it is always set to 1, it doesn't seem very useful. Likewise, if > each host starts with 1 and increments, it's also less useful > since hosts can collide. I think it should be randomly generated if > possible. Ok. > 3) Sections 6.3 and 6.4 both specify options with a variable-length > field followed by padding. However, they use two different encodings > for no good reason. One specifies the length of the field, and the > other specifies the length of the padding. Instead, both options > should be consistent. Right. Lets change 6.4. > 4) Section 6.4 says: > > When the Name Type field is set to 1, the Name field contains the > > Fully Qualified Domain Name of the trusted root, for example > > "trustroot.operator.com". > > More guidance is needed to prevent interoperability problems. > Is the string null-terminated (I assume no)? > Are internationalized domain names legal? What is the encoding? > (UTF-8? Unicode? ...) I see your point. Is there a good example where FQDN usage has been fully specified? > 5) Section 6.5 says: > > RFC 3281. If the GeneralName attribute is a dNSName, it MUST be > > resolvable to a global unicast address assigned to the router. If > > the GeneralName attribute is an iPAddress, it MUST be a global > > unicast address assigned to the router. For purposes of > facilitating > > For people not familiar with X.509, is it easy to explain in 1-2 > sentences what it is used for? (That is, why is it a MUST above?) > As is, it sounds suspiciously like a security hole. I agree that more explanation is required. The intentin of the IP address is to provide a check against the router's IP address in the cert. > 6) Section 6.5.1 says: > > This field MUST contain a list of prefixes that the router is > > authorized to route, or the unspecified prefix if the router > > This wording is particularly problematic. Routers route packets > not prefixes. They _advertise_ prefixes in RA's and in routing protocols. > It's similarly unclear whether the prefix list is what remote > prefixes it's allowed to advertise as off-link routes in RA's (e.g. > ::/0 if it can be a default router on the link), or whether the prefix > list is what local prefixes it's allowed to advertise as on-link routes > in RA's. I'm guessing the latter, but I can think of arguments for > restricting both. Right. It should have said advertise. And yes, it should probably be the latter case for the advertisements. > 7) Sections 6.6 and 6.7 appear to contradict each other. > 6.6 says: > > SHOULD send an advertisement without any certificates. In this case > > the router SHOULD include the Trusted Root options which were > > solicited. > Hence the Trusted Root option is legal in an advertisement. > > 6.7 says: > > packet processed in the normal manner. The only defined option that > > may appear is the Certificate option. An advertisement that passes > Hence the Trusted Root option is not legal in an advertisement. Right. 6.7 should be corrected. > 8) Section 7.1.2 and reference [27] contradict each other. > 7.1.2 says: > > CGAParameters ::= SEQUENCE { > > publicKey SubjectPublicKeyInfo, > > auxParameters CGAAuxParameters OPTIONAL } > whereas [27] now has the opposite order. > It would be better to not copy the definition here at all, and just > refer to [27] for the definition. Ok. > 9) Section 7.1.3 talks about a minbits parameter. It doesn't really > say how the value should be determined. Some guidance would be > helpful. Perhaps [27] can help here? Maybe add a reference? --------------- Pekka Nikander: I have now edited in Dave Thaler's comments as follows: > 1) Section 6 states: > > Similarly, the router, which is already connected to the network, can > > if necessary communicate off-link and construct the certificate > > chain. > > This should be clarified with "in some cases". If the router is > not connected to the Internet, this may not be possible. The new text now reads: In the typical case, a router, which is already connected to beyond the link, can (if necessary) communicate with off-link nodes and construct such a certificate chain. > 2) Sections 6.1 and 6.2 describe an Identifier field, but does not > specify how it is set in a solicitation or in an unsolicited > advertisement. E.g. if it is always set to 1, it doesn't seem > very useful. Likewise, if each host starts with 1 and increments, > it's also less useful since hosts can collide. I think it should > be randomly generated if possible. The new text now reads: A 16-bit unsigned integer field, acting as an identifier to help matching advertisements to solicitations. The Identifier field MUST NOT be zero, and its value SHOULD be randomly generated. (This randomness does not need to be cryptographically hard, though. Its purpose is to avoid collisions.) > 3) Sections 6.3 and 6.4 both specify options with a variable-length > field followed by padding. However, they use two different encodings > for no good reason. One specifies the length of the field, and the > other specifies the length of the padding. Instead, both options > should be consistent. Changed now so that both sections have an explicit pad length. > 4) Section 6.4 says: > > When the Name Type field is set to 1, the Name field contains the > > Fully Qualified Domain Name of the trusted root, for example > > "trustroot.operator.com". > > More guidance is needed to prevent interoperability problems. Is the > string null-terminated (I assume no)? Are internationalized domain > names legal? What is the encoding? (UTF-8? Unicode? ...) The new text now reads: When the Name Type field is set to 1, the Name field contains a Fully Qualified Domain Name of the trusted root, for example, "trustroot.example.com". The name is stored as a string, in the "preferred name syntax" DNS format, as specified in RFC1034 Section 3.5. Additionally, the restrictions discussed in RFC 3280 Section 4.2.1.7 apply. > 5) Section 6.5 says: > > RFC 3281. If the GeneralName attribute is a dNSName, it MUST be > > resolvable to a global unicast address assigned to the router. If > > the GeneralName attribute is an iPAddress, it MUST be a global > > unicast address assigned to the router. For purposes of facilitating > > For people not familiar with X.509, is it easy to explain in 1-2 > sentences what it is used for? (That is, why is it a MUST above?) As is, it sounds suspiciously like a security hole. This issue has disappeared since we no longer use RFC3281. > 6) Section 6.5.1 says: > > This field MUST contain a list of prefixes that the router is > > authorized to route, or the unspecified prefix if the router > > This wording is particularly problematic. Routers route packets > not prefixes. They _advertise_ prefixes in RA's and in routing protocols. > It's similarly unclear whether the prefix list is what remote > prefixes it's allowed to advertise as off-link routes in RA's (e.g. > ::/0 if it can be a default router on the link), or whether the prefix > list is what local prefixes it's allowed to advertise as on-link routes > in RA's. I'm guessing the latter, but I can think of arguments for > restricting both. This issue has disappeared since we no longer use RFC3281. > > 7) Sections 6.6 and 6.7 appear to contradict each other. > 6.6 says: > > SHOULD send an advertisement without any certificates. In this case > > the router SHOULD include the Trusted Root options which were > > solicited. > > Hence the Trusted Root option is legal in an advertisement. > > 6.7 says: > > packet processed in the normal manner. The only defined option that > > may appear is the Certificate option. An advertisement that passes > > Hence the Trusted Root option is not legal in an advertisement. 6.7 fixed to allow Trusted Root option. > 8) Section 7.1.2 and reference [27] contradict each other. > 7.1.2 says: > > > CGAParameters ::= SEQUENCE { > > publicKey SubjectPublicKeyInfo, > > auxParameters CGAAuxParameters OPTIONAL } > > whereas [27] now has the opposite order. It would be better to not > copy the definition here at all, and just refer to [27] for the > definition. This issue has diappeared since we no longer use ASN.1 here. > 9) Section 7.1.3 talks about a minbits parameter. It doesn't really > say how the value should be determined. Some guidance would be > helpful. The new text now reads: The minimum acceptable key length for the public keys used in the generation of the CGA address. The default SHOULD be 1024 bits. Implementations MAY also set an upper limit in order to limit the amount of computation they need to perform when verifying packets that use these security associations. Any implementation should follow prudent cryptographic practise in determining the appropriate key lengths. I don't think whether it is good to give any reference, since references in this field tend to get obsoleted fairly soon. Unless there are any more comments, I will consider this issue closed. --------------- --------------- ---------------