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

From: <[email-masked]>
Date: Tue, 14 Feb 2012 06:55:01 -0800 (PST)

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation. Please take a look at it and comment.

---

From: Ray Hunter <[email-masked]>
Date: Mon, 20 Feb 2012 18:45:04 +0100

I have read this document. I find it well written and easy to follow. I 
also think it contains important information for the operational 
community. Thanks.

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

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?

regards
RayH

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Feb 2012 01:32:18 -0300

Hi, Ray,

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

On 02/20/2012 02:45 PM, Ray Hunter wrote:
> 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

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.

> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ray Hunter <[email-masked]>
Date: Fri, 24 Feb 2012 18:20:38 +0100

Understood. Thanks.

I also see perhaps a third way less-draconian way to help address the 
generic problem of being unable to track fragmented headers at L2 (due 
to cloaking).

The problem is as you state: "Therefore, it is impossible for a device 
processing only the second fragment to locate the ICMPv6 header 
contained in that fragment, since it is unknown how many bytes should be 
"skipped" to get to the next header following the Destination Options 
Header."

What if this uncertainty could be removed, and the amount to be skipped 
in subsequent frames was always zero, at least until the ICMPv6 RA or 
other ND message was encountered and identified?

Since fragmentation in IPv6 is host-based, it seems to me that the 
source host should always have a complete picture of the PMTU and the 
full contents of the message to be fragmented (unlike IPv4 fragmentation 
by intermediate routers, which cannot take into account message content 
in the decision of where to fragment). ND is also very likely to be 
running on a single contiguous link where the MTU is well defined and 
known directly at the interface on the source node.

So rather than banning fragments altogether for certain traffic, or 
insisting that the complete header chain resides in the first frame, why 
not specify that fragmentation should always occur at a convenient point 
so that the header chain can always be followed at L2 filters, even for 
individual frames in a fragmented packet, and thus ensure layer 2 
filtering or firewall mechanisms cannot be bypassed by "cloaking" via 
oversized headers?

Wouldn't that be as straight forward as saying individual option headers 
shouldn't be fragmented across multiple frames when transmitting RA, ND 
or other critical messages that are likely to be filtered at L2? A 
similar check could be made by receiving hosts during reassembling and 
processing ND messages to ensure that the end node knew that these 
frames could have been filtered by RA-Guard or other ND-Guard mechanism 
if necessary (if it was present).

That seems like a much less onerous restriction than the two previously 
proposed of either banning fragmentation altogether or limiting the 
total option header length to one frame.

regards,
RayH

---

From: Fernando Gont <[email-masked]>
Date: Fri, 24 Feb 2012 22:27:43 -0300

Hi, Ray,

> other ND message was encountered and identified?

Not sure what this would mean... forbidding the use of IPv6 Extension
Headers with ND packets, or something else? (if that's what you're
proposing, please see: draft-gont-6man-nd-extension-headers).

In any case, RA-Guard should be able to mitigate RA-based attacks, with
*current* implementations. So while that effort is worth pursuing, it
would not be an alternative for the current RA-Guard implementation advice.

> filtering or firewall mechanisms cannot be bypassed by "cloaking" via

Not sure what you mean by "convenient point".

That aside, banning fragmentation for ND traffic is a good thing, since
it enables ND-monitoring similar to that performed by arpwatch in the
IPv4 world (i.e., feature-parity).

> or other critical messages that are likely to be filtered at L2?

If you still allow fragmentation, it becomes virtually impossible to
monitor ND traffic -- no matter *how* you fragment.

> total option header length to one frame.

What's the difference between requiring the entire IPv6 header chain to
be prsent in the first fragment, and what you're proposing?

Thanks!

Best regards,

---

From: Ray Hunter <[email-masked]>
Date: Sat, 25 Feb 2012 10:00:34 +0100

If the base requirement for RA Guard is that is has to protect all 
*current* end node implementations then you are absolutely right, and 
there's little option but to drop all un-parseable fragments as a 
default rule. However, it should be noted in the ID what adverse effects 
this default drop rule could have on filtering legitimate traffic via 
false positives (however obscure we think the need for that traffic 
might be), because this filter would potentially be much broader than 
just RA, and people deploying RA Guard need to be properly informed of 
the potential negative consequences in advance.

Thanks
RayH

Fernando Gont wrote:
> <snip>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 25 Feb 2012 13:33:44 -0300

Hi, Ray,

On 02/25/2012 06:00 AM, Ray Hunter wrote:
> default rule. 

Agreed.

> However, it should be noted in the ID what adverse effects
> might be),

How about adding something like this below the filtering rules:

"The aforementioned filtering rules require an RA-Guard implementation
to inspect, in the case of fragments that do not contain the entire IPv6
header chain, the Source Address and the Hop Limit of the packet. This
is meant to reduce false positives that could arise if some legitimate
packets failed to include the entire IPv6 header chain. In any case, as
noted in [draft-gont-6man-oversized-header-chain], such packets are
nevertheless unlikely to survive in real networks, since (while
currently legitimate from a specifications standpoint) the are
non-sensical and are virtually impossible to police with state-less
filters (hence likely to be blocked by such filters)."

> because this filter would potentially be much broader than
> just RA, 

Not sure what you mean...

> and people deploying RA Guard need to be properly informed of

Agreed. Please let me know if the above would work, or whether I should
tweak the text a bit.

Thanks so much!

Best regards,

---

From: Ray Hunter <[email-masked]>
Date: Sun, 26 Feb 2012 11:48:42 +0100

Humbly suggest making the text a bit more neutral, and leaving the 
debate about oversized headers for another day. Also the reason that a 
packet cannot be positively identified as RA or not might be the 
presence of headers split over fragments, but it could also be something 
else (that we haven't thought of yet).

Suggested text:

In order to protect current end-node IPv6 implementations, Rule 3 has 
been defined as a default rule to drop packets that cannot be positively 
identified as RA packets or not (perhaps due to the fact that it 
contains fragments that do not contain the entire IPv6
header chain). This introduces a chance that RA-Guard filtering could 
result in false-positive blocking of some legitimate non-RA packets that 
could not be positively identified as being non-RA. In order to reduce 
the likelihood of false positives, Rule 3 also requires that an RA-Guard 
implementation check before dropping an unidentifiable packet that it 
has an IPv6 Source Address that is a link-local address or the 
unspecified address (::), and the Hop Limit is 255 i.e. it is a packet 
that should not be forwarded by a router.

In any case, as noted in [draft-gont-6man-oversized-header-chain], 
fragmented packets with oversized headers are anyway unlikely to survive 
in real networks. Whilst currently legitimate from a specifications 
standpoint, they are virtually impossible to police with state-less 
filters and firewalls, and are hence likely to be blocked by such 
filters and firewalls.

Also two dumb questions as checks:

What about packets including encryption?

RFC4861 Section 3.3 and 11.2 still specifies that IPSec may be used to 
protect ND (and thus RA)
Presume encrypted traffic offers no threat as there's protection at a 
higher layer via the security association.
But is there any clarification text required in your draft to explicitly 
cover this?
i.e. all encrypted traffic should be passed by RA-Guard, even though it 
cannot be positively identified as RA or not?

Is there any need to further clarify how RA-Guard interacts with SeND?
I don't think so, but thought I'd ask.

regards,
RayH