Subject: [Tsv-art] Tsvart last call review of draft-ietf-opsec-ipv6-eh-filtering-06

From: Michael Scharf <[email-masked]>
Date: Fri, 23 Nov 2018 11:53:43 -0800

Reviewer: Michael Scharf
Review result: Ready

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.

I have reviewed draft-ietf-opsec-ipv6-eh-filtering-06. There are no apparent
transport issues. The proposed filtering could slow down the deployment of
experimental protocols that use IPv6 options, but the tradeoffs are explained
in the document.

Thanks

Michael

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Nov 2018 09:04:19 -0800

Equally worrisome that this doc appears to make recommendations that imply BCP, when it is merely informational.

IMO, it’s overstepping to do so.

Joe

> On Nov 23, 2018, at 11:53 AM, Michael Scharf <[email-masked]> wrote:
> 
> Reviewer: Michael Scharf
> Review result: Ready
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Nov 2018 09:21:52 +1300

> IMO, it’s overstepping to do so.

Possibly, but it's not forbidden by rule, as far as I know. However, the
draft is inconsistent in its use of SHOULD vs should (see my previous
message for an example of a lower case should which might or might not
be intended pseudo-normatively).

    Brian

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Nov 2018 12:59:58 -0800

The problem is operators using this advice as if it were BCP - and later docs treating the suggestions as recommended advice. 

This treats everything unknown as an attack (a disease I’ve noted in many similar docs for years), where it should also consider that doing so is *itself* an attack on the very flexibility we design in as standard. 

We really need to do a better job of not letting informational docs get out of hand this way. 

Joe 

> On Nov 24, 2018, at 12:21 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Nov 2018 22:08:10 -0300

> be intended pseudo-normatively).

Ack. We will make sure there's consistent use.

Thanks!

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 24 Nov 2018 22:13:46 -0300

Joe,

> This treats everything unknown as an attack (a disease I’ve noted in many similar docs for years), where it should also consider that doing so is *itself* an attack on the very flexibility we desig…

This is the reality: RFC7872.

We should consider claiming vitory if somehow people were to follow the
advice in this draft.

This is what happens in the operations camp:
https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops-03-

Ironically, the possible harm you apparently see behind this document
is, from an operations-reality pov, kind of a very idealistic take. --
the situation right now is that you cannot use EHs reliably on the
Internet. If if you even expect non-standardized EHs to go through,
then, while nice, that expectation really needs a reality-check.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sat, 24 Nov 2018 22:24:55 -0800

The reality is that standards are not followed, agreed. That does not imply that we need to relax those standards - instead, it can be reason to fix broken devices. 

Working at the level of the most broken device is no way to run a production Internet.

And claiming that doing so is appropriate for security reasons is just as broken, as it always has been.

Joe

> On Nov 24, 2018, at 5:13 PM, Fernando Gont <[email-masked]> wrote:
> 
> Joe,
>

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 25 Nov 2018 12:59:55 +0000

Joe Touch wrote on 25/11/2018 06:24:
> The reality is that standards are not followed, agreed. That does not
> imply that we need to relax those standards - instead, it can be
> reason to fix broken devices.
> 
Joe,

another point of view would be that operator feedback should be welcomed 
because sometimes protocols are found to be difficult to implement 
fully, or when implemented fully cause unforeseen consequences.  EHs are 
a good example of this.  When originally conceived - for the best of 
intentions - the spec was sufficiently loose that they were not just 
unimplementable from a practical point of view, but the spec was open to 
protocol level security problems.  RFC7112 describes some issues 
relating to EHs, but there are plenty of other examples.

How, where and when to filter EH packets creates a bind, no doubt about 
it. Some EHs are intrinsically troublesome (e.g. anything with hbh 
processing requirements); others can be processed without issues.  The 
IETF can choose to ignore this problem or get involved and have some 
influence about what might constitute best practice.  If this happens, 
vendors might even fix some of their silicon.  Declaring that the 
problem exists only on one side won't make the Internet better.

Nick

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 07:53:43 -0800

A reasoned discussion of the pros and cons would be useful.

What we have is the perspective, often heavily represented by vendors and operators, of the driving reality that:

