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

[Tom Herbert <[e-mail]>]

On Mon, Feb 22, 2021 at 11:14 AM Fernando Gont <[e-mail]> wrote:
>
> Tom,
>
> On 22/2/21 11:55, Tom Herbert wrote:
> > 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:
> >> [...]
> [....]
> >>
> >>> 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?
>
> That's not what this document is about.
>
>
> > 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".
>
> This document intentionally focuses on elaborating on the underlying
> problem, and *not* on providing such a recommendation.  We can certainly
> embark ourselves on that project once we complete this one.
>

>From the draft:

"Unless appropriate mitigations are put in place (e.g., packet
dropping and/or rate- limiting), an attacker could simply send a large
amount of IPv6 traffic employing IPv6 Extension Headers with the
purpose of performing a Denial of Service (DoS) attack"

That is clearly recommending a mitigation which is to drop packets or
rate-limit. Without any parameterization, this effectively justifies
routers to arbitrarily drop all packets with any extension headers
(rate-limiting packets makes the protocol effectively useless). Also,
if mitigations are being mentioned then the draft should also mention
the possibility that routers could be fixed, this is particularly
apropos with regards to the "DoS due to implementation errors".
Contemporary routers are trending towards being programmable so
implementation errors should be more amendable to being fixed without
hardware swap out.

Tom

>
>
> > 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).
>
> We reference such values for informative purposes. But the goal of this
> document is to provide a *qualitative* analysis.
>
> (We did include a reference for the two cited values, but our
> responsible AD suggested not to mention specific vendors/products. GIven
> your comment, I'll raise the question to him)
>
>
> > 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.
>
> As noted, that's certainly out of the scope of this document. That said,
> it would seem to me that RFC7872 is providing the kind of information
> that you seem to be looking for (modulo a recommendation).
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>