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,

Thanks so much for your comments!

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

More comments inline...

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

(more comments below)


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


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


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

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, But
this document simply specifies how you should *implement* ra-guard, and
doesn't argue in favor (or against) its deployment.


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



>   There are existing openly specified, legitimate, IPv6 Destination
>   Options that can be somewhat large in size (notably: CALIPSO).

My take is that if you setup employs CALIPSO, and it leads to packets
with a header chain that spans multiple local MTUs, then you'd simply
not deploy RA-Guard.

That say, would CALIPSO packets really lead to IPv6 header chains that
would span past 1500 bytes, or even past 1280 bytes?


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

Please do let me know what you think...

Cheers,
-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1