Subject: "In-Flight IPv6 Extension Header Insertion Considered Harmful" (draft-smith-6man-in-flight-eh-insertion-harmful)

From: Mark Smith <[email-masked]>
Date: Wed, 9 Oct 2019 16:37:22 +1100

Hi All,

Despite what was clarified in RFC 8200, it seems this ID is needed.

Looking for co-authors.

Thanks very much,
Mark.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, 9 Oct 2019 at 16:30
Subject: New Version Notification for
draft-smith-6man-in-flight-eh-insertion-harmful-00.txt
To: Mark Smith <[email-masked]>

A new version of I-D, draft-smith-6man-in-flight-eh-insertion-harmful-00.txt
has been successfully submitted by Mark Smith and posted to the
IETF repository.

Name:           draft-smith-6man-in-flight-eh-insertion-harmful
Revision:       00
Title:          In-Flight IPv6 Extension Header Insertion Considered Harmful
Document date:  2019-10-08
Group:          Individual Submission
Pages:          10
URL:
https://www.ietf.org/internet-drafts/draft-smith-6man-in-flight-eh-insertion-harmful-00.txt
Status:
https://datatracker.ietf.org/doc/draft-smith-6man-in-flight-eh-insertion-harmful/
Htmlized:
https://tools.ietf.org/html/draft-smith-6man-in-flight-eh-insertion-harmful-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-smith-6man-in-flight-eh-insertion-harmful

Abstract:
   In the past few years, as well as currently, there have and are a
   number of proposals to insert IPv6 Extension Headers into existing
   IPv6 packets while in flight.  This contradicts explicit prohibition
   of this type of IPv6 packet proccessing in the IPv6 standard.  This
   memo describes the possible failures that can occur with EH
   insertion, the harm they can cause, and the existing model that is
   and should continue to be used to add new information to an existing
   IPv6 and other packets.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 11:07:22 +0200

when feeling like need to insert an EH in-flight one must think how 
decisively that breaks the authenticity verifiers.

To alleviate the need to insert EH in-flight, and still satisfy the 
purpose, one would rather encapsulate, or use routing headers.

If one still feels like that need to insert an EH in-flight one must use 
it in a 'limited-domain' (see draft with 'limited-domains' in its 
filename).  This is not for Internet at large.

Alex

Le 09/10/2019 à 07:37, Mark Smith a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Oct 2019 21:12:51 +1100

> purpose, one would rather encapsulate, or use routing headers.

I'm  wondering if you've read the draft, since those are points that are in it.

(Text about it the obvious things it breaks isn't there yet, but
that's easy to fill in. The topics for all of them are.)

> filename).  This is not for Internet at large.

No, it's not for anywhere. If you've read the draft you'll understand why.

---

From: li zhenqiang <[email-masked]>
Date: Wed, 9 Oct 2019 10:16:09 +0000

We discuss and define the standard for Internet not for private network.

Zhenqiang Li
________________________________
[email-masked]

From: Alexandre Petrescu<mailto:[email-masked]>
Date: 2019-10-09 17:07
To: ipv6<mailto:[email-masked]>
Subject: Re: "In-Flight IPv6 Extension Header Insertion Considered Harmful" (draft-smith-6man-in-flight-eh-insertion-harmful)
when feeling like need to insert an EH in-flight one must think how
decisively that breaks the authenticity verifiers.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 13:07:29 +0200

> I'm  wondering if you've read the draft, since those are points that are in it.

routing headers arent in it, are they?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 13:08:53 +0200

> <[email-masked]> wrote:
[...]
> No, it's not for anywhere. If you've read the draft you'll understand why.

Would it strengthen the message of this I-D to add a reference to the 
'limited-domains' draft?

Alex

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Oct 2019 22:23:44 +1100

> routing headers arent in it, are they?

No.

Why should they be?

They're no different to any other EH. They shouldn't be inserted.

Inserting EHs makes the Source Address of a packet a lie.

---

From: Mark Smith <[email-masked]>
Date: Wed, 9 Oct 2019 22:49:03 +1100

No.

It would do the opposite. People are using limited or controlled
domains as an excuse to ignore the problems the ID describes.

They're assuming and asserting that limited or controlled domain
boundaries will be 100% perfectly enforced - no implementation bugs
ever, no partial device failures ever, and that devices will be
configured 100% correctly 100% of the time. That's ignoring the
operational reality of networks.

(I've seen ARP frames leak between different layer 3 interfaces on a
newly released router running a very wildly used and at least 20 year
old router operating system at the time.  This router wasn't doing
anything special, new or fancy - vanilla IPv4 forwarding, running BGP
and OSPF. The ARP frames were leaking from the upstream links onto the
downstream link which was a peering link, and that link had MAC
address limits at the far end that took the link down if there were
too many unique MAC addresses received. That dumped 100s of Mbps of
peering traffic back onto our Internet transit links, which at the
time we could just barely cope with. As an indication of how cost
effective this new peering link was for us, the money saved on transit
paid for the new router in 1 month.)

Regards,
Mark.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 9 Oct 2019 14:10:14 +0200

Hi,

> Inserting EHs makes the Source Address of a packet a lie.

This

I have had enough of debugging with packets that change in significant ways in transit. I want to leave that firmly in the IPv4 era. Packet-out == packet-in is extremely valuable for the grunt work at operators.

Cheers,
Sander

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 16:04:18 +0200

> Inserting EHs makes the Source Address of a packet a lie.

IT shows you did not read what I wrote :-)

I wrote that if someone needs very strongly to insert EH then rather 
encapsulate or use RHs.

