Re: [v6ops] new draft: draft-taylor-v6ops-fragdrop

[Fernando Gont <[e-mail]>]

Hi, Joe,

On 10/31/2012 04:58 PM, Joe Touch wrote:
>> While the IPv6 extension header syntax is good in terms of extensibility
>> (in principle, you can include as many options as you want, it also
>> allows for pathological cases in which the header chain is split among
>> multiple fragments (we're working on fixing that one), and also requires
>> any box that wants to find the upper-layer header to parse the entire
>> IPv6 header chain -- something that a large number of devices cannot do
>> at wire speed.
> 
> I thought we were talking more about fragmentation - which defeats
> filtering on upper layer info anyway.

Well, it's the combination of both that defeats stateless filtering.
However, please see draft-ietf-6man-oversized-header-chain.


>> For filtering purposes, it'd been interesting to have a pointer to the
>> upper-layer header -- although with the original specs, it might simply
>> not be there. With IPv4, at the very least it's trivial to find the
>> upper layer protocol: just skip the first IHL of the packet, and you're
>> there. With IPv6, at leasts in theory, it might be impossible (unless
>> you reassemble-filter-and-refragment).
> 
> In both cases fragmentation defeats DPI. But then so does IPsec.

But the two are completely different cases. With IPsec, there's a trust
relationship between the two endpoints. That doesn't necessarly mean
that you wouldn't like any DPI, though.



> Yes, IPv6's chained header structure is not DPI-friendly. But this isn't
> news, is it?

Agreed.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492