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

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 10 Aug 2009 15:13:04 +0200

Hi Eric,

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 but it seems both
sections are contradictory on that aspect.

So, what is a SEND router expected to do when receiving a unsecured RS
with a Timestamp and a Nonce option?

Cheers,

a+

[1]: http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 12 Aug 2009 08:56:35 +0200

Hi,

replying to myself for the records.

[email-masked] (Arnaud Ebalard) writes:

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

Cheers,

a+

---

From: Greg Daley <[email-masked]>
Date: Tue, 18 Aug 2009 15:48:06 +1000

Hi Arnaud, 

> From: [email-masked]
> To: [email-masked]
> Date: Wed, 12 Aug 2009 08:56:35 +0200
> CC: [email-masked]
> Subject: Re: [CGA-EXT] Question about RS/RA protection w/ SEND
> 
> Hi,
> 

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

_________________________________________________________________
Looking for a place to rent, share or buy this winter? Find your next place with Ninemsn property
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Edomain%2Ecom%2Eau%2F%3Fs%5Fcid%3DFDMedia%3ANineMSN%5FHotmail%5FTagline&_t=774152450&_r=Domain_tagline&_m=EXT

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 18 Aug 2009 09:19:56 +0200

Hi Greg,

Greg Daley <[email-masked]> writes:

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

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?

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