Subject: Re: [v6ops] Why operators filter IPv6 packets with extension headers?

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 1 Sep 2015 08:42:14 +0000

Fernando et al.,

A couple of quick comments:

- this reminds me of taylor-v6ops-fragdrop (which you cite at the end),
did you approach any of this old I-D authors?

- not sure whether the security implications should be re-stated again in
this document, let's rather split the security & operational issues into
two documents

- in the introduction, 'widespread implementation limitations' is probably
too strong (and I agree that my employer products could do better)

- in the introduction, "intentionally dropped" ? I am afraid that some
drop are not intentional

- I would shorten a lot the section 3 (security implications) and simply
put a lot of references to existing good documents of yours and others

- I like section 4 (operational implications) but it does not match the
title, it is more about why transit operators have to look at layer-4

- section 4 approaches the goal described in the abstract but actually
only provide clues why operators intentionally (or non intentionally)
drops packets with EH. For example, being unable to do ECMP is of course
an operational impact but why would it be the cause of EH drop?

- section 4.1 (iACL), beyond the permit/deny, some operators also rate
limit some traffic such pings

- section 4.1, perhaps worth mentioning that infrastructure ACL are more
in the white list approach, i.e., what is not BGP/ICMP (in your example)
to some prefixes is dropped, so, if someone uses EH to obscure the
traffic, this EH traffic matching the destination prefix is dropped anyway
by the ACL (so iACL works) but traffic destined to other destination is
not impacted. Or did I got something wrong?

- section 4.2 (route processor protection) is a little unclear

- the processing of HbH would kill the Internet of course (at least with
most routers), should HbH be separately called?

- section 4.3 (DDoS mitigation), I am unsure about FlowSPec but can it
also specify 'any traffic with EH' ? This would do the trick probably for
dropping or diverting the DoS packets?

- missing issue is lack of granular EH control by some routers, for
example if an operator wants to block its subscribers RH-0 but can only
drop RH (because RH type cannot be specified), then all RH are dropped
including MIPv6

- section 5 (potential attack vector) appears to be focus on fragment drop
by the public Internet. While it can probably work, the issues are
twofold: 
1) bad host implementations not doing enough tests before accepting a ICMP
packet-too-big 
2) public Internet dropping valid fragments in transit
In both cases, we (the industry, vendors + operators) need to fix those
two issues.

May I STRONGLY suggest to remove all security issues (other docs are
describing this) and focus only on the operational issues (esp in V6OPS) ?
And skip any discussion on the rationale why packets with EH are dropped?

Hope this helps to refine a potentially useful I-D.

-éric

On 1/09/15 03:17, "v6ops on behalf of Fernando Gont"
<[email-masked] on behalf of [email-masked]> wrote:

>Folks,
>
>The topic of operators dropping IPv6 packets containing extension
>headers has been raised quite a few times on this list and elsewhere.
>
>A month ago or so we published a document trying to summarize the
>reasons for which operators filter IPv6 packets containing extension
>headers. The document is available at:
><https://tools.ietf.org/id/draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt>
>
>We're currently working on a revision of this document, and would like
>to hear feedback from the working group regarding our document. e.g.,
>
>* Did we get anything wrong?
>* Is there anything missing?
>
>Or, if you like the document and agree with its content, that's also
>interesting feedback to have.
>
>Thanks!
>
>Best regards,
>-- 
>Fernando Gont
>e-mail: [email-masked] || [email-masked]
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Sep 2015 07:06:57 -0300

Hi, Eric,

Thanks so much for the timely feedback! Please find some comments inline
(more in a subsequent email)...

> did you approach any of this old I-D authors?

Warren (co-author of this I-D) was a co-author of both
draft-taylor-v6ops-fragdrop and draft-wkumari-long-headers -- but I did
not approach all co-authors of the aforementioned I-Ds. FWIW, version
-00 of our I-D is based in part on what was in version -00 of
draft-gont-v6ops-ipv6-ehs-in-real-world (before we decided to have that
one just focus on the measurements), and then discussions of this topic
on the v6ops mailing-list (mostly the input from Nick and Gert, which
was then augmented/elaborated for this I-D).

