This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Next message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Enno Rey
erey at ernw.de
Wed Jun 17 20:40:26 CEST 2015
Hi Tore, On Wed, Jun 17, 2015 at 08:18:09PM +0200, Tore Anderson wrote: > * sthaug at nethelp.no > > > Back to IPv6: I might allow "interesting" IPv6 extension headers > > within my own AS - because in such cases I have much more control. > > There is no way I'm going to allow IPv6 packets with long chains of > > "interesting" IPv6 header chains to pass my border routers. Either > > they have short enough header chains that my border routers can > > inspect the L4 info at line rate - or they get dropped. > > Hi Steinar, > > I wouldn't react to the above if you were operating an enterprise > network, but considering you're an ISP and transit provider, I find the > above rather surprising (and I do not mean that in a good way). > > First, your customers might have a perfectly valid reason to send or > receive IPv6 headers with IPv6 extension header chains you apparantly > will drop at your border. FWIW, if I found out that my upstream > arbitrarily dropped packets because they found them "interesting", > breaking my applications that brings us directly to the core of the debate: break "exactly which application?". there's no single application/service using EHs other than AH/ESP and, maybe in a few corner cases, FH today and I doubt we'll see some tomorrow (given developing such a thing is heavily de-incentivized by the growing number of operators mostly dropping EHs). Taking into account that stateless ACLs of all router vendors we tested (results tb published soon) can be avoided/evaded by adding ~5 extension headers to datagrams I fully understand any operator who does not want SSH on its devices to be reachable from the Internet (over v6 with extension headers) and hence acts in a way similar to the one Steinar described. I doubt Steinar loses many customers (due to "application breakage") by taking that path. In contrary I expect many of his customers valueing the increased level of device & network availability gained by eliminating an entire class of attacks. 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 =======================================================
- Previous message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
- Next message (by thread): [ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]