Re: [Tsv-art] [v6ops] [Last-Call] Tsvart last call review of draft-ietf-v6ops-ipv6-ehs-packet-drops-05

[Tom Herbert <[e-mail]>]

On Sun, Feb 21, 2021 at 2:39 AM Fernando Gont <[e-mail]> wrote:
>
> Hello, Tom,
>
> On 20/2/21 12:32, Tom Herbert wrote:
> [...]
> > On the other hand, there are use cases where it does work and is in
> > deployment; in fact, there are use cases where it's the *only* way to
> > do in flow classification on packets. The implicit requirement of this
> > draft here is that packets have port numbers in plain text, however
> > that is not possible in no-first fragments, tunnel mode IPsec,
> > tunnling protocols the routers don't understand, etc.
>
> What we describe in our document is how this applies to the general
> case, and what the operational reality indicates.
>
> For virtually anything, you can always find a scenario where things work.
>
>
>
> > With regards to extension headers, the presumed problem isn't that the
> > port numbers are present, it's that some, not all, routers have
> > limited capabilities to parse over EHs to find the transport headers.
>
> That's a fact, rather than a presumption.
>
>
>
> > This is reflected in the statement: "If an IPv6 header chain is
> > sufficiently long that it exceeds the packet look-up capacity of the
> > router, the router might be unable to determine how the packet should
> > be handled, and thus could resort to dropping the packet." It's not to
> > me clear what "sufficiently long" means; in particular, such a
> > statement isn't helpful to the host stack developer trying to figure
> > out if the packets they're creating will be properly forwarded.
>
> "Long enough" for the router handling the packet. There are different
> vendors, and different models. S the specific value will vary across
> router vendors and models. In our document, we reference two sample
> values -- but they are certainly not the only ones.
>
Fernando,

Yes, different routers do different things, but can you quantify what
the most commonly deployed routers do? If we can do that then we could
establish a better requirement for host stacks more than just "don't
send IPv6 header chains that are too long". For instance, from the
draft: "some contemporary high-end routers are known to inspect up to
192 bytes, while others are known to parse up to 384 bytes of
header.". That's good information since it at least starts to quantify
the router implementation constraints that are mostly the subject of
this draft (this data really needs a reference by the way). If we
establish what the most common limit is, say the 192 bytes that are
mentioned, then we could establish a requirement on routers that sets
a reasonable expectation for hosts stack as to what will be forwarded
with high probability. Something like "Routers SHOULD parse at least
192 bytes of headers". The host stack in turn, can try to limit what
it sends (e.g. a 192 bytes should be a reasonable budget for most EHs,
larger ones like SR and IOAM tend to be targeted to limited domains in
which case that operator can enforce higher limits in network
devices).

Note that such a limit is a SHOULD; it's obvious that we'll probably
never achieve 100% support on the Internet. But 100% isn't the goal.
IMO, the goal is to address the problems described in this draft,
specifically the operational constraints on routers that lead to
packet drop, in order to reduce drops for packets that contain EH. The
two cited constraints in this draft are TLV processing and parsing
buffer limitations. The problems associated with constraints on TLV
processing constraints are mitigated by RFC8200 relaxing the
requirement that all intermediate nodes must process HBH, and is also
mitigated by allowing limits on the number of TLVs a node processes
(RFC8504 sets a default limit to 8). The problem associated with
parsing buffer constraints could similarly be mitigated by a suggested
limit on the length of the header buffer chain as described above.

Tom

>
> > For
> > the purpose of providing use guidance to the host stack developers,
> > can you please clarify exactly what "sufficiently long" is?  For
> > instance, is it reasonable to expect that modern routers should be
> > able forward packets that contain sixty-four bytes of Destination
> > Options, or Routing Header, or HBH Options?
>
> That's out of the scope of this document. That said, RFC7872 might help
> to answer such question.
>
>
>
> > Note that RFC8504 and
> > RFC8883 do discuss processing limits being exceeded in terms of the
> > protocol considerations (in fact, RFC8504 recommends a specific
> > default limits on the maximum number of HBH and DestOpt options a host
> > will process in order to mitigate the "DoS due to processing
> > requirements" issue raised in 7.4 of this draft).
>
> The possibility of DoS is simply described as one of the possible
> implications of EHs. As noted in the document, while there might be
> filtering policies employed to mitigate DoS attacks, in many cases
> routers resort to dropping packets containing EHs because they prevent
> the router from accessing layer-4 information the router may need to
> process to decide what to do with the packet.
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>