a) implementing extended features is an attack on profits
b) properly configuring and monitoring extended features is an attack on effort

A reasoned argument would be useful. That is not what has been repeatedly presented, IMO.

Joe

> On Nov 25, 2018, at 4:59 AM, Nick Hilliard <[email-masked]> wrote:
> 
> another point of view would be that operator feedback should be welcomed because sometimes protocols are found to be difficult to implement fully, or when implemented fully cause unforeseen consequences.  EHs are a good example of this.  When originally conceived - for the best of intentions - the spec was sufficiently loose that they were not just unimplementable from a practical point of view, but the spec was open to protocol level security problems.  RFC7112 describes some issues relating to EHs, but there are plenty of other examples.
> 
> How, where and when to filter EH packets creates a bind, no doubt about it. Some EHs are intrinsically troublesome (e.g. anything with hbh processing requirements); others can be processed without issues.  The IETF can choose to ignore this problem or get involved and have some influence about what might constitute best practice.  If this happens, vendors might even fix some of their silicon.  Declaring that the problem exists only on one side won't make the Internet better.
> 
> Nick
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2018 08:40:25 +1300

> A reasoned argument would be useful. That is not what has been repeatedly presented, IMO.

I don't think that's entirely fair to RFC7045. But the fact is that
there's a tussle here between the desire for the ability to deploy
new protocols freely, and the desire for the ability to block
potentially harmful or malicious traffic. The definition of "harmful
or malicious" is not universally agreed. "Harmful to my business model"
is certainly one possible interpretation. But then, we decided to
implement the Internet as a largely unregulated competitive system,
so we got tussles.

As far as I can tell, there is nothing much that the IETF can do about
this.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 11:59:51 -0800

We can - and should - push back. Not all RFCs need to be published.

Joe

> On Nov 25, 2018, at 11:40 AM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 12:40:03 -0800

> implement the Internet as a largely unregulated competitive system,

I am concerned that this draft is attempting to weight the scales and
favor one side of this ongoing tussle, which leads to something like
"ossification in the name of security". I think that's a huge overreach.
I would like to have a very general caveat at the beginning of the
draft, explaining that it is perfectly fine to deploy routers that do
not perform any such filtering and simply forward the packets. We need
something significantly more forceful than merely saying that the short
statement in section 2.3.

The policies that it describes are plausible for specialized filtering
devices such as firewalls, but the draft proposes adopting these
policies for "transit routers", an ill defined term that could cover
pretty much every router in the the Internet. There is a big difference
there. Security devices are engineered to implement specific policies,
and come with management systems to update these policies over time.

Nick made that point, probably unintentionally, when he wrote that
"transit operators would generally take the view that any data-plane
packet which needs to be put through a slow path will be rate limited up
to 100% loss". Last I checked, data plane processing is implemented in
specialized components that are designed for speed. I am quite concerned
that filtering recommendations made by the IETF will end up deeply
embedded in the hardware of at least some routers, and that changing
them in the future would be quite hard. That's pretty much the recipe
for ossification.

I am also concerned that the filtering is justified by "security
considerations", but that with the exception of the HBH header these
considerations apply to end points, not to transit router. Take the
example of the experimental options, described in section 3.4.10. The
consideration says that "implications of these EHs will depend on their
specific use." It fails to mention any security consequence for the
transit router that would fail to filter these options. In the absence
of filtering, the packets will arrive at the end system, where they will
be processed if the end system is part of the experiment, or treated as
unwanted traffic if the end system is not part of that experiment. There
definitely will not be any harmful effect for the router that passed the
traffic.

I understand that unwanted traffic can be used in denial of service
attacks. But then, any traffic profile can be used in such attacks. The
attacker who can inject packets with EH=253 can also, for example,
inject arbitrary TCP segments, or spoofed EH packets. I also understand
the desire to protect end systems from unwanted traffic. There is a
history of attacks performed by various kind of "magic packets" that
cause a catastrophic failure in some target systems. But it does not
follow that such protection should be implement by coarse policies
hardwired in every router on the Internet. The definition of these
attacks changes over time, and it would be folly to implement these
rules in systems that lack management capabilities. The proper place for
that is specialized security functions, not in general purpose routers.

