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

[RJ Atkinson <[e-mail]>]

On 29  May 2012, at 16:21 , Fernando Gont wrote:
> Meta-answer: This document is a BCP on how to implement RA-Guard, *not*
> a BCP that RA-Guard should be deployed. -- i.e., we're not saying
> whether you should or should not deploy ra-guard, but rather "if you
> implement ra-guard, you should do it this way".
> 
> -- 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.

> On 05/29/2012 01:38 PM, RJ Atkinson wrote:
>> 1) Layer-2 Processing Rule causes valid IPv6 packets to be dropped
>> 
>>  MULTIPLE ISSUES:
>> 
>>  Rule #4 in this document is overly restrictive.  Implementing
>>  this rule has the effect of changing the IPv6 specifications
>>  to prohibit otherwise legitimate packets that violate this new
>>  and somewhat arbitrary rule, which is an unreasonable change.  
>>  In effect, this cure (i.e. Rule 4) is worse operationally than 
>>  the potential disease.
> 
> 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.

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

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.

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

>>  Absent manual configuration that tells the Layer-2 device which ports
>>  might connect to routers, the Layer-2 device separately cannot know
>>  which "ports ... are not allowed to send ICMPv6 Router Advertisement
>>  messages".  
> 
> 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.

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

> As noted at the beginning of this e-mail, my take is that you assume
> that we're encouraging ra-guard deployment for the general case,

No I don't. 

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

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

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.
With such correct implementations, Rule 4 being inverted is a hop.
With incorrect implementations, Rule 4 being inverted ensures that
valid IPv6 packets are not dropped.

>>  PROPOSED ACTION:
>> 
>>  The current Rule #4 should be have its meaning inverted (i.e. If a
>>  Layer-2 device is unable to identify whether the packet is an ICMPv6
>>  Router Advertisement, then the packet should be transmitted without
>>  modification) and text referring to that rule also should be edited 
>>  heavily to outline the issues noted above as the reason for the
>>  "transmit if in doubt" policy for a Layer-2 device.
> 
> As noted above, this document just specifies how to implement RA-Guard,

...which specification is incomplete or wrong, as I noted in my
previous note.

> When it comes to actual deployment, there are may be trade-offs (as
> discussed above). But if you do decide to deploy RA-Guard, you probably
> do not want a "default allow" rule (because attackers would certainly
> use any of the evasion techniques described in the document)...

(ASIDE:  "Security Considerations" needs more specific and detailed 
discussion of those deployment and operational trade-offs than it has
at present.)

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.

One of the main advantages of IPv6 is that it is not currently broken
by lots of mis-specified (pseudo-)security devices.  Please change
this document so that it won't cause valid IPv6 non-RA packets to
be dropped.  Please don't break IPv6.

Yours,

Ran