- ipv6-wg - mailman.ripe.net

Re: [ipv6-wg] [v6ops] Why operators filter IPv6 packets with extension headers?
by Eric Vyncke (evyncke) 08 Sep '15

08 Sep '15

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

4 3

Why operators filter IPv6 packets with extension headers?
by Fernando Gont 01 Sep '15

01 Sep '15

Folks, The topic of operators dropping IPv6 packets containing extension headers has been raised quite a few times on a number of mailing-lists and forums. 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 ops community 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. P.S.: If possible, please CC <v6ops(a)ietf.org> and <draft-gont-v6ops-ipv6-ehs-packet-drops(a)tools.ietf.org> when sending feedback. Thanks! Best regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

1 0

[training] RIPE NCC Training Courses October-December 2015
by Training Services 27 Aug '15

27 Aug '15

Dear colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Amsterdam, Athens, Odessa, Naples, Cardiff, Barcelona, Oslo, Bucharest, Budapest, Istanbul, Zagreb, Doha, Berlin. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - Basic IPv6 Training Course - 2 days Advanced IPv6 Training Course - Routing Security Training Course - DNSSEC Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

IGF Seeking Input: “Creating an Enabling Environment for IPv6 Adoption”
by Marco Hogewoning 24 Aug '15

24 Aug '15

Dear colleagues, As part of this year's Internet Governance Forum (IGF), an IPv6 Best Practice Forum will discuss successful approaches that encourage IPv6 adoption. To get the most out of this effort, we would like to invite you to contribute your experiences to the forum. IGF Best Practice Forums rely on input from stakeholders across the Internet community and are open to anyone who would like to contribute. The RIPE NCC and other RIRs are participating in this discussion and we hope that RIPE community members will also take part. The goal of the forum is to create a high-level document that describes successful efforts to stimulate IPv6 adoption in both the public and private sectors. An example might be the creation of a task force that coordinated to remove barriers to IPv6 adoption. The group has already created a survey aimed at IPv6 task forces, which is available here: https://goo.gl/kQhmz We would like to further invite you to share any specific examples where commercial needs were addressed, such as creating a business case to secure management support for IPv6. A dedicated public mailing list has been developed for this project, which is available here: http://mail.intgovforum.org/mailman/listinfo/bp_ipv6_intgovforum.org More information on the IGF IPv6 Best Practice Forum can be found here: http://www.intgovforum.org/cms/2008-igf-hyderabad/event-reports/78-best-pra… We invite you to contribute using the links above. If you have any questions about this effort or the IGF in general, please don’t hesitate to contact me. Kind regards Marco Hogewoning External Relations Officer RIPE NCC

1 0

Promote the use of IRC
by Daniel Baeza (Red y Sistemas TVT) 13 Aug '15

13 Aug '15

Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #ipv6 channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel

10 15

New IPv6 Tutorials Available Online
by Pedro Vaz 27 Jul '15

27 Jul '15

Dear colleagues, We are pleased to announce that two new IPv6 videos are now available as part of our growing collection of E-Learning Tutorials. You can find these here: Neighbor Discovery Protocol: https://www.ripe.net/support/training/learn-online/videos/ipv6/ipv6-fundame… 464XLAT: https://www.ripe.net/support/training/learn-online/videos/ipv6/transition-m… These videos also form part of the "Introduction to IPv6" online course that is available through the RIPE NCC Academy. If you want to join this course, you can register here: academy.ripe.net. The RIPE NCC Academy and RIPE NCC E-Learning Tutorials are a free service available to everyone. We plan to announce even more exciting E-Learning news in the coming months, so stay tuned! If you have any questions or comments, feel free to contact us at<e-learning(a)ripe.net>. Happy learning! Kind regards Pedro Vaz Trainer/Graphics Animator RIPE NCC

1 0

IPv6 martian filter-set
by Yannis Nikolopoulos 09 Jul '15

09 Jul '15

Hello, I'm not sure if people are using the fltr-martian-v6 filter set maintained by Job Snijders: filter-set: fltr-martian-v6 descr: Current IPv6 martians mp-filter: { 0000::/8^+, # loopback, unspecified, v4-mapped 0200::/7^+, # Reserved by IETF [RFC4048] 2001::/32^-, # Teredo prefix [RFC4380] 2001:db8::/32^+, # NON-ROUTABLE range to be used for documentation purpose [RFC3849] 2002::/16^-, # 6to4 prefix [RFC3068] 3ffe::/16^+, # used for the 6bone but was returned [RFC5156] 5f00::/8^+, # used for the 6bone but was returned [RFC5156] fc00::/7^+, # Unique Local Unicast [RFC4193] fe80::/10^+, # Link Local Unicast [RFC4291] fec0::/10^+, # Reserved by IETF [RFC3879] ff00::/8^+ # Multicast [RFC4291] } I'm trying to figure out why prefixes like 0200::/7 or 0400::/6 are not included in this list Any ideas? cheers, Yannis