I am also concerned that the draft does not define the difference
between EH options and IPv6 payload types. The IPv6 header contains a
"payload type" field, that may legitimately contain any of the payload
types defined in the IANA registry of protocol numbers
(https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml).
Some of those payload types are flagged as IPv6 extension header types
and listed in the corresponding registry
(https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml).
Discussing EH without discussing the other payload types seems bizarre.
Do the reasons for blocking for the experimental payload type 253 also
apply to, for example, the UDP Lite payload type? What about discussing
ESP and not discussing L2TP or MANET?

-- Christian Huitema

-- Christian Huitema

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 25 Nov 2018 22:11:12 +0000

Christian Huitema wrote on 25/11/2018 20:40:
> specialized components that are designed for speed.

I was talking specifically about dfz transit routers, not edge devices 
or firewalls. There are exceptions to fast-path processing where 
data-plane packets are punted to management plane CPUs for generalised 
processing rather than being forwarded by the ASIC / NPU due to hardware 
inability to process the packets correctly (e.g. gigantic EH chains), or 
by protocol specification (e.g. hbh).  What I said previously referred 
to control plane rate limiting of these types of data plane packets.

Nick

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Nov 2018 15:01:22 -0800

On 11/25/2018 2:11 PM, Nick Hilliard wrote:
>> packet which needs to be put through a slow path will be rate limited
>> up to 100% loss". Last I checked, data plane processing is
>> implemented in specialized components that are designed for speed.
>
> processing rather than being forwarded by the ASIC / NPU due to
> hardware inability to process the packets correctly (e.g. gigantic EH
> chains), or by protocol specification (e.g. hbh).  What I said
> previously referred to control plane rate limiting of these types of
> data plane packets.

I understand the limitation. My point is simply that a DFZ router with
such limitations has little business implementing filtering by payload
type. It is more likely to generate trouble tickets because
communication broke rather than praise because some unwanted traffic was
filtered in transit, rather than at ingress or egress.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Nov 2018 14:31:28 +1300

> filtered in transit, rather than at ingress or egress.

In that case it seems that this section of the draft needs attention:

2.2.  Applicability Statement

   This document provides advice on the filtering of IPv6 packets with
   EHs at transit routers for traffic *not* explicitly destined to such
   transit routers, for those cases in which such filtering is deemed as
   necessary.

       Brian

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Nov 2018 21:16:23 -0800

The core problem with this doc, IMO, is that:

- packets that cannot be distinguished from legitimate traffic MUST NOT be inferred as an attack

- the use of resources appropriate for legitimate traffic MUST NOT be interpreted as a vulnerability for that reason alone

I.e., most of the analysis in this document is flat out incorrect in assuming that merely because a packet could cause a router to do work that it is a security risk to handle that packet as intended.

Joe

