Subject: MRD and security (was Re: [magma] MRD discussion follow up)

From: Gregory Daley <[email-masked]>
Date: Thu, 04 Mar 2004 04:23:16 +0000 (GMT)

Sorry,

I know this breaks threading, but I've
only just jumped back onto the list...

Pekka Wrote:
>On Mon, 1 Mar 2004, Jim Martin wrote:
[cut]
>
>> and additional security data for 
>> authentication. 
>
>This was so vague in the meeting in the meeting that I'm hesistant to 
>do so, just that we could plug back something like this in 5 years, if 
>MRD even gets widespread deployment.

I agree that there doesn't need to be significant 
definition of this work in the current document.
Defining room for extension may be useful though.

>As you don't use ND here, with all the funkiness required -- securing 
>the traffic should be possible with IPsec easily, but of course the 
>switches won't do it.

Actually, I think that you will have the same chicken and egg
problem with bootstrapping the SAs as in SEND.
Only pre-shared keys would work with IPSec.  This doesn't sound like
a particularly robust discovery mechanism for the general case.

>Remember that there is very little security in a physical link in the 
>first place.

Indeed, so it may actually be useful if there was an
alternative, which provided some.

Certainly there may be an opportunity for even wireless
hosts to indicate that they are routers in some environments.

I'd guess that ethernet switches which wish to ensure
that multicast isn't hijacked by hosts may consider
determining authorization before treating a port as
one connected to a router.

>There seem to be some possibilities which could provide a start for a
>security at a different level.  You could suggest that the switch be
>able to verify that the L2 address of the router is X1, X2, .., XN.  
>That would move the problem to be securing Layer 2 using a number of
>mechanisms -- and when you could spoof your MAC addresses, you could
>do a lot more harm anyway, so MRDISC wouldn't be interesting anymore.

This may be an interesting idea, although you'd still
need (in the longer term) to be able to verify
authorization to use the MAC address (implying authority
to be a router).  

This would be trivial to configure on some hosts.

>> 1) Revert to the TLV option format from the previous rev of the spec, 
>> putting the Querier Interval and Robustness back into options.
>> 2) Revert to the TLV option format from the previous rev of the spec, 
>> leaving the Querier Interval and Robustness values as fixed fields in 
>> the header, and define a pad option to use for testing.
>> 3) Leave the spec as it is now, with the addition of language that 
>> specifies that any additional data beyond the fixed message length be 
>> ignored. Future extensions would then define the use of that 
>> additional 
>> data.
>
>I'd go with 3).

So would I.

>>       The security concern was that we had no clear plan on how and
when we 
>> were going to address the on-link security issue. SEND is near 
>> completion, and there's no reason the work on securing MRD using some 
>> of their models can't happen now. 
>
> Practically, SEND is not feasible for switches IMHO.

Actually, I'm not sure that I agree. 

Any switch which is sending these packets is an IPv6(or4) host.

The configuration is minimal, although the computation may be
large in verifying ND or MRD messages.

If one message is shown to be authorized by the routing
infrastructure though, a switch may keep that state for
a finite duration. Subsequently received messages may
update that state, but may not need to do so immediately, 
or may do so in a recoverable way.

For example, if no configuration information elements change
from a message which has been verified, the receiver could
start background processing the message's security while
it tentatively updated the timers.  Even if it takes some 
time at low priority to verify the message integrity
(or non-integrity) it is working off a configuration
which is already trusted.

This may lead to some temporary denial of service attacks
when the configuration has changed, but new legitimate
advertisements haven't been received.

I've got a feeling though that it's not worth securing 
MRD, unless we secure MLD (at least Queries) as well.

Greg 

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma