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

[Ray Hunter <[e-mail]>]

+1 Agree with Fernando. Disagree with Ran. I don't agree that this is a 
blocking factor, and believed the WG had reached rough consensus.

IMHO Initially, I was also concerned about false-positives, but after 
careful consideration I believe that if someone has chosen to implement 
RA Guard then the benefit of day 0 attack protection from 
false-negatives is worth far more than the downside of potentially 
dropping some false-positive link-local-only ICMPv6 packets.

Operational experience has proven a "drop unknown by default" rule to be 
necessary: the reason this ID was written was because previous RA-Guard 
implementations which only filtered on positive identification were 
being bypassed in the wild.

Flipping the default behaviour to "allow unknown by default" as Ran 
suggests, would IMVHO require tightening up the spec for an RA message 
so that they could always be 100% reliably parsed in all instances 
(including end host implementations) for RA Guard to remain useful, but 
that is outside the scope of the ID and would also limit future 
developments.

If as an end user you don't like this compromise, don't buy a L2 switch 
that implements RA-Guard. Or turn it off globally. Or configure the port 
to be a router port (that allows all messages).

regards,
RayH

Fernando Gont wrote:
> 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,