> On Nov 25, 2018, at 12:40 PM, Christian Huitema <[email-masked]> wrote:
> 
> 
> I am concerned that this draft is attempting to weight the scales and favor one side of this ongoing tussle, which leads to something like "ossification in the name of security". I think that's a huge overreach. I would like to have a very general caveat at the beginning of the draft, explaining that it is perfectly fine to deploy routers that do not perform any such filtering and simply forward the packets. We need something significantly more forceful than merely saying that the short statement in section 2.3. 
> The policies that it describes are plausible for specialized filtering devices such as firewalls, but the draft proposes adopting these policies for "transit routers", an ill defined term that could cover pretty much every router in the the Internet. There is a big difference there. Security devices are engineered to implement specific policies, and come with management systems to update these policies over time. 
> Nick made that point, probably unintentionally, when he wrote that "transit operators would generally take the view that any data-plane packet which needs to be put through a slow path will be rate limited up to 100% loss". Last I checked, data plane processing is implemented in specialized components that are designed for speed. I am quite concerned that filtering recommendations made by the IETF will end up deeply embedded in the hardware of at least some routers, and that changing them in the future would be quite hard. That's pretty much the recipe for ossification.
> 
> I am also concerned that the filtering is justified by "security considerations", but that with the exception of the HBH header these considerations apply to end points, not to transit router. Take the example of the experimental options, described in section 3.4.10. The consideration says that "implications of these EHs will depend on their specific use." It fails to mention any security consequence for the transit router that would fail to filter these options. In the absence of filtering, the packets will arrive at the end system, where they will be processed if the end system is part of the experiment, or treated as unwanted traffic if the end system is not part of that experiment. There definitely will not be any harmful effect for the router that passed the traffic.
> I understand that unwanted traffic can be used in denial of service attacks. But then, any traffic profile can be used in such attacks. The attacker who can inject packets with EH=253 can also, for example, inject arbitrary TCP segments, or spoofed EH packets. I also understand the desire to protect end systems from unwanted traffic. There is a history of attacks performed by various kind of "magic packets" that cause a catastrophic failure in some target systems. But it does not follow that such protection should be implement by coarse policies hardwired in every router on the Internet. The definition of these attacks changes over time, and it would be folly to implement these rules in systems that lack management capabilities. The proper place for that is specialized security functions, not in general purpose routers.
> 
> I am also concerned that the draft does not define the difference between EH options and IPv6 payload types. The IPv6 header contains a "payload type" field, that may legitimately contain any of the payload types defined in the IANA registry of protocol numbers (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml>). Some of those payload types are flagged as IPv6 extension header types and listed in the corresponding registry (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml <https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml>). Discussing EH without discussing the other payload types seems bizarre. Do the reasons for blocking for the experimental payload type 253 also apply to, for example, the UDP Lite payload type? What about discussing ESP and not discussing L2TP or MANET? 
> -- Christian Huitema
> 
> -- Christian Huitema
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Nov 2018 04:21:06 -0300

Christian.

On 25/11/18 17:40, Christian Huitema wrote:
[.....]
> "ossification in the name of security". I think that's a huge overreach.

Not really. If that was the case we'd probably say "drop all EHs you see
no use for". If you look at the advice, it esentially argues in favor of
passing everything unless the traffic is known to be harmful.

> them in the future would be quite hard. That's pretty much the recipe

PLease take a look at the advice: it essentially argues "pass everything
that has been stadardizez and that will not cause you pain". And, again,
this is in line with RFC7045.  Compare that with what we have in the
real world (RFC7872), and you'll probably agree that if folks were to
implement this advice, it would be a *huge* improvement -- at the time
of this writing you cannot even use ipsec reliably on the Internet(!).

> that is specialized security functions, not in general purpose routers.

RFC7872 seems to argue that there are folks filtering these in transit
routers.

> between EH options and IPv6 payload types.

You mean EH types and upoer layer payloads?

> The IPv6 header contains a
> (https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml). Discussing
> EH without discussing the other payload types seems bizarre. Do the
> reasons for blocking for the experimental payload type 253 also apply
> to, for example, the UDP Lite payload type? What about discussing ESP
> and not discussing L2TP or MANET?

This document discusses EHs. THe considerations for filtering on upper
payloads are rather different, and normally depend on the upper protocol
details. (e.g. TCP ports).

As noted in draft-gont-v6ops-ipv6-ehs-packet-drops, EHs can mess up with
the ability of intermediate devices to do their work.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 26 Nov 2018 04:54:32 -0300

Joe,

> And claiming that doing so is appropriate for security reasons is just as broken, as it always has been.

This document is a product of the opsec working group. As such, it talks
about what you can do with what you have.

Blaiming vendors, even if warranted, is not something that is going to
change what an operator may do with these packets.

If, e.g., what you want to is that vendors provide full (hardware)
support for all EHs, then the way to go would probably be to have 6man
publish a document saying that implementations without such support
should not claim they support IPv6. In such case, I wonder how many of
those "ipv6-enabled" boxes we'd have ... and then probably we'd
decide that that would not be politically-convenient, and prefer to look
elsewhere.

What this doc tries to do is to analyze the possible effects of
different types and options, and only advice to drop them when there is
a clear reason to do so. If you go through all the types we discuss,
you'll see that, for the vast majority, the advice is "pass it".

---

From: Gert Doering <[email-masked]>
Date: Mon, 26 Nov 2018 08:57:46 +0100

Hi,

> I.e., most of the analysis in this document is flat out incorrect in assuming that merely because a packet could cause a router to do work that it is a security risk to handle that packet as intend…

