Subject: [arch-d] Fiddling with IP packets in the network, IPv6-style (Fwd: Question about SRv6 Insert function)

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 03:47:21 +0300

Folks,

There seems to be ongoing working group item in the spring wg
(https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01)
that essentially proposes the insertion of IPv6 Extension Headers by
middle boxes in the middle of the network, which goes against a very
explicit requirement in the IPv6 spec (RFC8200) -- that notes that EHs
cannot be inserted in the middle of the network.

This begs a number of questions (e.g., how come that one wg is working
on something that goes against a spec that is not under its charter).

But given this is an architecture list, I wonder if anybody has a say on
the topic? (including the IAB). Is that the way IPv6 is expected to
work? What can we expect from IPv6?

-------- Forwarded Message --------
Subject: Re: Question about SRv6 Insert function
Date: Thu, 5 Sep 2019 03:34:09 +0300
From: Fernando Gont <[email-masked]>
To: Ole Troan <[email-masked]>, Fernando Gont <[email-masked]>
CC: Ron Bonica <rbonica=[email-masked]>, [email-masked]
<[email-masked]>, [email-masked] <[email-masked]>, Suresh Krishnan
<[email-masked]>, draft-voyer-6man-extension-header-insertion
<[email-masked]>,
draft-ietf-spring-srv6-network-programming
<[email-masked]>

On 4/9/19 09:58, Ole Troan wrote:
> Fernando,
> 
>>>> Since there have been plenty of attempts to do EH insertion or
>>>> leave the IPv6 standard ambiguous in this respect, and the IETF has
>>>> had consensus that EH insertion is not allowed, I think it would be
>>>> bad, wastefull, tricky, and even dangerous to let a document go
>>>> through the whole publication process, and just rely on the AD to
>>>> keep the "DISCUSS" button pressed.
>>>>
>>>> Put another way: what'd be the rationale for having a draft-ietf
>>>> and have the corresponding wg ship the document with something that
>>>> clearly goes against IETF consensus, and that the relevant AD has
>>>> declared that wouldn't let pass?
>>>
>>> In short, this is not the case. I am *not* the relevant AD for the
>>> SRv6 Network Programming draft. If this document was in 6man I would
>>> have flagged it much earlier like I did for the SRH draft.
>>
>> Sorry, what I meant by "relevant AD" is: "one of the responsible ADs for
>> the spec that's being violated".
>>
>> i.e., isn't there in the IETF process -- whether formal or informal --
>> for this sort of thing to be flagged before documents get too far in the
>> publication process?  ("Hey, this document in your area is actually
>> breaking a spec of one of my wgs" sort of thing...)
> 
> I would prefer that we calmed down a bit on the protocol policing.

Sorry, but this has nothing to do with protocol policing. It has to do
with respecting the consensus this wg and the ietf as a whole had on the
topic. i.e., that EHs must not be inserted in the network.

We'd go into an interesting path to insanity if we publish specs, and
subsequently publish conflicting specs that simply ignore previous ietf
consensus.

If folks want to do EH insertion, the #1 step is to publish a document
that updates RFC8200 such that the "EHs must not be inserted..." is
replaced with something else or eliminated.

> We know that header insertion breaks unsuspecting source hosts if done by the network.
> It breaks (at least) PMTUD, ICMP errors and AH.
> 
> What we have said in the past is; explain how those issues are dealt with or do not apply to your proposal.

That's what you and others may have said or thought. But the consensus
is what's in the standard (RFC8200). And the standard says that EHs
cannot be inserted in the network. If you want to do it, the first step
is to update RFC8200.

> And some form of "doing on behalf of" is not necessarily problematic.

It is rightaway problematic specs-wise when it violates a crystal-clear
requirement in RFC8200, that we arrived to after a very heated debate,
and lots of enegery and time from all the involved people.

The fact that after all the long story behind publication of rfc8200 as
standard (and the ongoing srv6 document we're doing here, which was
adopted on the condition that it wouldn't do eh-insertion), we can live
with other wgs violating specs that we produced here with so much effort
and time, is kind of amusing.

If folks want to allow EH-insertion (i.e., formally allowing middleboxes
to fiddle with packets), RFC8200 should be updated, and the work should
be done in 6man.

I don't think it's SPRING's call how the IPv6 protocol works.

> It's the "blind" "Thou shalt not do" that I object to. As opposed to arguing on technical grounds.
> 
> Ensuring interoperability is our purpose. Not protect 8200 as if it's a religious text.

My #1 concern (not that I don't have others) is one related to fairness
of the standardization process. I don't think we should simply
rubberstamp anything a big vendor wants to sell, no matter how big the
vendor is, or how much money may be involved.

And if this working group (and the IETF as a whole) published a spec on
which there was consensus, ignoring the spec and doing whatever one
pleases is not the way to go. Firstly, make e the case for updating
RFC8200. Then come up with the proposal to fiddle with packets in the
network.

P.S.: I've never been into the camp of protecting X (whether rfc8200 or
any other document) as if it was religious text. Quite ironically, I
have experienced such religious opposition in 6man itself (for instance,
your argument of "don't fix slaac-renumbering because ipv6 has not been
designed to support flash renumbering" seems pretty much a religious
argument against work that would not result in any major modifications
to any of the protocols involved -- as opposed to EH insertion).

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 5 Sep 2019 02:09:59 +0100

Hiya,

On 05/09/2019 01:47, Fernando Gont wrote:
> the topic? (including the IAB).

I don't "have a say" but I do have a question...

Given this is a WG document in a chartered IETF WG, I'm
unclear why you're asking the IAB/arch-discuss. I mean,
if the draft is out of the WG's charter or something,
then raising that with the chairs and then responsible
AD etc would be the path to follow. So I'm puzzled as
to why you think IAB members ought spend time on this
(given that I, and I guess other IAB members likely
start out as ignorant when it comes to spring stuff;-)

Ta,
S.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 04:30:20 +0300

> start out as ignorant when it comes to spring stuff;-)

