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

[joel jaeggli]

On 9/1/15 1:42 AM, Eric Vyncke (evyncke) wrote:
> 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?

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

> - 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
> 
> _______________________________________________
> v6ops mailing list
> v6ops at ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 229 bytes
Desc: OpenPGP digital signature
URL: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20150907/85aff703/attachment.sig>