> this document, let's rather split the security & operational issues into

FWIW, the intent here with respect to the security implications was to
provide a rather high-level discussion, and provide pointers for the
interested reader. While in principle I don't object to splitting
considerations in separate documents, I'm not sure it's possible to
separate them, since the security aspect is probably one of the reasons
for which some people filter them, though.

> too strong (and I agree that my employer products could do better)

The intent here was to note that it's not a single product/vendor that
has limitations in this respect, but rather rather a more
widespread/general thing.  Do you have any suggestions on how to tweak
the text?

> - in the introduction, "intentionally dropped" ? I am afraid that some

Agreed. We noted that "...may be intentionally dropped on the public
Internet in some network deployments". i.e., some operators do filter
packets with EHs for a reason (rather than just e.g. wrong configuration
defaults of buggy boxes).

> put a lot of references to existing good documents of yours and others

This is indeed an open question. One one hand, the idea was to provide
pointers (please let us know the ones we may have missed). On the other
hand, we tried to provide some level discussion of each of the bullets
such that folks could get some idea of "what this is all about" without
digging into lots of documents.

> title, it is more about why transit operators have to look at layer-4

My mental model of this section is "We filter packets with EHs because
they prevent us from doing our job, because we need the layer-4 info...
And this is why we need that info".

> an operational impact but why would it be the cause of EH drop?

You mean other than you don't have many header fields on which to hash?

> limit some traffic such pings

Yep. Will fix.

> most routers), should HbH be separately called?

I think that'd be sensible. -- and seem to recall that there was some
I-D (RFC?) focusing on HbH? (or was it on router alert option?)

> drop RH (because RH type cannot be specified), then all RH are dropped

Good point. Will add this.

> by the public Internet.

Yes.

> While it can probably work, the issues are twofold: 

FWIW, kernel.org was vulnerable to this (before the Linux kernel was
patched to prevent the generation of atomic fragments)

> 1) bad host implementations not doing enough tests before accepting a ICMP

Agreed. However:

i) RFC4443 does not require such checks (unfortunately)

ii) Because of EHs, at least in theory you might not even have such info
available (a packet with EHs might mean that what you get in the ICMPv6
payload does not even have the layer-4 header)

> In both cases, we (the industry, vendors + operators) need to fix those

"Agreed" -- although some have argued against that (fwiw, I'm just the
messenger :-) )

> And skip any discussion on the rationale why packets with EH are dropped?

Let's hear from other folks what they think. I think that without at
least some "roadmap"/brief discussion, folks might need to dig deep into
many documents in order to grasp "what this is ll about".

FWIW, 8just me thinking out loud), I guess that one of the possible
outcomes could be to have (some reduced version of) Section 3 be a
subsection of Section 4?

Thanks!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Sep 2015 08:43:50 +1200

> On 09/01/2015 05:42 AM, Eric Vyncke (evyncke) wrote:

...
> I-D (RFC?) focusing on HbH? (or was it on router alert option?)

You're probably thinking of draft-baker-6man-hbh-header-handling,
but there's a slight conflict between that and RFC 7045, which
made a normative change to HbH by downgrading them to SHOULD:

   The IPv6 Hop-by-Hop Options header SHOULD be processed by
   intermediate forwarding nodes as described in [RFC2460].  However, it
   is to be expected that high-performance routers will either ignore it
   or assign packets containing it to a slow processing path.  Designers
   planning to use a hop-by-hop option need to be aware of this likely
   behaviour.

Also of course the next version of 2460bis will revisit this topic.

      Brian

---

From: joel jaeggli <[email-masked]>
Date: Mon, 7 Sep 2015 22:45:33 -0700

> did you approach any of this old I-D authors?

I think it's safe to say they we're all operating in the same milieu.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Sep 2015 10:12:50 +0200 (CEST)

> interesting feedback to have.

I find this document useful and agree with the content.

I think you have been able to remove most of the mentions of "filtering" 
when intent isn't there, but there is still one in the security 
considerations section (at least that's my opinion).

-- 
Mikael Abrahamsson    email: [email-masked]