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

[Washam Fan <[e-mail]>]

Hi,

There is definitely theoretically false positives. But the possibility
should be very slim if rule 1-3 has been passed. Please note that only
if pass the previous 3 rules, the rule #4 would apply.

Thanks,
washam

2012/5/30 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,
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops