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

From: Gorry Fairhurst via Datatracker <[email-masked]>
Date: Thu, 18 Feb 2021 08:54:37 -0800

Reviewer: Gorry Fairhurst
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

/ Review:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/?include_text=1
——

This draft examines ops issues associated with IPv6 EHs. The document is
well-written, with an operational/security bias. The transport area interest is
primarily as a user of the potential to use an EH, and how an EH might impact
the probability of packet delivery to an endpoint.

* The ID discusses the current issues that result in EH filtering:
In this respect, the document describes challenges and mitigations based on
experience - and concludes:   “This document is not a recommendation to drop
such packets, but rather an analysis of why they are dropped”. However there is
one sentence where the text could potentially be mis-read as offering new IETF
advice, which if misread, could suggest there is no potential for a future
transport to use this, which I don’t read as the intention: /As a result,
operators usually drop IPv6 packets containing this extension header. / - There
are various ways you might consider rewording this. One way could be to say
something more like “As a result, many operators currently drop”

* The ID also discusses use of the IPv6  Flow Label: This seems a little off
topic, but seems linked to EH implications on ECMP.  However, the final
sentence of this section is a reference to [Jaeggli-2018] which in turn
concludes that the IPv6 Flow Label should not be used it as a part of hashes
for load balancing. Yet, as far as I know, this is not the recommendation of
the IETF in 2020.  This seems therefore to be an odd concluding sentence for a
section that seems otherwise to support the IETF recommendations. - This might
perhaps be easily made more neutral by moving the sentence that affirms the
IETF RFCs. i.e., moving the sentence starting “Clearly,…” to become the last
sentence in that section. —--

The remaining comments are not linked to paths, and are editorial comments/NiTs:

* Maybe the double parenthesis could be just ‘[‘ and ‘]’ rather than “([“ and
“])”?

* Reading: /(and formally forbids such fragmentation case)./ - readability
could improve by removing /case/

* A definition would be helpful for /RLDRAM/.

* There are many types and sizes of routers, is this true of all routers
(including low-end) or could this better reflect some type of routers? So,
maybe the following statements could use better words than /most contemporary
routers/? /Most contemporary routers use dedicated hardware/ … and later: /Most
contemporary routers have a fast hardware-assisted forwarding  plane/

* I suggest a more powerful chip design might not have reduced performance, but
would cost more: /but the overall performance of the system will be reduced. /
- so maybe either performance is reduced or the system cost increased?

* Insert "forward":
/to make a decision regarding which of the links to use for a given packet./
- to /use for/to use to forward/

* Typo:
/ Use of unknown extension headers can prevent an NIDS/IPS from  processing
layer-4 information/ - Add a period after, to match other items in the same
list.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2021 14:56:34 -0300

Hello, Gorry!

Thanks a lot for your review. In-line....

On 18/2/21 13:54, Gorry Fairhurst via Datatracker wrote:
[....]
> something more like “As a result, many operators currently drop”

We'll apply the suggested change.

> the IETF in 2020.  

FWIW, we discuss the Flow Label a bit because the usual reaction would 
be "why do you process the header chain for load-balancing, instead of 
employing the Flow Label?"

> This seems therefore to be an odd concluding sentence for a

We'll apply the suggested change. Thanks!

> * Maybe the double parenthesis could be just ‘[‘ and ‘]’ rather than “([“ and

Yep. Will do.

> could improve by removing /case/

Will do.

> * A definition would be helpful for /RLDRAM/.

Would a reference to https://en.wikipedia.org/wiki/RLDRAM  do the trick? 
  Or were you just suggesting to expand the acronym?

> contemporary routers have a fast hardware-assisted forwarding  plane/

You mean something like "carrier-grade router"?

> - so maybe either performance is reduced or the system cost increased?

Agreed. Will incorporate this.

> - to /use for/to use to forward/

Will do.

> layer-4 information/ - Add a period after, to match other items in the same

Will do.

Thanks a lot!

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Feb 2021 08:35:01 +1300

> On 18/2/21 13:54, Gorry Fairhurst via Datatracker wrote:
...
 
> employing the Flow Label?"

However, Gorry is right that citing Joel's operational comments is only part
of the story. I immodestly suggest citing RFC 7098 too, for a discussion
of how the flow label can in principle be used for server load balancing.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2021 17:04:51 -0300

Hi, Brian,

[....]
> of how the flow label can in principle be used for server load balancing.

Good grief! I thought we were referencing this one already (but looks 
like we're not) Any suggestion on how to reference it?

E.g., we could do:

    Thus, ECMP and Hash-based Load-Sharing [rfc6434] [RFC7098] should be 
possible
    without the need to process the entire IPv6 header chain to obtain
    upper-layer information to identify lows.

plus adding it ALONG WITH RFC6438 here:

    making Flow Label-based ECMP
    and Hash-based Load-Sharing [RFC6438] feasible.

xor add this:

   [RFC7098] discusses how the IPv6 FLow Label can used to enhance layer
    3/4 (L3/4) load distribution and balancing for large server farms.

right after:
    Thus, ECMP and Hash-based Load-
    Sharing should be possible without the need to process the entire
    IPv6 header chain to obtain upper-layer information to identify
    flows.

Alternatively, if you can think of a better way to do it, please do let 
us know.

Thanks!

Regards,

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Feb 2021 09:30:17 +0000

TSV-ART reviews are for our transport ADs's, so they will look at this 
in IETF-LC.

However, thanks really for looking into these details and for the 
changes you propose.

I can help clarify your questions below:

> employing the Flow Label?"
Thanks - I see. Brian's Carpenter's suggestion would also help avoid 
misinterpretation.
> Would a reference to https://en.wikipedia.org/wiki/RLDRAM  do the 
> trick?  Or were you just suggesting to expand the acronym?
>
>
I'd suggest to avoid the URL to wikipedia (people can easily find that - 
or a more concrete reference, but need to be certain of the term). To be 
clear, I was more expecting a simple expansion:

"Reduced Latency DRAM (RLDRAM)"
> You mean something like "carrier-grade router"?
That would be much better, or something similar that differentiates this 
from AP's, desktop routers, etc.
>> layer-4 information/ - Add a period after, to match other items in 

Best wishes,

Gorry

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Feb 2021 09:14:08 +1300

Hi Fernando,

I slightly prefer this alternative:

> or add this:

Thanks,
    Brian

---

From: Tom Herbert <[email-masked]>
Date: Fri, 19 Feb 2021 14:13:52 -0700

>     IPv6 header chain to obtain upper-layer information to identify
I don't why this is only a "should". Hashing of three tuple for load
balancing works as described as evident by the fact it is in wide
deployment (consider it's been in Linux stack for it's internal load
balancing for several years and there's now over a billion devices in
the world that do this).

Tom

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 Feb 2021 02:02:51 -0300

Hi, Brian,

>>      IPv6 header chain to obtain upper-layer information to identify

Fair enough. Will apply this one (i.e., expect it in -06).

[...]
>>      and Hash-based Load-Sharing [RFC6438] feasible.

Apologies for the caps-lock :-) Didn't see it!

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 Feb 2021 02:07:41 -0300

Hi, Tom,

On 19/2/21 18:13, Tom Herbert wrote:
[....]>> xor add this:
> I don't why this is only a "should". 

This is not a requirement. We're mostly indicating possibility.

> Hashing of three tuple for load

LB based on the FL relies on:
* Appropriate implementation of the FL
* Use of the FL in load balancers

There has been (and still is) an interesting mix of cases where one or 
both of this simply do not happen.

See e.g.: https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/

We're just the messenger here....

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 20 Feb 2021 02:57:17 -0300

Hi, Gorry,

> TSV-ART reviews are for our transport ADs's, so they will look at this 

Always keen for improvements, anyway!

[....]
> Thanks - I see. Brian's Carpenter's suggestion would also help avoid 

Cool. We'll apply both.

[...]
> "Reduced Latency DRAM (RLDRAM)"

Fair enough. I'll expand the acronym.  (I agree with you about Wikipedia)

> from AP's, desktop routers, etc.

Fair enough. I'll incorporate "carrier-grade router" unless anybody can 
come up with a better term.

Thanks!

Regards,

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Feb 2021 12:59:07 +0000

Hi Gorry,

> - so maybe either performance is reduced or the system cost increased?

The practical issue here is that on all hardware, if you increase the 
complexity of a pipeline, the performance will be reduced.  This is a 
statement of what happens in the real world on installed systems.

The purpose of this ID was to provide an practical overview of the 
real-world problems that operators are likely to experience, and why 
they happen, rather than getting into the thornier issue of analysing 
the what-ifs and wherefores of design choices.  So we deliberately 
steered clear of value judgements, including the trade-offs between 
cost, complexity and performance - there's too much scope in there to 
get lost in the long grass.

Nick

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 20 Feb 2021 13:52:11 +0000

> get lost in the long grass.

Yes, I thought that was the intention, although the current text seems 
to me to be describing a tradeoff, and the word "cost" is ambiguous in 
terms of processing resource and manufacture cost, so I agree we could 
do better. The current text says:

    Technical constraints mean that there is a trade-off
    between the amount of data sent to the lookup engine and the overall
    performance of the lookup engine.  If more data is sent, the lookup
    engine can inspect further into the packet, but the overall
    performance of the system will be reduced.  If less data is sent, the
    overall performance of the router will be increased but the packet
    lookup engine may not be able to inspect far enough into a packet to
    determine how it should be handled.

- Maybe "overall performance" isn't the right word here either.
You will know what is best - perhaps this is talking about "packet forwrading rate"?

Best wishes,

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Sat, 20 Feb 2021 08:32:28 -0700

> both of this simply do not happen.

Fernando,

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.

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.
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.  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? 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).

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Feb 2021 19:10:16 +0000

Hi Tom,

Tom Herbert wrote on 20/02/2021 15:32:
> me clear what "sufficiently long" means;

Is this just an issue of dialect?  The term "If an IPv6 header chain is 
sufficiently long that..." just means "If an IPv6 header chain is long 
enough that..."

> in particular, such a
> out if the packets they're creating will be properly forwarded.

That's something that should be addressed in a future ID.  Right now 
we're concentrating on documenting the problem.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Feb 2021 19:14:18 +0000

Gorry Fairhurst wrote on 20/02/2021 13:52:
> Yes, I thought that was the intention, although the current text
> seems to me to be describing a tradeoff, and the word "cost" is
> ambiguous in terms of processing resource and manufacture cost, so I
> agree we could do better.

We couldn't avoid it completely.  The explanation there was minimal and 
was included to help the reader understand what was going on.

> - Maybe "overall performance" isn't the right word here either. You
> will know what is best - perhaps this is talking about "packet
> forwrading rate"?

Yep - "packet forwarding rate" works, and is clearer.  Thanks!

Nick

---

From: Tom Herbert <[email-masked]>
Date: Sat, 20 Feb 2021 12:46:13 -0700

> we're concentrating on documenting the problem.
Nick,

Maybe so, but without further details I believe the way the problem is
being documented is ambiguous and unenlightening. Besides, there has
already been work in this area that really could be cited here. For
instance, in RFC8883 the different ICMP errors reflect several
different ways and provide a lot more detail as to why nodes might
drop packets because headers are "too long". That RFC lists the
priority of ICMP errors as:

 1.  Existing ICMP errors defined in [RFC4443].
 2.  "Unrecognized Next Header type encountered by intermediate node"
 3.  "Extension header too big"
 4.  "Option too big" for length or number of consecutive padding
options exceeding a limit.
 5.  "Option too big" for the length of an option exceeding a limit.
 6.  "Too many options in an extension header"
 7.  "Extension header chain too long" headers exceeding a limit.
 8.  "Too many extension headers"
 9.  "Headers too long"

Numbers 3-8 represent reasons why nodes might drop a packet with
extension headers. Number 9 encompasses those cases where a node
parses beyond the IPv6 headers chains (for instance a node that parses
into GRE encapsulation).

Give that these classes are documented, then the obvious question is
what are the common limits that should work. RFC8504 does this for
some of the limits that are more apropos to the host; hopefully, an
outcome of this draft will define some practical limits for routers
and set some expectations about what should work.

Tom

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 20 Feb 2021 20:26:51 +0000

Hi Tom,

> and set some expectations about what should work.

Definitely that would be good material for a future ID.  This aim of 
this draft is:

>    This document summarizes the operational implications of IPv6
>    extension headers specified in the IPv6 protocol specification
>    (RFC8200), and attempts to analyze reasons why packets with IPv6
>    extension headers are often dropped in the public Internet.

I'd love to see some future discussion about reasonable lower limits 
that we could expect manufacturers and software authors to aim towards, 
but it's out of scope for this draft.

