[ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers?
- Previous message (by thread): [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers?
- Next message (by thread): [ipv6-wg] [training] IP Address Space Course this November in Bucharest
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
joel jaeggli
joelja at bogus.com
Tue Sep 8 07:45:33 CEST 2015
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.ripe.net/ripe/mail/archives/ipv6-wg/attachments/20150907/85aff703/attachment.sig>
- Previous message (by thread): [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers?
- Next message (by thread): [ipv6-wg] [training] IP Address Space Course this November in Bucharest
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]