And then IETF wonders why operators do not feel like time spent on
providing their input to IETF WGs is well-spent.

What else can it be, on a real-world device, in today's Internet?

Gert Doering
        -- Operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2018 06:32:43 -0800

> On Nov 25, 2018, at 11:57 PM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

The failure of a device to run as advertised or the failure of an operation to select the an appropriate device.

Operators that want to conserve resources without cause are welcome to run their routers inside glass boxes in museums.  Routers do work. Packets cause that work. That work is not an attack unless it is *disproportionate*. That is not shown for nearly any of the cases in this document.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2018 06:36:09 -0800

> On Nov 25, 2018, at 11:54 PM, Fernando Gont <[email-masked]> wrote:
> 
> a clear reason to do so.

It claims those actions based on security. This is not a security issue. It is a revenue preservation issue.

There is a big difference between using a protocol feature and abusing it. The implication that merely using some of these features is a security issue and an abuse is the problem with this document - and the approach of similar documents.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 Nov 2018 07:18:49 -0800

Picking a random message to reply to.

I'm not any kind of IPv6 expert, so I'm not taking a position on the
goodness or badness of extension headers.

With that said, we do have a fair amount of experience with trying to
deploy new protocols in the face of significant levels of network-level
filtering; TLS 1.3 was delayed by a year or so when we discovered that
there were middleboxes which made incorrect assumptions about our extension
points. At the end of the day, we got things working, but at the cost of
some not very attractive hacks, and if you look at QUIC, a lot of the
design is motivated by concealing extension points from network
intermediaries in order to avoid a replay of this scenario. Otherwise,
we're worried that we won't be able to extend the protocol in the future.

So, at least from the endpoint's perspective, a situation in which network
intermediaries block any new protocol features they don't recognize is not
really great.

-Ekr

On Mon, Nov 26, 2018 at 6:36 AM Joe Touch <[email-masked]> wrote:

> There is a big difference between using a protocol feature and abusing it.
> The implication that merely using some of these features is a security
> issue and an abuse is the problem with this document - and the approach of
> similar documents.
>
> Joe
>

---

From: Gert Doering <[email-masked]>
Date: Mon, 26 Nov 2018 18:53:37 +0100

Hi,

On Mon, Nov 26, 2018 at 06:32:43AM -0800, Joe Touch wrote:
> The failure of a device to run as advertised or the failure of an 
> operation to select the an appropriate device.

This is where the "real-world" bit comes into play.

> Operators that want to conserve resources without cause are welcome
> to run their routers inside glass boxes in museums.  Routers do
> work. Packets cause that work. That work is not an attack unless
> it is *disproportionate*. That is not shown for nearly any of the
> cases in this document.

As people have explained in great detail, there's work that the routers
are built to do, where the number of packets they can handle is nearly
arbitrarily high.

Then there's packets that are seen as an exception, and handled in a
not-as-powerful path.  Back then, when the Internet was new, these 
exceptional packets were considered "something we'll handle when the 
need arises", and it mostly worked.  Today, whenever anything is connected
to the real Internet has a weakness, it will be abused.  Thus, these 
packets will have to be rate-limited, up to the point of uselessness.  

Of course you can build a box that can do everything with the same 
speed.  I would recommend to the reader to make himself familiar with
current market realities, though, regarding "cost", "power consumption",
"feasibility to build in time before the increase in bandwidth has them
obsoleted again" and "willingness of customers to pay serious money for 
their Internet access".

Gert Doering
        -- Operator

---

From: Ole Troan <[email-masked]>
Date: Mon, 26 Nov 2018 19:02:54 +0100

> their Internet access”.

While I agree with what you say here, this draft recommends the opposite.
It recommends that routers should do more work, not less.

Filtering out extension headers and options inside of extension headers, is not only costly, it also violates basic Internet Architecture principles.

Ole

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2018 13:59:38 -0800

On 2018-11-26 09:53, Gert Doering wrote:

> ...
> need arises", and it mostly worked.

Translation - "we cheated", and that's not working anymore. Agreed. 

> Today, whenever anything is connected

Rate limiting is quite different from 100% discards. When abuse happens,
it's clearly safe to react. 

