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

From: Fernando Gont <[email-masked]>
Date: Fri, 02 Mar 2012 07:35:24 -0300

Hi, Ray,

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

On 02/26/2012 07:48 AM, Ray Hunter wrote:
> 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).

Well, either you have the entire header chain, or you don't... not sure
what could be the "third" option...

> 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

I've included the above text verbatim. Regardng the text below, I've
worthsmithed it a bit (see below):

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

How about rewriting this as:

"This means that, at least in theory, RA-Guard 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 that the Hop Limit is 255.

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

I've re-written this as:

  In any case, as noted in [draft-gont-6man-oversized-header-chain],
  IPv6 packets that fail to include the entire IPv6 header chain 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.

Please do let me know if all the paragraphs above are look okay....

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

If anything, I'd not write that requirement in terms of "encrypted
traffic", but rather in terms of e.g. packets employing the ESP header.
My take would be that, from the point of view of RA-Guard, ESP is
considered "the last header in the chain", and hence this would mean
that ESP packets are not filtered.

In any case, I'll create a separate thread to discuss this issue, such
that it is easier for others to weigh in.

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

There are no special rules required to interact with SeND, since SeND
traffic is not encrypted. Please let me know if you think that a comment
about this is warranted.

Thanks!

Best regards,
-- 
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, 02 Mar 2012 16:55:15 +0100

Proposed text looks fine.

> what could be the "third" option...
Just trying to avoid making any unnecessary assumptions.

For example, what about a (new) extension header for which the RA-Guard 
parser doesn't have an explicit decoder, but the end nodes do, and the 
header does not comply with 
http://tools.ietf.org/html/draft-ietf-6man-exthdr-06 ?

You may be able to see all the headers in the packet, but that isn't 
necessarily a sufficient precondition to guarantee that all RA-Guard 
implementations can parse deep enough into the packet to determine that 
the packet is definitely not an RA message.

An unlikely scenario I know, but the default drop un-parseable packets 
rule also protects this corner case.

regards
RayH

---

From: Fernando Gont <[email-masked]>
Date: Fri, 02 Mar 2012 16:45:41 -0300

Hi, Ray,

> http://tools.ietf.org/html/draft-ietf-6man-exthdr-06 ?

6man has been very clear that there have to be very good reasons for
introducing a new ext header, and in the event that happens, they new
ext header will have the TLV format specified in draft-ietf-6man-exthdr
(it's a "MUST").

So, the scenario you mention won't happen.

> rule also protects this corner case.

Exactly.

Thanks,

---

From: Washam Fan <[email-masked]>
Date: Mon, 5 Mar 2012 13:15:59 +0800

Hi Author,

I have a comment on rule#3 in section 3. It seems to me that the first
fragment which can be recognized as non-RA could pass the RA-Guard. Is
that the intent?

I think we should also drop the first fragment even it can be
recognized as non-RA, because we are going to drop the subsequent
fragments. Otherwise, there would be a DoS implication on the
receiving node.

Of course, atomic fragment should be excluded.

Thanks,
washam

2012/2/14  <[email-masked]>:
>
> 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.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Mar 2012 15:10:10 +0900

> fragments. Otherwise, there would be a DoS implication on the

So - you would like to drop all fragmented packets?

---

From: Washam Fan <[email-masked]>
Date: Mon, 5 Mar 2012 17:02:45 +0800

Hi Fred,

> So - you would like to drop all fragmented packets?

Yes. Because if you forward the first fragment and drop all the
remaining fragments, the receiving node would always receive the first
fragment but no others. Is that considered as an attack?

Thanks,
washam

---

From: Fred Baker <[email-masked]>
Date: Mon, 5 Mar 2012 18:22:09 +0900

> fragment but no others. Is that considered as an attack?

it is in IPv4 networks, and this disables a defined end-to-end IPv6 service. I think you would get comments from 6man...

---

From: Fernando Gont <[email-masked]>
Date: Mon, 05 Mar 2012 23:17:17 -0300

> fragment which can be recognized as non-RA could pass the RA-Guard. Is

Yes, of course. -- otherwise we'd be blocking legitimate fragmented traffic.

Thanks,

---

From: Washam Fan <[email-masked]>
Date: Tue, 6 Mar 2012 11:05:34 +0800

Hi Fernando,

> Yes, of course. -- otherwise we'd be blocking legitimate fragmented traffic.

My point was, you are blocking legitimate traffic eventually. For
example, if there is a non-RA datagram split into 2 fragments, you
will pass the first fragment because it is recognized as a non-RA. you
will block the second fragment because you can not recognize it as a
RA or not. I assume the non-RA datagram is shipping LL src and 255 hop
limits. The receiving node would always receive the first fragment but
no others, is that a DoS attack?

Thanks,
washam

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 00:58:13 -0300

Hi, Washam,

On 03/06/2012 12:05 AM, Washam Fan wrote:
> RA or not. 

The second fragment *can* be determined as non-RA (from the Next Header
field of the fragment header). -- Maybe I should explicitly note that
that non-first fragments should always be passed?

> I assume the non-RA datagram is shipping LL src and 255 hop

If it's a non-RA datagram, all the fragments will be passed.

If it is *not* a fragmented RA, the first fragment will be dropped, and
the rest of the fragments will be passed. This could certainly be
exploited for a DoS... but an attacker could always perform the same
attack by forging fragmented datagrams without sending one of the
fragments -- i.e., an IPv6 implementation should be able to handle this
case, already. I could add a small paragraph clarifying this in the
Security Considerations section if you think this would be
appropriate/necessary.

Thanks!

Best regards,

---

From: Washam Fan <[email-masked]>
Date: Tue, 6 Mar 2012 14:13:42 +0800

Hi Fernando,

2012/3/6 Fernando Gont <[email-masked]>:
> field of the fragment header).

