Re: [v6ops] IPv6 EHs Packet Drops (Fwd: New Version Notification for draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt)

[Fernando Gont <[e-mail]>]

On 02/10/2016 06:52 AM, [e-mail] wrote:
>> 
>>> if we accept that e.g. a transit network needs to look into L4
>>> or deeper, then we also accept we can never make any innovations
>>> at this layer. (and we've essentially accepted that the Internet
>>> is going to be just an underlay for whatever comes next).
>> 
>> Not necessarily. There are essentially two issues here:
>> 
>> 1) The Next-Header space is not self describing. It should be
>> possible to skip past unknown EHs. I presented a proposal 
>> (draft-gont-6man-rfc6564bis-01), but we did nothing about it.
>> (there could be other alternatives, such as prohibiting the
>> specification of new EHs... but we did nothing about it).
> 
> right, it isn't clear that is solving the problem. if walking the
> chain is done by a middlebox for the purpose of "security", then it
> would be highly unlikely that it would allow an unknown extension
> header.

That's the point: you cannot tell if what's inside is an EH or an
upper-layer protocol.

If the device is whitelisting stuff, I'd agree with you on the
end-result. OTOH, if the devices means to blacklist stuff, then this may
lead to unnecessarily packet drops.

And, in any case, a bug is a bug.

We're pretending that RFC6564 can be employed to skip past unknown EHs,
when it really can't.



> for a router doing ECMP we should instead make the flow label
> usable.
> 
> what we have done, is to make it very unlikely that new extension
> headers will be defined. given that we have the three extensible
> containers, RH, DestOpt and HBH. and we might be making parsing the
> HBH optional.

Then let's say that. Right know, given an unknown Next Header, it's
impossible to tel whether it's an EH or an ULP.

I don't care if we go forward with what we propose in our rfc6564bis
I-D, or we just ban the definition of new EHs. Anything is better than
leaving the bug in.



>> 2) EH chains can be very long. Me, I'd prefer that we get to some 
>> compromise (e.g., "everyone must support EH chains of at least 256
>> bytes to be able to claim they are IPv6-ready"), rather than what
>> we have now: we pretend that nodes support the currently unlimited
>> EH chain lengths, but in practice it gets hard to pass a 10B chain
>> through.
> 
> right, but within the constraints of RFC7112. for routers that number
> is and always have been 40. :)

40B?

If it's an implementation limit, it'd be great that we all agree that
40B is the least common denominator.

Besides, whatever the number, there can be as many instances of HBH as
desired.. so even for routers, you still have to support at least
up-to-MTU long EH chains.


> for middleboxes it is dependent on
> policy, and since that could typically be to parse the whole
> packet...
> 
>>> I can't think of many examples where a transit network would
>>> require to parse the extension chain.
>> 
>> We have examples in draft-gont-v6ops-ipv6-ehs-packet-drops-02.txt 
>> (supplied by folks running such networks).
> 
> sorry, I don't see any examples there where a transit network would
> require to look deeper than 40 bytes. in the case of DDOS that would
> be filters that would match a signature, and I'd imagine that include
> extension headers right.

The examples basically boil down to happing to enforce some sort of
filters that require layer-4 info.



>> Probably the ECMP case is easier to solve in the near term. OTOH,
>> the ability to do packet filtering doesn't look easy to solve if we
>> keep the (rather onerous nowadays) requirement of supporting
>> arbitrarily-long EH chains.
>> 
>> FWIW, this is just me trying to make things work, and trying to
>> find a middle-ground between the theoretical requirements we
>> expect implementations to comply with, and the "I will drop all the
>> EH-enabled packets" that seems to be rather widespread.
> 
> right, this is simply a result of the tussle between the different
> actors on the network. if anything IETF should try to be neutral in
> that tussle.

But when we don't try to be pragmatic and agree on what is supported,
the result is not good: I'd prefer to be "limited" in the EH chains that
I can use, but to know that I can rely on e.g. up to 64B or 256B EH-chains.

Right know, since our requirement to support arbitrarily-long EHs is
generally seen as too onerous, the end result is that folks don't care
to support EHs, and hence you wouldn't even hope to have your 10B EH
chains go through the network.

I'm not even arguing about an actual modification to the spec (i.e., and
enforced upper limit), but e.g. and enforced lower limit that everyone
has to support (which could be increased overtime). -- if we really
won't EHs to be deployable.

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