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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 24, 2021 at 9:27 AM Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
>
> On 23/2/21 13:54, Mark Smith wrote:
> > On Wed, 24 Feb 2021 at 02:51, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote:
> >>
> >> Hi, Tom,
> >>
> >> On 23/2/21 11:34, Tom Herbert wrote:
> >> [...]
> >>> >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.
> >>
> >> No, We're just stating the obvious. If we were performing a
> >> recommendation, the text would be something like "IPv6 implementations
> >> should". And we'd also be using RFC2119 speak... and the document would
> >> be BCP.
> >>
> >
> > It reads like an implied recommendation to me.
> >
> > It's stating possible prevention measures, and then the consequences
> > of not doing them. That implies the stated prevention measures are
> > recommended. (e.g. "If you aren't careful with a knife, you could cut
> > yourself (so be careful with a knife)").
>
> I think you're reading more from the draft that what we have written or
> meant.
>
> Your example is a good one, and has indeed two parts:
>
>     "If you aren't careful with a knife, you could cut yourself"
>
> This is a *fact* and I don't think there's much room for debate around it.
>
>
>    "(so be careful with a knife)"
>
> *This* is advice.
>
>
> Our document contains the former (a fact), but not the later (advice).
>
Fernando,

The analogy doesn't hold here because unlike knives, extension headers
are not inherently dangerous. The problems have been caused by some
routers implementations that have assumed unwritten requirements (like
routers must access transport layer), unquantified requirements
(header chains can't be too long), and apparently buggy
implementations (mentioned in the draft). This draft describes, cites,
recommends, references, or suggests (whichever you prefer) two
specific mitigations which are to drop packets or rate limit packets.
These mitigations are described without context or parameterization,
so the reader might infer that blindly dropping all packets with
extension headers is an acceptable mitigation. Furthermore, if the
draft is suggesting mitigations to problems created by routers, then
an obvious one would be to ask router vendors to fix their bugs (which
I am trying to say without cynicism).

Tom

> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@xxxxxxxxxxxxxxx
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux