Subject: Turning routers into hosts (Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt))

From: Mark Smith <[email-masked]>
Date: Tue, 14 Jul 2020 07:23:15 +1000

On Tue, 14 Jul 2020 at 06:02, Toerless Eckert <[email-masked]> wrote:
>
> On Mon, Jul 13, 2020 at 03:00:44PM -0300, Fernando Gont wrote:
> > On 10/7/20 15:32, Toerless Eckert wrote:
> > > IMHO: See my email earlier in the thread about punting stuff to slow-path, especially when/before
> > > you figure out that you should have just ignored something at linerarte.
> > >
> > > Aka: not sufficiently prescriptive RFCs + bad implementations == extension header based features killed in deployments.
> >
> > Indeed. And add to that that the EH structure itself seems to be rather
> > unfriendly with some popular hardware architectures. (unless with "not
> > sufficiently prescriptive RFCs" you are meaning to set the maximum EH-header
> > chain length to some sane value that folks might agree to comply with).
>
> I think we might want to start with a draft collecting what we think to
> kow about the problem and figure out if we can structure it accordingl
> to make sense out of it to make progress that is not just incrementally fixing
> one single bit.
>

I think one of the first sections needs to be titled:

"Turning Routers into Hosts"

because in-flight processing of packets' EHs, payloads etc, rather
than just dumb, fast and simple forwarding them, is host processing of
packets.

How to tell it's host processing?

- processing of packets requires going past the IPv6 fixed header

- in-flight processing would fail if everything but the fixed header
was encrypted

- processing beyond the fixed (forwarding) header is occuring at a
node that *doesn't* hold the packet's destination address:

RFC8200:

router       a node that forwards IPv6 packets not explicitly
                addressed to itself.  (See Note below.)

   host         any node that is not a router.  (See Note below.)

(Note is about a node's interfaces being forwarding or not)

In this discussion and similar, people are really discussing paths
between a packet's original source and a final destination constructed
of a set of packet host processing hops.

Regards,
Mark.

> Cheers
>     Toerless
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 13 Jul 2020 23:49:49 +0200

Thanks, Mark

Whats your opinions about functionality ? Or are you only interested in terminology ?
Terminology is always fun, but given how your interpretation differs from
RFC8200, i wonder why you're bringing it up.

Extension headers could still be encrypted if they would also be managed so
as to be decryptable by network nodes.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Jul 2020 12:13:32 +1200

> "Turning Routers into Hosts"

Are you sure you don't mean "Turning Routers into Packet Manglers"?

Regards,
   An author of RFC3234

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Jul 2020 21:59:03 -0400

On Mon, Jul 13, 2020 at 8:15 PM Brian E Carpenter <
[email-masked]> wrote:

> >>>> Aka: not sufficiently prescriptive RFCs + bad implementations ==
> extension header based features killed in deployments.
> >>>

... are you sure you don't mean "Turning Routers into Smoking Holes in the
Ground"

Regards,
  An operator of a device that tried to punt packets to the slow path.

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Jul 2020 00:11:35 -0300

> Are you sure you don't mean "Turning Routers into Packet Manglers"?

FWIW, draft-gon6-v6ops-ipv6-ehs-packet-drops describes why devices need 
to peek into the packet. It doesn't talk about any kind of mangling... 
and the only manipulation it refers to is the potential dropping of packets.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 06:40:39 +0200

>   An operator of a device that tried to punt packets to the slow path.

Where were you when we deployed in ca. 1989 version 1.0 of DVMRP across the
Internet which was using a loose source route to a remote tunnel endpoint
to avoid encapsulation overhead. And all the routers along that internet
path happily punted all those loose source route packets. I think it took
a few months before operators recognized the problem though...

If smoking out routers with slow path is still a thing,
i guess there must be some redeeming gratification in it.  ;-))

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 15 Jul 2020 15:27:23 +0100

Toerless Eckert wrote on 14/07/2020 05:40:
> i guess there must be some redeeming gratification in it.

If you know of any kit impervious to corner cases, please speak up!

Nick

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 15 Jul 2020 16:51:25 +0200

> If you know of any kit impervious to corner cases, please speak up!

For clarity i should have said "smoking out kits by the good guys".
Not the bad guys (attacks).

I don't know the details of Warrens smoking example, but in general i
think when we started with IP in the last millenium, we where excited
to utilize its full potential. Now we are excited only minimize its potentials
and use to avoid smoke. That is somewhat depressing.

Personally i think we can build better network protocols
that withstand smoke, but we then need to also have better specs that
have language against smoke. I did sugest some example in these threads.

In general, i am a fan of stateless forwarding plane functionality these days.
Whenever you need to maintain & modify state across packets, smoke protection
becomes a lot harder. Already starts with changes in FIBs.

In my experience, compared to smoking out routers with e.g.: struggling NAT/FW
table handling, FPE processing of extension headers for stateless functionality is trivial.

The more basic problem is that of handling dynamic performance. Consider
just a CPU style FPE, where the packet+extension header processing can lead to
performances of e.g.: N pps/sec for the most simple packet to N/4  pps/sec for
the christmas tree packet. Now go write the document to characterize
all feature combinations of performance impact up for a big SP customer. Ok.
assume you can do this. Now try to be that SP trying to figure out how to
operationalize this complex performance matrix.

Aka: Whenever you come up with more complex FPE functionality, you need
to either spend aditional chip space so it doesn't impede on performance,
but instead on the cost of the chip, or you need to think of an operational
model where the performance impact can be easily managed. Obviously, for
high-end features, the operational model is successfull: Put it into VMs,
run it with a cloud-native setup where you just allocate more and more CPU
cores, dependng on performance needed.

Cheers
    Toerless