Besides procedural issues, the ultimate implications of this is that
we're formally introducing middle-boxes that fiddle with packets in the
middle of the network.

Isn't this within the kind of stuff the IAB has interest on?
If so, better to tackle this now, than to publish an RFC5902-style
document when the cat is already out of the box.

Thanks,

---

From: Tony Li <[email-masked]>
Date: Wed, 4 Sep 2019 18:37:47 -0700

> we're formally introducing middle-boxes that fiddle with packets in the

Didn’t we have this same discussion 25 years ago on NAT boxes?

The fact of the matter is that the IETF is completely helpless to prevent such things. 
True, it can block standardization, but if the market wants it, the market will drive it
and all that the IETF does is to make itself irrelevant to the process.

> Isn't this within the kind of stuff the IAB has interest on?

If it were, the first complaint would be about SRv6 itself.

The IAB’s only role is that of genteel education and it’s a target rich environment.

Tony

---

From: Christian Huitema <[email-masked]>
Date: Wed, 4 Sep 2019 20:02:01 -0700

> On Sep 4, 2019, at 6:37 PM, Tony Li <[email-masked]> wrote:
> 

The flip side of that is end to end encryption, which pretty much ensures that "a bit is a bit". And we sre seeing most of traffic being encrypted, pretty much armored against shenanigans in the middle. Given that, stuff like SRv6 is mostly useful for traffic engineering, which seems like something we would want.

-- Christian Huitema

---

From: "S. Moonesamy" <[email-masked]>
Date: Thu, 05 Sep 2019 01:52:37 -0700

Dear Fernando,
>on something that goes against a spec that is not under its charter).

That would be an IETF process question instead of one about architecture.

>work? What can we expect from IPv6?

The participants in that discussion have a say in the (existing or 
proposed) standards.  There is a discussion of extensions headers in 
RFC 7045.  There is the address allocation aspect which is also 
discussed in other venues, e.g. RIR venues.  There are the security 
and privacy aspects.  At this stage, it may be better to have the 
working group discuss the issues before requesting wider input.

Regards,
S. Moonesamy

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Sep 2019 11:08:07 +0200

> work? What can we expect from IPv6?

Can we expect IP at large to touch headers of end user packets?  No. 
Can we expect it in a 'limited-domain'?  Yes, and I'd say INFORMATIONALly.

Alex

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 15:06:11 +0300

On 5/9/19 12:08, Alexandre Petrescu wrote:
> Can we expect IP at large to touch headers of end user packets?  No. Can
> we expect it in a 'limited-domain'?  Yes, and I'd say INFORMATIONALly.

Spoiler: You can't guarantee with 100% certainty that packets will not
leak out from a "limited domain".

---

From: Fernando Gont <[email-masked]>
Date: Thu, 5 Sep 2019 16:04:59 +0300

> and all that the IETF does is to make itself irrelevant to the process.

Or it could at least push for the cleaner options: e.g., I see no reason
for doing eh-insertion as opposed to encapsulating the packet into a new
ipv6 packet, and create that packets with the headers you need.

> The IAB’s only role is that of genteel education and it’s a target rich

So... who cares about architecture, then?

Thanks!

Cheers,