Oh, i see. Thank you very much for the comments Eric. Regards, Ana
Eric Levy-Abegnoli wrote: > Hi Ana, > see comments inline > On Sunday 07 September 2008 23:22:49 Ana Kukec wrote: > >> Hi all, >> >> Here are some questions about the RFC3971, there are some illogical >> paragraphs.. Answers are welcomed :-) >> >> 1. RFC3971 says about Router Solicitations: >> Section 5.1.1: If the node has been configured to use SEND, the CGA >> option MUST be present in all NS and Advertisement messages and MUST be >> present in RS messages unless they are sent with the unspecified source >> address. >> Section 5.1.2: Note that the CGA option is not used when the source >> address is the unspecified address. >> Section 5.2.2: Router Solicitation messages wihout the RSA Signature >> option MUST also be treated as unsecured, unless the source address of >> the message is the unspecified address. >> >> -> Which means that message with unspecified address, without CGA and >> signature must be treated as secured? I am aware that the router will >> not update its Neighbor Cache in this situation. But anyway, why can >> such message be treated as secured? >> > What else could the receiver do? The semantic may be bogus, but RS with > unspec > is quite commonly the first message that a node will send, before acquiring > an address. What "secure" means in that context is that the receiver must > respond. Even when instructed to be in "full-secure" mode. > And as you suggested, these messages don't create any state at the receiver. > From a "handling" standpoint, they are to be treated the same way as secured > message, even if they are not. > >> 2. RFC3971 says: >> Because authorization paths are not a common practice >> in the Internet at the time of this writing, the path MUST consist of >> standard Public Key Certificates (PKC, in the sense of [8]). >> >> -> But [8] points to Authorization certificate which does not have >> public key? >> > I don't get it. Certificate used in SEND have a public key. As well as X.509 > certifcate referred to in 3280. What beast are you talking about? > > >> 3. Isn't there Pad Length missing in the RSA Signature option? >> Section 5.2 says: >> Digital Signature >> This field starts after the Key Hash field. The length of the >> Digital Signature field is determined by the length of the RSA >> Signature option minus the length of the other fields (including >> the variable length Pad field). >> Padding >> This variable-length field contains padding, as many bytes long as >> remain after the end of the signature. >> >> -> Isn't this circular? We need Pad Length, right? >> > The length of Digital Signature can be inferred from the length > of the key modulus (that you can get from the public key in the CGA option). > > >> 4. Again, RFC3971 says: >> Section 6.3.1 says: >> The X.509 IP address extension MUST contain at least one >> addressesOrRanges element. This element MUST contain an >> addressPrefix element containing an IPv6 address prefix for a prefix >> that the router or the intermediate entity is authorized to route. >> ... >> Instead of an addressPrefix element, the addressesOrRange element MAY >> contain an addressRange element for a range of subnet prefixes, if >> more than one prefix is authorized. >> >> -> addressPrefix is first said to be MUST. And then, "instead of >> addressPrefix we may have.." >> > I don't see any ambiguity there. The way I read it is "It MUST be either A or > B". How else would you interpret it? And don't know how to better put it ... > Eric > > >> Tnx for the answers, >> Cheers >> Ana >> _______________________________________________ >> CGA-EXT mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cga-ext >> > > > > _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
