|
Hi Arnaud, > From: arno at natisbad.org > To: elevyabe-FYB4Gu1CFyUAvxtiuMwx3w at public.gmane.org > Date: Wed, 12 Aug 2009 08:56:35 +0200 > CC: cga-ext at ietf.org > Subject: Re: [CGA-EXT] Question about RS/RA protection w/ SEND > > Hi, > > replying to myself for the records. > > arno at natisbad.org (Arnaud Ebalard) writes: > > > I'd be interested by your (implementor) thoughts on the following if you > > have some time. > > > > I thought SEND specification (RFC 3971) would support the following > > scenario but in the end, it is unclear (I would say the spec is > > contradictory on that aspect): > > > > A MIPv6 MN with partial support for SEND: it supports only the > > certificate-based part of the spec and knows nothing about CGA. It is > > configured with trust anchors and supports sending RS with Timestamp > > and Nonce option. It would allow it to verify RA messages sent by > > SEND-enabled routers. One possible interest of such a mode is for > > securing the MIPv6 home link detection mechanism (see [1] for > > rationale). > > > > In the specification, we have the following: > > > > Section 5.3.3: > > > > "If the node has been configured to use SEND, all advertisements sent > > in reply to a solicitation MUST include a Nonce, copied from the > > received solicitation. Note that routers may decide to send a > > multicast advertisement to all nodes instead of a response to a > > specific host. In such a case, the router MAY still include the nonce > > value for the host that triggered the multicast > > advertisement. (Omitting the nonce value may cause the host to ignore > > the router's advertisement, unless the clocks in these nodes are > > sufficiently synchronized so that timestamps function properly.)" > > > > > > Section 8: > > > > o Unsolicited advertisements sent by a SEND node MUST be secured. > > > > o A SEND node MUST send a secured advertisement in response to a > > secured solicitation. Advertisements sent in response to an > > unsecured solicitation MUST be secured as well, but MUST NOT > > contain the Nonce option. > > > > I may have missed something in the specification ... > > Here is what I initially missed in the specification: > > Section 5.1.1: > > If the node has been configured to use SEND, the CGA option [...] > must be present in Router Solicitation messages unless they are sent > with the unspecified source address. > > Section 5.1.2: > > Router Solicitations messages without the CGA option MUST also be > treated as unsecured, unless the source address of the message is the > unspecified address. > > So, in order for my MN to get a secured RA w/ a Nonce option from a > SEND-enabled router on the link, it needs to send a RS with the Nonce > option using the unspecified address as source for its message. > > Sending such a message is authorized (as per section 5.1.1) and the > message will be considered secured (as per section 5.1.2. I should say > it will not be considered unsecured) by the receiver. As per section 8, > this will trigger the emission of a secured advertisement, which will > include the nonce option found in the RS (as per section 5.3.3). I believe the behaviour of the responding device was constrained during the security review for SEND. The issue here was the potential to generate known clear-text (the nonce) onto the network without performing any significant work. A unicast RA is not rate-limited the same way as the multicast RA, and the RAs are visible to all packet recipients. This could cause a SEND advertiser to generate multiple responses which reveal information about its private key (or hash to particular values, like the recent MD5 certificate attack). The problem with your certificate only MN is that it cannot reliably receive a quick RA in order to detect change and configure a new source address. That is because it will rely upon the Multicast delivery of packets which is strictly time separated by MinDelayBetweenRAs. While RFC3775 Identifies a smaller value for this (0.03-0.07s) this relies upon all networks using the values from RFC3775. This is not the default, and certainly not optimal for some wireless networks. In a constrained network environment though, your mechanism could work. I guess the issue is mostly one of motivation and the correct engineering solution. Why have the constraint of requiring nonces, and only certificates (not CGA) for the MN? Isn't there a way of reengineering the 3971 operations to support Certificate based devices holding Nonces? (For example, even if it is not possible to authenticate the origin of the certificate, the operations required to sign the message could be checked by the recipient router: it's not like we have a large deployed base ;) An old and dated draft which looked at using nonces for response matching is at: http://ietfreport.isoc.org/all-ids/draft-daley-dna-nonce-resp-01.txt The principle here was not to rely upon existing SEND function so much as to include a new option for the purpose of liveness proof. The draft didn't go anywhere, but perhaps it could stoke some ideas. Greg Daley Find your next place with Ninemsn property Looking for a place to rent, share or buy this winter? |