Nick

---

From: Fernando Gont <[email-masked]>
Date: Sun, 21 Feb 2021 03:56:59 -0300

Hello, Tom,

On 20/2/21 12:32, Tom Herbert wrote:
[...]
> 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.

> limited capabilities to parse over EHs to find the transport headers.

That's a fact, rather than a presumption.

> 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.

> For
> 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

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,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 Feb 2021 07:55:42 -0700

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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Feb 2021 15:23:04 +0000

Tom,

We're talking at cross-purposes here. This is a descriptive 
Informational draft.  Its aim is to describe a specific problem set 
relating to an ipv6 protocol component.

Tom Herbert wrote on 22/02/2021 14:55:
> send IPv6 header chains that are too long".

... which proposes to turn the draft into a prescriptive draft, i.e. to 
advise on what protocol implementers should do.

We totally get the value proposition of what you're suggesting, but it 
doesn't belong in this draft.  Establishing workable limits is both 
difficult and subjective, which is why our proposal is that it should be 
in a future draft which would probably end up being a BCP.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 Feb 2021 09:29:24 -0700

Nick,

I understand the purpose of the draft, however, IMO, for the problems
that are described there is insufficient detail and scope to draw any
meaningful conclusions or take away any new insights. When the draft
mentions that routers might drop packets because packets are too long,
then the obvious question is what exactly is too long. Since this
draft is discussing real implementation and not theory, it seems like
measuring the extent and determining the real operational parameters
of the problems, like what a useful minimum length of header chains
is, seems straightforward either by experimentation or simply polling
router vendors to see what they support. Similarly for scope, of all
the reasons listed in the draft what is the rate of occurrence? Is
header chain length the biggest reason for drops or is it something
else? Again that's something that seems eminimetly measurable and
doesn't have to be left to the abstract which this draft seems content
to do.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2021 14:33:29 -0300

Tom,

[....]
> meaningful conclusions or take away any new insights.

Then I guess we disagree. One of the most commonly questions asked in 
this contact is "But... why do routers look inside packets?" -- and this 
document answers that question, along with the challenges it represents.

Note: in a thread on specific transports you also asked what information 
routers process. And this document also answers such question.

> When the draft
> then the obvious question is what exactly is too long.

And the obvious answer is that that depends on a vendor/model basis. If 
the router only copies the mandatory header to a buffer, then "too long" 
might be "1 EH".

> Since this
> router vendors to see what they support.

It performs a qualitative analysis of the problem.

What you ask seems to be either RFC7872bis, or a document that would 
complement RFC7872.

... but certainly out of the scope of this document.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2021 14:24:17 -0300

Tom,

[....]
> the most commonly deployed routers do? 

That's not what this document is about.

> If we can do that then we could

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.

> For instance, from the
> 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
> 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,

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Feb 2021 18:25:34 +0000

Tom,

> router vendors to see what they support.

This issue has already been addressed by Rob Wilton in his AD review:

https://mailarchive.ietf.org/arch/msg/v6ops/iqtpqSIRolTWMbMVIpm-gcoo8qM/

The review is valid.  Behaviour of this form is dependent on just about 
everything from the router model, to the line card model, to the ASIC / 
NPU deployed, to the firmware or software version running on the 
forwarding device.  A general description is adequate for the purposes 
of this draft.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Mon, 22 Feb 2021 12:17:10 -0700

Fernando,

If you recall, I specifically asked for the _normative_ requirements
about what a host must expose to the network beyond just the IP
headers. If the normative requirements are such that that hosts MUST
expose transport ports (assuming consensus is achieved for that), then
it follows that we'll need the normative requirements for how deep in
the packet those transport headers can be.

Tom

---

From: Fred Baker <[email-masked]>
Date: Mon, 22 Feb 2021 11:40:17 -0800

Happy to be wrong, but I think we already have those. From the security header on, any network device should assume that the message content is (or may be) encrypted, and make no policy requirements beyond that point. If a message contains no security header but policy makes a network device stop where it might be found, I think we have achieved the goal.

Sent from my iPad

> On Feb 22, 2021, at 11:17 AM, Tom Herbert <[email-masked]> wrote:
>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 22 Feb 2021 22:44:43 +0000

Tom,

> the packet those transport headers can be.