That means that if someone feels strongly to insert EH then rather use 
RH, or encapsulation.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 16:16:50 +0200

> That means that if someone feels strongly to insert EH then rather use 

I did not mean to insert an RH, but use an RH as designed.

It is possible to achieve same effect as the EH insertion by correctly 
using an RH.

Alex

>>>>>> A new version of I-D,

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 16:18:42 +0200

> domains as an excuse to ignore the problems the ID describes.

Cite it like that.

> operational reality of networks.

In some settings these things are true: it must absolutely positively 
work as designed.

The boundaries are enforced 100% by humans taking care continously of 
the disconnection, with an axe at hand if necessary to cut it when it 
must not work:-)

The implementation bugs are ensured by using older code, or formal 
methods, or some other methods.

The partial device failures are eliminated by trying continuously the 
devices and having second (or even third) devices at hand when necessary.

The devices are configured correctly because they are checked and double 
checked every day.

The operational reality of networks depends on which humans are running 
them.

> paid for the new router in 1 month.)

True.  Things leak between what one consider a limited-domain and the 
Internet at large.  The experience of ARP leaked must be noted.

Alex

---

From: Tom Herbert <[email-masked]>
Date: Wed, 9 Oct 2019 07:54:47 -0700

> In some settings these things are true: it must absolutely positively
Alexandre,

An airplane also "must absolutely positively work as designed", and
yet they still crash occasionally because of design flaws and software
bugs. So it is with any complex technology. There is no such thing as
100% correct or 100% network deployment at scale. Indeed, some
networks may come very close, but there's no network that is
_provably_ correct and secure. IMO, coming close to perfection isn't
enough to justify rethinking the fundamental principle of robustness
in Internet protocols.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 9 Oct 2019 17:00:31 +0200

> enough to justify rethinking the fundamental principle of robustness

I do not look at rethinking the principles of Internet.

To clarify: if one wants to insert EHs on the fly, then rather do it in 
a limited domain.

Or did you mean that one is not allowed to write software to insert EHs 
on the fly?

Under which circumstances is one allowed to write software to insert EHs 
on the fly?

Alex

---

From: Tom Herbert <[email-masked]>
Date: Wed, 9 Oct 2019 10:04:09 -0700

Alexandre,

Implementators can and probably will do whatever they want. It's a
question of whether what they are doing is conformant with the
standard. Per RFC8200, EH header insertion is not allowed. To be
clear, this is not just a purist argument, there are real reasons why
EH is bad idea, or "harmful" as this draft states it. The attribution
problem and ICMP breakage are real issues that are brought up every
time wrt to proposals to allow EH insertion. There hasn't been an
answer to the problems. Just saying that EH insertion would be
restricted to limited domains doesn't help either, things like ICMP
and attribution are still very much needed there. Besides that,
limited domains itself is not normatively defined in IETF, and
probably never will be, so we can't just update RFC8200 to say that EH
insertion is somehow prohibited on the "Internet" but allowed in
"limited domains". Even if there was a normative definition of limited
domains, then we'd be facing the prospect of bifurcating core Internet
protocols so that they could operate differently in "limited domains"
than "on the Internet"-- that seems like it would become an untenable
mess for protocol standards.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Oct 2019 08:44:17 +1300

> domains as an excuse to ignore the problems the ID describes.

The limited domains draft actually intends to say something a little
different: if you are going to define a limited domain protocol, do it
properly, with a well defined and secure domain boundary, and mechanisms
for nodes to know about that boundary. It also makes the point that
this does not simplify protocol design; rather the opposite: "a limited
use requirement potentially adds complexity to both the protocol and
its security design". Just saying that you will configure the boundary
nodes carefully to avoid accidents is not enough, IMHO.

I still don't undersand how the SRH work solves that problem, even
without dynamic header insertion.
 
> operational reality of networks.

Exactly.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 10 Oct 2019 10:26:22 +0200

I do not say EH insertion on the fly is a good thing, and I agree with 
the reasons mentioned about why it is not a good thing: things leak to 
Internet at large, and end-to-end authentication becomes impossible.

For the equivalency, see below.

> without dynamic header insertion.

I do not know the precise reason why people insert EH on the fly.

But it is always possible to use an RH (not SRH) to direct the traffic 
to a rdv point IP address, that runs a certain application.  That 
application may execute what that EH needs to do.  This RH can 
accommodate end-to-end authentication, and the packets can be 
communicated over the Internet at large.

That is the equivalency of using an RH to satisfy the EH-on-the-fly need.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 10 Oct 2019 15:59:16 +0200

> Despite what was clarified in RFC 8200, it seems this ID is needed.

Mark,

I think there are critical technical aspects which are missing.
The key one to me is that ICMP error messages generated they would 
include the inserted headers, which unless removed at the boundary would 
confuse the original sender since the sender didn't include that 
extension header.

Thus if the goal for in-flight EH insertion is to be transparent to the 
rest of the network, the solution needs to rewrite the inside of any 
ICMP error that has been generated between the ingress and egress of the 
EH insertion.
If PMTUd is to work, that includes calculating the MTU to report to the 
originator.

There are some other issues if the path MTU between the ingress and 
egress gets close to 1280, because in the worst case that means that a 
1280 byte original can't make it across the in-flight path without 
someone fragmenting it, and PMTUd can't be used to get an IPv6 sender to 
fragment something which is 1280 bytes or less.

I can't tell from the draft whether you want to expand and focus on the 
technical description of the issues with in-flight insertion and the 
requirements if this is supposed to be transparent to the rest of the 
Internet, or if you want to expand and focus on the more philosophical 
arguments.

Regards,
   Erik