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

[Eric Vyncke (evyncke)]

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"
<v6ops-bounces at ietf.org on behalf of fernando at gont.com.ar> 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: fernando at gont.com.ar || fgont at si6networks.com
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>_______________________________________________
>v6ops mailing list
>v6ops at ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops