Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

[Fernando Gont <[e-mail]>]

Hi, Ran,

On 05/29/2012 10:02 PM, RJ Atkinson wrote:
>> -- I'm just double-checking that this is the angle from which you've
>> read the document...
> 
> Yes.  If a Layer-2 device that implements the RA Guard feature is unable 
> to discern whether a packet contains an RA or not -- then that device 
> ought to bridge/transmit the uncertain packet rather than drop it.

But that would essentially break RA-Guard's ability of mitigating
RA-based attacks...


>> To some extent, RA-Guard does firewalling at layer-2.
> 
> No.  It doesn't.  If one wants to raise the issue of options,
> optional headers, and fragmentation, then one really really
> has some Layer-3 capabilities -- or ought to.

Well, strictly speaking, one already needs some layer-3 capabilities
just to parse the layer-3 header...



>> This means that,as with stateless filtering, there's a point at which you
>> need to draw a line that says what you consider acceptable, and what not...
>> and as with layer-3 stateless firewalls, there is (at least theoretically
>> speaking) a risk of false positives. If those false positives outweigh the
>> benefits of firewalling in the first place, you simply do not deploy the firewall
>> (or in this case, RA-Guard)
> 
> Not a good comparison.  Many stateless firewalls that are widely 
> deployed transmit uncertain packets, rather than dropping them.

I didn't say "*all* stateless firewalls". That aside, I'm generally of
the idea that if you do deploy a firewall, you should do "default deny"
(rather than 'default allow').



> Separately, folks do NOT want IPv6 to be broken and balkanised
> in the way that IPv4 was.  This spec can be fixed.  The earlier
> note described a simple and sufficient fix.

People are already filtering stuff in v6. From ICMPv6, to unrecognized
extension headers.

Packets in which the IPv6 header chain spans multiple fragments already
break things such as state-less translators (which, given the level of
v6 deployment, we should expect to be able to live with for quite some
time). That aside, since they would essentially make state-less
filtering impossible, I really doubt you can assume that they will pass
stateless filters.

While, packets in which the IPv6 header chain spans multiple packets
are, strictly speaking, legitimate, I wonder whether this was actually
intended. -- Recent discussions regarding the IPv6 MTU seem to indicate
that the magic number '1280' came up from expecting the full IPv6 packet
(plus outer headers for tunnels) to fit within the the common 1500-byte
MTU. For instance, if the IPv6 header chain spans multiple packets, you
end up having more than 50% overhead...



>>>  Further, Layer-2 only devices (e.g. Ethernet bridges/switches) are 
>>>  commonly, correctly, and legitimately used to interconnect different 
>>>  segments of the same IPv6 subnetwork.  So a Layer-2 device cannot 
>>>  know whether a particular RA Advertisement is valid or not -- that 
>>>  information is simply not available at Layer-2 in a dependable way.
>>
>> I those scenarios, you either manually configure every layer-2 device in
>> an appropriate way, or you simply do not deploy ra-guard.
> 
> That doesn't work, as I noted in the original post.

Not sure what you mean. You can deploy RA-Guard only in those scenarios
in which you know that the router will be connected to a specific
layer-2 port (such that you can configure the layer-2 device to allow
RAs only on that port). If, for some reason, you cannot tell beforehand
on which layer-2 port you will connect your local router, then RA-Guard
is not appropriate for your scenario, and you shouldn't deploy/enable it.


>> Exactly. You should manually configure the device with this information,
>> *and* you should manually enable ra-guard.
> 
> However, this document doesn't require that such implementations
> even possess the capability of being configured with that data.
> So again, not a good reason.

Well, I assumed this to be a 'requirement' ("implication", if you want)
from  RFC 6105. But I agree that we might need to make this explicit in
this document -- I'd also have no problem with adding that the RA-Guard
feature should be 'off' by default, too.



>>>  Separately, in a network that contains wireless elements, routers
>>>  might connect to different Layer-2 base stations at different times.
>>>  In turn, those different Layer-2 base stations are very likely to 
>>>  connect to different Layer-2 ports on different Layer-2 switches/bridges.
>>>  Such Layer-2 switches/bridges generally cannot know that a wireless
>>>  aspect exists in the deployment.  So this is another reason that a
>>>  Layer-2 only device is not the correct place to be trying to filter
>>>  ICMPv6 RA packets.
>>
>> In those scenarios, you'd simply not deploy ra-guard.
> 
> That is not noted in Security Considerations for this document.

Good point. I'll craft some text about this, and post it for review...



>> But this document simply specifies how you should *implement* ra-guard, and
>> doesn't argue in favor (or against) its deployment.
> 
> The proposed implementation is broken.  It requires that RA-Guard
> implementations drop completely valid non-RA IPv6 packets in some 
> situations.

There's certainly a possibility of false positives (for instance, this
is already noted in the document). However, that's the trade-off for
being able to prevent RA-based attacks. And it's something that you
deploy in your local network -- not some filter that you deploy in the
middle of the network.


>>>  Removing this rule creates no new security risk as the any actual
>>>  problem packet can be detected and dropped later -- either by an 
>>>  IPv6-capable router or an IPv6-capable firewall -- one that is 
>>>  located at an IPv6 subnetwork boundary.
>>
>> How would you block malicious RAs originating from the local subnetwork?
> 
> With a real RA Guard, implemented properly, that knows it is dropping
> packets that (1) contain an RA message type and (2) are invalid.

Then you wouldn't block them. I'd just add multiple extension headers,
and fragment the resulting packet...



> The problem is with your concept of a Layer-2 only device that
> is an RA Guard.  The functions needed to make a correct determination
> about packets aren't available in (most, all) Layer-2-only devices.
> 
> Devices that implement RA Guard need to have at least sufficient 
> Layer-3 capabilities to distinguish RA packets from non-RA packets.

The only way to do RA-Guard with zero possibility of false positives is
to have the ra-guard device implement layer-3 reassembly. But since RAs
are supposed to operate on a subnet, such devices is not supposed to be
there, and hence such approach wouldn't be purist, either.


> With such correct implementations, Rule 4 being inverted is a hop.

If it's a hop, then you should decrement the Hop Limit. And the RA would
be discarded (since the Hop LImit would not be 255, as currently required).


> I know of lots of folks who'd be interested in RA-Guard, if the 
> specification weren't broken in a way that can cause valid IPv6 packets 
> that are not RA packets to be dropped.  So they would prefer the 
> inversion of Rule 4.

We essentially have to options here:

1) Have RA-Guard be effective to mitigate RA-based attacks, accepting
the fact that there's a possibility for false positives.

2) Have RA-Guard have a "default allow" policy, at which point it
becomes useless for mitigating RA-based attacks.

I have no problem with elaborating on the issue of false positives, and
being more explicit about considerations that should be made when
enabling RA-guard. But specifying a "security" devices that cannot
handle well-known evasion techniques (for which there are even publicly
available tools) doesn't seem to make much sense.


Regarding false positives: Do you have any estimates regarding how large
e.g. CALIPSO options could be in practice?



> One of the main advantages of IPv6 is that it is not currently broken
> by lots of mis-specified (pseudo-)security devices.

Well, strictly speaking, you're right: it is broken by mis-behaving(?)
devices. ICMPv6 is reportedly broken, and devices are already filtering
unrecognized headers.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492