Subject: [CGA-EXT] Questions about RFC3971

From: Ana Kukec <[email-masked]>
Date: Sun, 07 Sep 2008 23:22:49 +0200

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?

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?

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?

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.."

Tnx for the answers,
Cheers
Ana
_______________________________________________
CGA-EXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Eric Levy-Abegnoli <[email-masked]>
Date: Mon, 8 Sep 2008 02:42:14 +0200

Hi Ana,
see comments inline
> 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.
> -> But [8] points to Authorization certificate which does not have
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?
 
> -> 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). 

> 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

---

From: Ana Kukec <[email-masked]>
Date: Tue, 09 Sep 2008 12:15:57 +0200

Oh, i see. Thank you very much for the comments Eric.

Regards,
Ana