But reacting to the mere presence of this additional - unexpected - work
is not itself abuse. And frankly it's only abuse because vendors claim
IPv6 compliance by cheating and operators go along with the game. 

> obsoleted again" and "willingness of customers to pay serious money for 

If you sold this as "partial IPv6" or "incomplete support for RFC8200",
then sure. 

If most of the time these options are not used, then fine - rate limit
when they come up. But say that's what you're doing. 

And don't pretend that this is for security purposes. 

Joe

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Nov 2018 17:18:26 -0600

> that has been stadardizez and that will not cause you pain". And, again,

How is this better than "pass everything that will not cause you pain"?
Why should the transit care if something is standardized or just an
experiment running over the internet?

> of this writing you cannot even use ipsec reliably on the Internet(!).

One can agree that folks implementing this advice would be an improvement
over the current state of affairs, without agreeing that the IETF should
advocate against using our protocols as they were designed.

> details. (e.g. TCP ports).

Perhaps I am confused, but IIUC this document discusses values placed in
the IPv6 "Next Header" field, some of which are EHs and some of which are
not.  Values not recognized to the processing entity may be EHs or may be
"next protocol"s, and if the value is not recognized there is no way to
know which is the case.  Ergo, filtering out unknown values that might be
EHs is also filtering out unknown next-protocols, which seems really bad
for the future flexibility of the internet.

-Ben

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Nov 2018 11:06:51 +1100

The same is true in DNS. Recursive servers end up having to probe with different extensions set.  Such
probing is being turned off for basic EDNS because it leads to false positives about what the remote
server support which in turn breaks DNSSEC which depends on EDNS and being able to set the DO flag bit.

One source vendors are so fed up with this stupidity by firewall vendors that they are collectively
going to stop shipping code that automatically attempts to work around this breakage.  The big open
recursive resolver operators are also turning off work arounds.  This at least will mean that DNSSEC
will become more reliable.  https://dnsflagday.net

https://ednscomp.isc.org/compliance/summary.html has lots of time series showing how different extension
mechanisms are blocked / mis-handled.

EDNS has stated from day 1 that unknown EDNS flags are to be ignored yet there are firewall vendors that
seem to think it is a good idea to block them.  It took years for DO to be allow through by most firewalls.

EDNS has stated from day 1 that unknown EDNS versions are supposed to be responded to by BADVERS with the
highest version supported but we still have firewall vendors block EDNS version != 0 requests.

EDNS also says that unknown EDNS options are to be ignored by the server yet there are firewalls that block
them by default.  There are those that block NSID options in the request by default, but it something the
DNS operator has to enable in the server for there to be a NSID in the response.

None of this blockage provides any real security.  Name servers handle all of these extensions and don’t
fall over.

There really is too much paranoia by firewall and other vendors.  Just because something is using a extension
mechanism it doesn’t mean that it is dangerous or abuse.

Getting back to IPv6 headers ASIC’s that can’t skip over fragmentation headers are just plain broken.
ASIC’s that can’t generate PTB responses are just plain broken.  These are part of basic IPv6.  Neither
should require hitting the slow path.

Mark

> On 27 Nov 2018, at 2:18 am, Eric Rescorla <[email-masked]> wrote:
> 
> I'm not any kind of IPv6 expert, so I'm not taking a position on the goodness or badness of extension headers.
> 
> With that said, we do have a fair amount of experience with trying to deploy new protocols in the face of significant levels of network-level filtering; TLS 1.3 was delayed by a year or so when we discovered that there were middleboxes which made incorrect assumptions about our extension points. At the end of the day, we got things working, but at the cost of some not very attractive hacks, and if you look at QUIC, a lot of the design is motivated by concealing extension points from network intermediaries in order to avoid a replay of this scenario. Otherwise, we're worried that we won't be able to extend the protocol in the future.
> 
> So, at least from the endpoint's perspective, a situation in which network intermediaries block any new protocol features they don't recognize is not really great.
> 
> -Ekr
> 
> 
> 
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Nov 2018 13:33:42 +1300

On 2018-11-27 12:18, Benjamin Kaduk wrote:

<snip>

> for the future flexibility of the internet.

You are not at all confused. That's one of the reasons we wrote RFC7045. 

But for a paranoid firewall, it doesn't matter. The logic is 
unrecognized -> drop in either case.