this has been addressed already: the draft does not set out to assess or 
specify normative requirements for transport headers.  There doesn't 
seem to anything left to address on this issue.

Nick

---

From: Tom Herbert <[email-masked]>
Date: Tue, 23 Feb 2021 07:34:04 -0700

>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

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 12:26:03 -0300

Hi, Tom,

On 23/2/21 11:34, Tom Herbert wrote:
[...]
> 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.

> Without any parameterization, this effectively justifies

This is document does not provide any sort of advice. It's an analysis 
of which packets may get dropped.

What you are asking could indeed be interesting -- but it's certainly 
out of the scope of this document.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Feb 2021 03:54:49 +1100

> should". And we'd also be using RFC2119 speak... and the document would

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)").

If you don't want it to read like a recommendation, the prevention
measures should be taken out, and just state the action and the
consequences e.g. something like:

"It is possible for an attacker to send a large amount of IPv6 traffic
employing IPv6 Extension Headers with the purpose of performing a
Denial of Service (DoS) attack."

That leaves it to the reader to work out how to prevent or mitigate
the consequences if they consider it to be an issue.

Regards,
Mark.

---

From: Joseph Touch <[email-masked]>
Date: Tue, 23 Feb 2021 14:59:03 -0800

> On Feb 23, 2021, at 8:54 AM, Mark Smith <[email-masked]> wrote:
> 
> Denial of Service (DoS) attack.”

FWIW, it would be nice if these sort of “current implementations don’t keep up” docs said more like “ALWAYS support EHs, but with lower rates as the length increases”, so we don’t end up limiting ourselves based on current implementations.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 13:26:35 -0300

> 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).

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Wed, 24 Feb 2021 10:01:28 -0700

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 14:22:50 -0300

Tom,

> I am trying to say without cynicism).

It seems that your mis-interpreting our document.

Abstract

It is an operational document produced by v6ops, and not a protocol spec 
produced by 6man. It is aimed at operators. And, if anything, the IETF 
can make use of it for further work.

It discusses challenges that are faced in the real world, from an 
operational perspective, discussing the things an operator may have at hand.

We don't provide recommendations. We don't even mean to.

Thanks,

---

From: Joseph Touch <[email-masked]>
Date: Wed, 24 Feb 2021 09:28:43 -0800

> On Feb 24, 2021, at 9:01 AM, Tom Herbert <[email-masked]> wrote:
> 
> are not inherently dangerous

Right, and any recommendation should even avoid “3 EHs are OK but 4 are not”.

The answer is that the longer the EH, the higher the risk, but any fixed limit to EHs needs to be done as a standards-track update to IPv6.

This sort of “warning about how people do it” stuff has to be tempered with the fact that this is a snapshot in time.

Joe

---

From: Mark Smith <[email-masked]>
Date: Thu, 25 Feb 2021 07:47:04 +1100

> I think you're reading more from the draft that what we have written or

As a native English speaker, I'm just saying how this text reads to me.

Reading that text, I'd start thinking about how I put in place packet
dropping or rate-limiting to stop this DoS. Those may not be the only ways
to mitigate this issue, however since it has been suggested, I would assume
it is the best way, and I think most people would, because people place
more weight on stated options over unstated options.

The long term result will be that it will be common for packets with EHs to
be dropped or there is rate-limiting on them.

If you still want to mention packet dropping or rate-limiting, then you're
going to have to further clarify be when or when it isn't appropriate, and
also should mention other mitigations if they exist

e.g.

"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. In a controlled and trusted network, a DoS attack may not be
likely or a concern, since the attacker is more easily identified and
halted. In an untrusted network, where a DoS attack is more likely,
mitigations such as packet dropping and/or rate- limiting, or other
mitigations, may be necessary."

That's well and truly further down the advice path, however, realise that
all I've done is expanded on what was already the advice in the text.

>    "(so be careful with a knife)"

The preventative advice appeared twice, firstly at the front, just to
follow the format of the text we're looking at - it's the "be careful"
part. I put the 2nd instance of the advice in to emphasise it was the
advice part, and in brackets because it's optional text and I normally
wouldn't say or write it.

"You can cut yourself with a knife, therefore you should be careful." is
where the advice is at the end.

If you are careful, you can still cut yourself with a knife. So the fact is
a knife can cut, the advice is be careful, whether or not it appears before
or after the fact about knives.

Regards,
Mark.