Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation

[Fernando Gont <[e-mail]>]

Hi, Ray,

Thanks so much for your feedback! -- Please find my comments inline...

On 02/20/2012 02:45 PM, Ray Hunter wrote:
> One thing I do not find satisfactory is one of the MUST drop rules:
> 
>> 3.  If the layer-2 device is unable to identify whether the packet is
>>        an ICMPv6 Router Advertisement message or not (i.e., the packet
>>        is a fragment, and the necessary information is missing), the
>>        IPv6 Source Address of the packet is a link-local address or the
>>        unspecified address (::), and the Hop Limit is 255, silently drop
>>        the packet.
> I understand the logic of the rule. But to me this suggests that the RA
> Guard filtering mechanism may well exceed its raison d'etre of layer 2
> filtering of unauthorized RA messages. 

Filtering RA messages at layer-2 has a number of challenges:

1) RFC4861 allows fragmentation of ND packets. Even if we eventually
change this (as proposed in draft-gont-6man-nd-extension-headers),
RA-Guard must still be able to deal with the deployed base (i.e., it
could never assume that such packets will be dropped)

2) IPv6 first-fragments that do not include the entire header chain are
currently legitimate (please see
draft-gont-6man-oversized-header-chain). Therefore, an attacker could
always conceal the payload by including lots of extension headers, and
fragmenting the packets.

So the rule above should be read as:
"Pathological fragments that do not include the entire IPv6 header chain
are still legitimate (specs-wise)... we could rather ban them in
RA-Guard... but let's be more conservative, and just filter the ones
that could hurt what we are meaning to protect"

The above rule will only filter first-fragments that fail to contain the
entire IPv6 header chain (i.e., the upper-layer protocol cannot be
determined). In order to avoid false positives, we also check the Hop
Limit and the Source Address.

Note, however, that my take is that such packets would likely be
filtered by any deployed IPv6 firewalls, so legitimate traffic shouldn't
rely on them.


> I get the feeling therefore that
> the detection/definition of what is an unauthorized RA message may
> currently be underspecified. Or else the RA message itself is currently
> specified in such a way that the RA Guard filtering approach is not
> viable, as it may be circumvented by other yet-to-be-discovered cloaking
> mechanisms.

There are two different problems here, which kind of overlap:
1) Support of fragmentation in ND traffic: this should be forbidden (I'd
argue that it should be forbidden even if SEND is deployed). Supporting
fragmentation makes it much harder to produce feature parity with IPv4:
ND traffic monitoring is virtually impossible.

2) First-fragments that do not contain the entire IPv6 header chain bein
legitimate: As far as RA-Guard is concerned, if the entire header chain
is present in the first-fragment, then we can "cleanly" filter the
packets. If the header chain is split into multiple fragments, then we
must rely on the heuristics above.



> This rule we may also be in danger of heralding in a "drop all source
> <link-local-address> hop-limit 255 unless" layer-2 filter to cover a
> multitude of evils for various protocols and messages.
> 
> What other legitimate traffic would/could this rule potentially break?

As noted above, I really doubt that any protocol that relies on
"oversized header chains" (draft-gont-6man-oversized-header-chain) as
IPv6 firewalls get widely deployed -- the only way to firewall such
traffic would be to reassemble-filter-fragment... and that's undesirable
in many cases.

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