(This is part of the chain of reasoning that led to
draft-carpenter-limited-domains, but that's another story.)

    Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 27 Nov 2018 01:18:18 +0000

Joe Touch wrote on 26/11/2018 21:59:
> Rate limiting is quite different from 100% discards. When abuse
> happens, it's clearly safe to react.
data plane speeds are measured in terabits/sec.  Control plane capacity 
for dealing with punted packets is measured in kilobits.  As end user 
and data plane speeds increase, rate-limiting for problematic packets 
will tend towards towards 100% loss.

It doesn't matter if your packet stream is subject to 20% loss, or 100%, 
or 100% for 20% of the time - beyond a certain point, the end user 
experience will languish in an indistinguishable morass of unusability.

Nick

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Nov 2018 17:47:28 -0800

If you can’t handle options, then you’re just lying about the tbps.

Joe

> On Nov 26, 2018, at 5:18 PM, Nick Hilliard <[email-masked]> wrote:
> 
> data plane speeds are measured in terabits/sec.  Control plane capacity for dealing with punted packets is measured in kilobits.  As end user and data plane speeds increase, rate-limiting for problematic packets will tend towards towards 100% loss.
> 
> It doesn't matter if your packet stream is subject to 20% loss, or 100%, or 100% for 20% of the time - beyond a certain point, the end user experience will languish in an indistinguishable morass of unusability.
> 
> Nick
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 27 Nov 2018 08:34:56 +0100

Hi,

> And don't pretend that this is for security purposes. 

So your advice would be to turn off IPv6 support in our network, then?

Because customers are not going to pay money for it, and "no money for it"
is not going to buy me a "full featured and IETF-approved" set of routers.

Reality can be fairly uncomfortable.

Gert Doering
        -- NetMaster

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Nov 2018 10:10:15 +0000

> Translation - "we cheated", and that's not working anymore. Agreed.

Fundamentally it is about economics.

Doing complex processing in the fast path is expensive. It is expensive 
to have the cycles
available. In designs that use fixed logic assistance it is pretty much 
infeasible to cope with
multiple options as the combinatorial complexity explodes on you.

As the packet size increases this is also expensive in terms of the fast 
packet caching memory
needed.

In the days when the fast path/slow path decision was first taken, there 
were also fundamental
limits on what could be implemented at any price thus pushing the cost 
from equipment
to physical infrastructure. There are some use cases that say that we 
need to get 1Tb/s
to the host for some applications, so we cannot be sure that the 
fundamental parsing limit
problem will not re-occur.

In any case, fast feature = silicon = cost and whilst you can or at 
least could ride More's law,
at the end of the day you have to trade features against port density 
against power against
capex against opex. ... and all this is without the issue of the 
internet carbon footprint
coming under scrutiny.

So what this came down to at the time the feature split was taken was a 
decision on economics,
i.e. is the cost of the additional feature worth the price paid? That is 
still true and  I think that
we need to remember that as we add non-optional features into the fast 
path.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Nov 2018 10:17:46 +0000

> If you can’t handle options, then you’re just lying about the tbps.

When the required application performance exceeds the ability of the 
hardware
designers to deliver it economically (or may be at any price) something 
has to give.
At that point either the protocol gets modified, or it goes end of life.

- Stewart

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Nov 2018 02:40:26 -0800

Take that to the standards wg. Don’t stick your head in the sand and try to do an end run in ops. And don’t call any of this a security issue that it isn’t. 

Joe

> On Nov 27, 2018, at 2:17 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> When the required application performance exceeds the ability of the hardware
> designers to deliver it economically (or may be at any price) something has to give.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 27 Nov 2018 10:52:51 +0000

I was simply explaining forwarding engineering 101, which seemed to be being forgotten in the tread.

Beyond that I don’t much care on way or the other.

Stewart

> On 27 Nov 2018, at 10:40, Joe Touch <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 27 Nov 2018 03:08:02 -0800

Standards 101 is either support the standard or revise it. The latter was tried and rejected.

Whatever you do, don’t fail to support it for false reasons.

Joe 

> On Nov 27, 2018, at 2:52 AM, Stewart Bryant <[email-masked]> wrote:
>