Sorry, I am confused here. you don't know how many bytes should be
skipped to reach the next header, per section 2.2.

> -- Maybe I should explicitly note that

Yes, please. Then I have no confusion.
> If it is *not* a fragmented RA, the first fragment will be dropped, and

I think you meant 'if it *IS* a fragmented RA', didn't you?

> Security Considerations section if you think this would be

Yes, that would address my concern.

Thanks,
washam

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 03:48:43 -0300

Hi, Washam,

> skipped to reach the next header, per section 2.2.

Sorry, I don't really know why I wrote what I wrote. You're right about
this one.

> Yes, please. Then I have no confusion.

Great. Will clarify this and update the I-D before the cutoff. -- thanks!

> I think you meant 'if it *IS* a fragmented RA', didn't you?

Yes (it's clear I should go to bed now :-) ) -- sorry for the confusion!

> Yes, that would address my concern.

Will address this one in the next rev, then (before the cutoff).

Thanks so much!

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

---

From: Ray Hunter <[email-masked]>
Date: Tue, 06 Mar 2012 09:18:36 +0100

Thanks for your interest.

I think your cases might be clearer if rather than using the term "non 
RA datagram" you actually included a full example of the header 
properties that can be identified after parsing e.g. src address, hop 
count, fragment header present or not, ICMP header present or not.

To my understanding, I suspect what you're describing is simply a false 
positive, which comes as a side-effect risk of implementing RA-Guard, 
and is covered by the warning in the draft.

Case 1: fragmented traffic where the upper layer header is not present 
in the first fragment. Possible false positive

Fragment 1 with
i) fragment header = present & fragment offset => first fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) no ICMPv6 or TCP/UDP or other top layer header in this fragment

will be dropped by Rule 3 as it cannot be positively identified as not 
being ICMPv6 RA.

Fragment 2 with
i) fragment header = present & fragment offset => 2nd or later fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) don't care

NB TCP header or ICMPv6 header + RA message may be present in this 
fragment (but cannot be determined because the header length of the 
previous header is contained in the first fragment)

will not be dropped by Rule 3, as filtering rules are defined for 
packets. Will be passed via rule4.
Packet will fail re-assembly at the receiving end node.

So this case could well be legitimate traffic (TCP header in fragment 2) 
that ideally should not be dropped => false positive, or it could be RA 
(ICMPv6 header + RA message in fragment 2) which should have been dropped.

For RA Guard to be able to protect existing implementations you have no 
choice but to drop unidentifiable packets as the default rule.

But can you think of a use for such traffic? This is traffic that is 
limited to the link only. The nodes *know* the MTU by definition. So why 
are they sending fragments? If you can answer that then you know whether 
the false positives will be truly harmful.

There could be valid use cases of course, which is why I'd encourage you 
to think of them and discuss. NB router ports are not subject to these 
filtering rules, as they are valid sources of RA. So false positives 
would probably be end-node traffic like unsolicited service 
announcements limited to link only and sourced from the link-local 
address and where the upper-layer protocol header is not contained in 
the 1st fragment.

Case 2 : Fragmented packet where the TCP or other upper layer header is 
present in the first fragment (and it it is not RA) = nominal case of 
non-RA message passed

Fragment 1 with
i) fragment header = present & fragment offset => first fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) TCP/UDP or other top layer header present in this fragment so the 
parser can identify that this packet is not RA

will not be dropped by Rule 3 as it can be positively identified as not 
being ICMPv6 RA, and will be passed via Rule 4.

Fragment 2 with
i) fragment header = present & fragment offset => 2nd or later fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) data

will not be dropped by Rule 3 and will be passed via rule 4, as the 
filtering rules are defined for packets (not fragments).

Case 3 fragmented RA in stateless RA Guard, where the ICMPv6 header and 
start of the RA message are in the first fragment = nominal case of RA 
message blocked:

Fragment 1 with
i) fragment header = present & fragment offset => first fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) ICMPv6 RA message

will be dropped by Rule 3 as it can be positively identified as being 
ICMPv6 RA.

Fragment 2 with
i) fragment header = present & fragment offset => 2nd or later fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) data (continuation of RA message)

will not be dropped by Rule 3 and will be passed via rule 4, as the 
filtering rules are defined for packets (not fragments).
The packet will fail re-assembly at the end node and thus the RA message 
is effectively blocked.

regards,
RayH

Washam Fan wrote:
> Hi Fernando,
>
> 2012/3/6 Fernando Gont<[email-masked]>:
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 06 Mar 2012 05:40:50 -0300

Hi, Ray,

Please find my comments inline...

> will be dropped by Rule 3 as it cannot be positively identified as not
[....]
> the false positives will be truly harmful.

+1

Thanks,