2 2

RIPE71 IPv6 WG: call for presentations
by Jen Linkova 07 Jul '15

07 Jul '15

Dear IPv6 Enthusiasts, RIPE71 is just 4 months away and it's time to start thinking about IPv6 WG session agenda! If you would like to present, or just have any suggestions on what we should discuss) - please email ipv6-wg-chairs(a)ripe.net. If you would like to present, we need the following information: - a tentative title of your talk; - short summary - how much time you need (I'd recommend allowing 5 mins for questions). Thank you! -- SY, Jen Linkova aka Furry on behalf of IPv6 WG chairs.

1 0

Fwd: Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt)
by Fernando Gont 01 Jul '15

01 Jul '15

FYI To the extent that it's possible, please discuss the I-D on the IETF v6ops mailing-list. But feel free to discuss it here anyway (I'll monitor the list for comments). Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: Operational Implications of IPv6 Packets with Extension (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt) Date: Wed, 01 Jul 2015 17:35:11 -0300 From: Fernando Gont <fgont(a)si6networks.com> To: v6ops(a)ops.ietf.org <v6ops(a)ietf.org> CC: draft-gont-v6ops-ipv6-ehs-packet-drops(a)tools.ietf.org Folks, A group of us published a new I-D trying to summarize the operational and security implications. It is meant to summarize the reasons for which operators may intentionally drop IPv6 packets containing IPv6 extension headers. The I-D is available at: <https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops…> As far as this I-D is concerned, think of us co-authors as the messengers. The I-D doesn't argue itself whether you should (or should not) drop packets with EHs, but simply discusses the challenge they represent in some scenarios. Comments will be more than welcome. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt Date: Wed, 01 Jul 2015 13:29:21 -0700 From: internet-drafts(a)ietf.org To: Gert Doering <gert(a)space.net>, Nick Hilliard <nick(a)inex.ie>, Shucheng LIU (Will) <liushucheng(a)huawei.com>, Gert Doering <gert(a)space.net>, Warren Kumari <warren(a)kumari.net>, Will Liu (Shucheng) <liushucheng(a)huawei.com>, Fernando Gont <fgont(a)si6networks.com>, Nick Hilliard <nick(a)inex.ie>, Fernando Gont <fgont(a)si6networks.com>, Warren Kumari <warren(a)kumari.net> A new version of I-D, draft-gont-v6ops-ipv6-ehs-packet-drops-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-v6ops-ipv6-ehs-packet-drops Revision: 00 Title: Operational Implications of IPv6 Packets with Extension Headers Document date: 2015-07-01 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-packet-drops… Status: https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops/ Htmlized: https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-00 Abstract: This document summarizes the security and operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be dropped in the public Internet. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat

1 0

Extension Headers / Impact on Security Devices
by Enno Rey 26 Jun '15

26 Jun '15

Hi, hope everybody had a great #RIPE70 meeting. We did! Many thanks to the organizers and chairs! With regard to the strong position on ext hdrs that I expressed in the session yesterday pls allow to add some material/sources: - this is a paper laying out how we could circumvent some major (both commercial and FOSS) IDPS solutions in their at the time of testing latest versions, by various combinations of extension headers and fragmentation: https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-o…. - here's some thoughts and preliminary results of tests performed to circumvent stateless ACLs: http://www.insinuator.net/2015/01/evasion-of-cisco-acls-by-abusing-ipv6-dis…. http://www.insinuator.net/2015/01/the-persistent-problem-of-state-in-ipv6-s…. We have a (somewhat) ongoing research project looking more closely on the interaction of ACLs and extension headers. For the moment I can only state that it's not just Cisco who are "affected". More results will be available in some months. If the chairs consider this appropriate we will happily give a presentation on this stuff in Bucharest or at another occasion. We could even bring some devices to Bucharest to do some practical testing and demos "in some side room" during #RIPE71, for those interested. We can even do the latter without any official part in a session, if there's interest. As for the topic itself I'd like to summarize our position as follows: - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up. - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic. - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case. - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered this thesis. one can probably find much more issues provided time & resources). Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case. - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown). - now that "this vicious circle" has gained sufficient ground it will be even less incentivized to develop a compelling use case. which is why we do not expect to see one in the future. === Everybody have a great weekend and for those still in AMS: have a safe trip home! Best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

16 43