Re: [CGA-EXT] Question about RS/RA protection w/ SEND

[[e-mail] (Arnaud Ebalard)]

Hi Greg,

Greg Daley <[e-mail]> writes:

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

My main target was the Home Network (for securing the Home Link
Detection mechanism of the MN) in which the reduced values for the
MinDelayBetweenRAs apply. But I think you are right on the following
point: relying only on multicast RA will not work well on crowdy
networks or in common environments (i.e. w/o beting able to force more
frequent response from routers). 

> 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?

Well, it took me only 3 days or so to have a basic implementation of the
mechanism (no timestamp check though) in UMIP (Linux MIPv6 daemon) and
required only to support RS (addition of nonce and timestamp) and RA
(nonce and sig option parsing and validation). Implementing (and
deploying) the CGA part can be done later but is IMHO a lot more work.

> 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 ;) 

Sorry, I fail to understand the idea. Can you give an example?

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

Thanks for the pointer.

Cheers,

a+