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 16:00:32 CEST 2015
Hi, On Wed, Jun 17, 2015 at 03:41:01PM +0200, Jen Linkova wrote: > On Wed, Jun 17, 2015 at 3:33 PM, Enno Rey <erey at ernw.de> wrote: > >> I see *large* variable length headers, in combination with complex > >> parsing rules, as the problem. > > > > (*large* variable headers) exactly, plus fragmentation > > Fragmentation is not specific to IPv6, is it? right [even though I'm in the camp of "deprecate fragmentation as a whole" ;-), but let's not open this can of worms here]. BUT: fragmentation becomes a (then somewhat IPv6 specific) huge problem space once you have a datagram containing, say, 20 extension headers of partially variable lenght & pretty much arbitrary order, split into, say, 50 fragments. [again, see https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf]. Such a datagram would be fully valid as of today/RFC2460. Yes, we're aware of RFC7112. It's just: no OS we know and no devices we're aware of (feel free to provide pointers) implement RFC 7112 as of today. but many attack tools implement the techniques mentioned above. Which is why quite some operators (in particular, but not only) from enterprise and managed service provider/cloud space drop all EHs except, maybe, AH+ESP. thanks Enno And, as the fragment > header itself is just 8 bytes (AFAIR, too lazy to check ;)) - I'd not > classify it as *large* variable header. > > > and "ambiguities" wrt fragmentable vs. unfragmentable part and how headers point to the next one once there's a cut between them due to fragmentation. the, what we consider, "problem space" is much larger, unfortunately. > > Has not RFC7112 addressed this particular problem? > > -- > SY, Jen Linkova aka Furry -- 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 ]