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

[Joe Touch <[e-mail]>]

On 10/31/2012 11:34 AM, Fernando Gont wrote:
> On 10/31/2012 04:11 PM, Joe Touch wrote:
>> Yes, but the whole point of the IPv6 option architecture was to avoid
>> the issues seen with IPv4 options.
>
> The only thing in that IPv6 would avoid is requiring routers to parse
> *all* options, just to find the ones that need to be processed by routers.

Yes.

However, since fragmentation is near the end of the set of possible 
options, that means that ANY recommendations about how IPv6 routers 
handle options will require deep option parsing. How does that help?

> 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.

The non-HBH options can be split across fragments, but not the HBH ones.

> 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.

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

>> Consider that:
>>
>>      - routers don't like fragments because they can't inspect them
>>
>>      - so we tunnel and fragment in a higher level protocol
>>
>>          the router now needs to implement the higher protocol
>>          and still fragment or else we cannot have tunnels
>>
>>          the routers on the path still cannot inspect the
>>          higher-level fragments
>>
>> So we're back to the reason this all breaks - routers doing something
>> that we simply cannot support in the architecture.
>
> It's probably time to accept that firewalls and routers implementing
> ACLs are part of the architecture.

We need to accept one of three things:

	DPI is part of the architecture
		either don't use IPv6 options
		or don't use IPv6

	IPv6 options are part of the architecture
		DPI isn't meaningful anymore

 > One might argue that the use of
> firewalls couldn't be foreseen with IPv4. But at the time IPv6 was
> designed, it was already a reality.

So that means IPv6 was designed to inhibit the use of options, or 
designed to inhibit its own deployment.

Seems like the latter is coming to fruition.

Joe