Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01

[Fernando Gont <[e-mail]>]

Hi, Tom,

On 2/12/20 17:06, Tom Herbert wrote:
[....]
>>> In
>>> some other uses, the fact that packets with these options might be
>>> expected to be dropped by many paths - for good reasons, does not mean
>>> that the option is useless to set in general - it might merely be that
>>> for these paths it is not possible to use the option and then care is
>>> needed in deciding which packets set the EH and how this is used.
>>
>> We certainly don't mean that. We mean "if you EHs, the chances of your
>> packets being dropped increase, for the general case".
> 
> Fernando,
> 
> That's true of a lot protocols. If you use fragmentation, any protocol
> other than TCP or UDP, encryption, encapsulation, or even IPv6  your
> chances of packets being dropped increase in the general case.

I haven't seen measurements in that respect.



> In fact
> many of the reason noted in this draft for drops are the same those
> other cases. So it's generally true that any deviation from a narrow
> set of protocols and options that are known to be commonly supported
> by routers risks increased chance of packet drop

I don't think this is necessarily the case.



> I view this draft is another case of trying to document and explain
> the status quo for how routers and middleboxes implement the protocol
> (we saw the similar discussion in RFC8900 and
> draft-ietf-tsvwg-transport-encrypt-18). Documenting current real world
> behavior is good, however it needs to been in context (similar to
> concerns raised for other like drafts):
> 1) Some of the behaviors being documented are either contrary with the
> Internet architecture or downright non-conformant with the standards.
> IMO this needs to be clarified and called when discussing some
> particualar mechanism a vendor has chosen to implement. This may be
> describing current practice, but as Gorry this in no way should be
> construed as IETF best practice

This document doesn't pretend to be a BCP. For instance, we have a 
Disclaimer in that respect: 
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01#section-2



> 2) We need to realize there are potentially conflicting rrequirements.
> For instance, in this draft there is a statement "contemporary routers
> and middle-boxes that need to find the layer-4 header must process the
> entire IPv6 extension header chain.". I do not believe there is any
> core IETF standard that requires routers to access the transport
> layer, that's more a design choice vendors have made.

That depends a lot whether you're referring to the conceptual role of 
router, or to the concept of "router" as deployed in the real 
operational world.



> In fact, from a
> host perspective, we are trying to obsolete that by encrypting
> transport headers like in QUIC for instance (there are both security
> and protocol evolution motivations for doing that).
> 3) We need to very careful about making conclusions or even those that
> are inferred by the reader.

I don't think we are driving to a lot of conclusions here. Actually, 
we're elaborating on the empirical results.



> It should be very clear that this
> documenting is not advocating obsoleting extension headers nor that
> arbitrary dropping of packets with extension headers is acceptable.

That's why we have: 
https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01#section-2 
  . At the end of the day, I don't think one can do a lot better than 
that (and tweaking the document as suggested by Gorry, of course).



> 4) It would be nice to have some guidance on a way forward.

It *would* be nice. However, most of the ways forward are unrealistic. 
To name a few:

1) You can't claim you support IPv6 if you can't handle EHs of arbitrary 
length.

2) You can't claim you support IPv6 if long EH chains result in a 
performance impact.

3) You can't claim you support IPv6 if you peek at the EH chain -- 
whether you are a router, NIDS, firewall, or load-balancer

4) Dropping packets with EHs is being a bad Internet neighbor.


Re: #1-3: I guess IETF/6man would be unhappy to realize that, then, IPv6 
is not as widely implemented.

Re: #4: I guess operators will note that they ave a network to run.



> Assuming
> that the consensus is that extension headers are still useful,

FWIW, we're not making statements in that respect. We're elaborating on 
the problem at hand, and the considerations when relying on EHs.
I would assume that, at the very lest, you can leverage EHs in the 
so-called "limited domains" -- and that's what spring et al are doing.



> what can we do to increase their viablitiy?

Improved support in network devices. But that normally implies $ than 
needs to be invested by some, and payed by others.



> 5) Specific to this draft, almost all the references are at least five
> years old. For instance, RFC7872 which is considered the reference for
> measurement of EH drops on the Internet dates back to 2016. So these
> aren't really fresh and  in the case of RFC7872 that was publsihed
> before RFC8200 so it doesn't reflect the impact of the updated EH
> related requirements in RFC8200. More recent data and analysis would
> strengthen the discussion.

The only EH that was relaxed is HbH. And the numbers for other EHs are 
already bad enough. I'm not sure how that would change the reality and 
assessment.

Thanks!

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