Hi Arnaud,
> From: [email protected]
> To: [email protected]
> Date: Wed, 12 Aug 2009 08:56:35 +0200
> CC: [email protected]
> Subject: Re: [CGA-EXT] Question about RS/RA protection w/ SEND
>
> Hi,
>
> replying to myself for the records.
>
> [email protected] (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
_________________________________________________________________
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
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
