Subject: [tsvwg] transport-encrypt-14 review, pt 1

From: Martin Duke <[email-masked]>
Date: Thu, 9 Apr 2020 12:44:06 -0700

Getting through this draft is not going as quickly as I'd hoped. Before my
notes get unmanageably long, I thought I'd send a few comments through
section 3.

The comments might invite some WG discussion, but the nits are purely
typos. Consider this a down payment on AD review.

*Comments* (if these are addressed later in the document, I apologize):
- I think this is missing an important reason for header encryption, or at
least header authentication -- to foil a large number of attacks like TCP
RST injection.

- Conversely, middlebox interference with headers does enable performance
enhancing proxies for extraordinary link types like satellite.

- Sec 2.3 explains that transport information is useful in detecting
various network pathologies. While true, the range of possible pathologies
is only as large as the control surface the transport protocol offers.

For example, in TCP networks can affect (and measure) packet loss and
latency. They also can also modify packets or drop them based on transport
layer information, meaning there are more failure modes to detect.

In QUIC, the latter is almost impossible. Aside from Initial Packets, the
only possible actions are (1) drop the packet, (2) accelerate or decelerate
the packet, (3) change bits that will cause authentication failure at the
receiver, or (4) modify the packet at UDP or below. All of these are still
measurable over a network segment, though with different techniques from
today. Most trivially but perhaps impractically, a complete inventory of
bits at the network ingress and egress point will reveal all of this
information.

Put more simply, everything that QUIC conceals from the network can be
ruled out as a cause of the network’s treatment of a packet.

*Nits:*
Section 1
p.2. para 1. comma after RFC 8548.

p.3, para 2. s/This include/This includes

p 3 para 2. "observe a specific information" - remove 'a'

p 3 para 2. "whether it is intended that a network device can
   modify the field, whether the devices are able to modify that field;" is
this accidentally repeated?

Sec 2.1. Para 3. “Header compression depends [on] understanding

Please add an informational reference for TCP fast Open.

Sec 2.3 s/transport headers fields/transport header fields

Sec 3.1.1 1st para: "Denial of Service, DOS, prevention." (?)

Sec 3.2, p.20 : s/easy to manage, a device/easy to manage, but a device

Martin

---

From: Joseph Touch <[email-masked]>
Date: Thu, 9 Apr 2020 13:20:26 -0700

> On Apr 9, 2020, at 12:44 PM, Martin Duke <[email-masked]> wrote:
> 
> - Conversely, middlebox interference with headers does enable performance enhancing proxies for extraordinary link types like satellite.

Those are only “extraordinary” only in the “been around for 50 years in the Arpanet/Internet”. That understanding goes back as far as RFC 346 and IEN 8.

Additionally, ground nets often experience similar BW delay products, which can be the dominant driver. 

There are known ways to help TCP over such links that don’t involve these sort of steps, documented as far back as RFC 2488, some of which are now being incorporated (faster window growth and recovery, ala Hybla).

I.e., just because a mechanism CAN rely on these headers doesn’t mean that’s the only - or even safe - way to do so.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 Apr 2020 08:35:12 +0100

On 09/04/2020 20:44, Martin Duke wrote:
<snip>
> various network pathologies. While true, the range of possible 
> pathologies is only as large as the control surface the transport 
> protocol offers.
>
> latency. They also can also modify packets or drop them based on 
> transport layer information, meaning there are more failure modes to 
> detect.
>
I'm OK going into pathologies of "modifying" packets - but would really 
urge we do that in a separate document. There are *MANY* methods, many 
incentives, and many failure modes - and there is much that is not 
published.

In contrast, the devices and procedures that observe (possibly 
authenticated) headers.

> In QUIC, the latter is almost impossible.
> Aside from Initial Packets, the only possible actions are (1) drop the 
> packet, (2) accelerate or decelerate the packet, (3) change bits that 
> will cause authentication failure at the receiver, or (4) modify the 
> packet at UDP or below.

That seems rather a simple view! Traffic conditioning and monitoring is 
still something that can operate at the flow level and by address, even 
on IPsec flows for instance - just with less accuracy, and likely 
requiring more heuristics and with more and different "failure" modes 
e.g. that impact sequences of packets rather than deterministically drop 
packets with specific headers. The Internet been doing flow detection 
and characterisation for Firewalls, Traffic Classification, DOS 
detection, etc. Even devices that currently perform (mostly benign) ACK 
Filtering of TCP traffic can resort to Size-based queuing/filtering 
(also out there)... that would be less benign (more variable treatment), 
but is widely supported.

I'm unsure that's a helpful place to dig further into though.

> All of these are still measurable over a network segment, though with 
> different techniques from today. Most trivially but perhaps 
> impractically, a complete inventory of bits at the network ingress and 
> egress point will reveal all of this information.
>
That sounds rather niave to say in a RFC though, because the simple view 
doesn't reflect the ways in which per-flow measures are performed. These 
will differ depending on what sort of network segment you consider.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 Apr 2020 08:09:11 +0100

On 09/04/2020 21:20, Joseph Touch wrote:
>
>
>> On Apr 9, 2020, at 12:44 PM, Martin Duke <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> - Conversely, middlebox interference with headers does enable 
>> performance enhancing proxies for extraordinary link types like 
>> satellite.
>
> Those are only “extraordinary” only in the “been around for 50 years 
> in the Arpanet/Internet”. That understanding goes back as far as RFC 
> 346 and IEN 8.
>
> There are known ways to help TCP over such links that don’t involve 
> these sort of steps, documented as far back as RFC 2488, some of which 
> are now being incorporated (faster window growth and recovery, ala Hybla).
>
> I.e., just because a mechanism CAN rely on these headers doesn’t mean 
> that’s the only - or even safe - way to do so.
>
> Joe

I'm with Joe there are MANY ways that devices sitting in the network 
*do* presently change TCP headers. This is not at all restricted to 
specific technologies such as Satellite. TCP ACK 
filtering/decimation/etc is commonly used on a variety of paths to 
reduce return link traffic in WiFi, Docsis, LTE, etc. PEPs have split 
TCP in many ways where delay and/or loss is important, devices that 
track or change rwnd are out there, as are other devices that have 
modified other things for better or worese. However we already have 
RFC3135, RFC3449, a variety of header compression specs, and more 
recently RFC8404. All of which delve into these topics.

In an earlier thread, I motivated restoring the focus on methods that 
observe headers and do not "manipulate" these. It's true that when the 
WG decided to add the "ossification" examples at the start iof the 
document, that these were nearly all related to changing headers, but 
still I think the focus of the remainder should be on methods that do 
not change headers - That also is the set of methods that could be 
compatible with end-to-end authentication.

Gorry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 10 Apr 2020 09:44:02 -0500

(Please tell me when I become a pain)

> incentives, and many failure modes - and there is much that is not

I had mentioned this - not so completely - in a couple of posts during
WGLC, but the reasons I'd encourage not expanding the scope of this
document (now) are

   - There are many methods of dorking with transport headers,
   - Many of those methods aren't documented now,
   - Many of those methods are proprietary "secret sauce" of vendors making
   boxes that dork with transport packet headers, and they have no reason to
   help us describe them,
   - Our experience with the MARNEW IAB workshop (
   https://tools.ietf.org/html/rfc8462) was that we could't even get traces
   from 3GPP/GSMA wireless carriers to use as a baseline for the effect of
   middleboxes dorking with packets, not even anonymized traces, and
   - Our experience when we tried to document what session border
   controllers were doing to SIP calls was that what SBCs did was a moving
   target ("can we tell you about our LATEST product features?").

It's worth doing, if it can be done, but is it worth holding this document
up to significantly expand the scope and delay it while we find out?

Thinking about this now, I also wonder whether the audience for this
document is the same as the audience for an analysis of ways that
middleboxes dork with transport headers, but that's a minor question.

Do The Right Thing, of course.

Best,

Spencer

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Apr 2020 07:51:35 -0700

On Fri, Apr 10, 2020 at 12:45 AM Gorry Fairhurst <[email-masked]> wrote:
> I'm with Joe there are MANY ways that devices sitting in the network *do* presently change TCP headers. This is not at all restricted to specific technologies such as Satellite. TCP ACK filtering/decimation/etc is commonly used on a variety of paths to reduce return link traffic in WiFi, Docsis, LTE, etc. PEPs have split TCP in many ways where delay and/or loss is important, devices that track or change rwnd are out there, as are other devices that have modified other things for better or worese. However we already have RFC3135, RFC3449, a variety of header compression specs, and more recently RFC8404. All of which delve into these topics.
>
> In an earlier thread, I motivated restoring the focus on methods that observe headers and do not "manipulate" these. It's true that when the WG decided to add the "ossification" examples at the start iof the document, that these were nearly all related to changing headers, but still I think the focus of the remainder should be on methods that do not change headers - That also is the set of methods that could be compatible with end-to-end authentication.
>

Gorry,

I think the draft is trying to walk a fine line. The draft provides
several examples of presumably benevolent instances of passive
observation, however doesn't acknowledge there are deployed use cases
of modification. There are people that would probably agree that maybe
observation is okay but modification is detrimental. There are also
those that might say any use of transport information by intermediate
nodes is bad and leads to ossification, so both observation and
modification should be prevented. A third camp might say we've been
modifying TCP fields and our users are seeing great benefits so it's
okay. I don't think there is consensus on which of these viewpoints is
correct, however I believe that the goal of the draft is trying to
establish a balanced position without judgement, so not mentioning a
known use case that would definitely be affected by transport layer
encryption seems like an omission.

I'd also point out that if a transport protocol developer makes a
conscious decision to not encrypt some data in the transport layer for
the benefit of observation at intermediate nodes, it's just as easy
for them to also purposely not authenticate data so that intermediate
nodes could modify it (again this is independent of any judgement as
to whether intermediate nodes observing or modifying end-to-end data
is a good thing).

Tom

---

From: Martin Duke <[email-masked]>
Date: Fri, 10 Apr 2020 08:03:40 -0700

Very well everyone,

I'm conscious of coming in at a very late stage in the consensus -- if
we've already defined header modification as out of scope, then very well
(although it would be good to state that the Introduction, assuming I
didn't miss it there). That certainly negates my comments PEPs and
injection attacks as subjects, although that seems like an important part
of this landscape.

packets with specific headers.

By "almost impossible" I was exactly suggesting this kind of approach,
which I am fairly convinced will lead to tears. But people are going to do
what they're going to do, I guess.

Martin

On Fri, Apr 10, 2020 at 7:51 AM Tom Herbert <[email-masked]> wrote:

> performance enhancing proxies for extraordinary link types like satellite.
> >
> >
> > Those are only “extraordinary” only in the “been around for 50 years in
> the Arpanet/Internet”. That understanding goes back as far as RFC 346 and
> IEN 8.
> >
> these sort of steps, documented as far back as RFC 2488, some of which are
> now being incorporated (faster window growth and recovery, ala Hybla).
> >
> specific technologies such as Satellite. TCP ACK filtering/decimation/etc
> is commonly used on a variety of paths to reduce return link traffic in
> WiFi, Docsis, LTE, etc. PEPs have split TCP in many ways where delay and/or
> loss is important, devices that track or change rwnd are out there, as are
> other devices that have modified other things for better or worese. However
> we already have RFC3135, RFC3449, a variety of header compression specs,
> and more recently RFC8404. All of which delve into these topics.
> >
> observe headers and do not "manipulate" these. It's true that when the WG
> decided to add the "ossification" examples at the start iof the document,
> that these were nearly all related to changing headers, but still I think
> the focus of the remainder should be on methods that do not change headers
> - That also is the set of methods that could be compatible with end-to-end
> authentication.
> >
>
> Gorry,
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 Apr 2020 16:08:15 +0100

On 10/04/2020 16:03, Martin Duke wrote:
> we've already defined header modification as out of scope, then very 
> well (although it would be good to state that the Introduction, 
> assuming I didn't miss it there). That certainly negates my comments 
> PEPs and injection attacks as subjects, although that seems like an 
> important part of this landscape.
>
> To Gorry:
> which I am fairly convinced will lead to tears. But people are going 
> to do what they're going to do, I guess.
>
> Martin
>
Yes, and my own judgment (personal of course) is also that going too far 
down this particular direction could well end in tears.

Gorry

> On Fri, Apr 10, 2020 at 7:51 AM Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Fri, Apr 10, 2020 at 12:45 AM Gorry Fairhurst
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >
>     > On Apr 9, 2020, at 12:44 PM, Martin Duke
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     > Those are only “extraordinary” only in the “been around for 50
>     years in the Arpanet/Internet”. That understanding goes back as
>     far as RFC 346 and IEN 8.
>     >
>     > Additionally, ground nets often experience similar BW delay
>     products, which can be the dominant driver.
>     >
>     > There are known ways to help TCP over such links that don’t
>     involve these sort of steps, documented as far back as RFC 2488,
>     some of which are now being incorporated (faster window growth and
>     recovery, ala Hybla).
>     >
>     > I.e., just because a mechanism CAN rely on these headers doesn’t
>     mean that’s the only - or even safe - way to do so.
>     >
>     > Joe
>     >
>     > I'm with Joe there are MANY ways that devices sitting in the
>     network *do* presently change TCP headers. This is not at all
>     restricted to specific technologies such as Satellite. TCP ACK
>     reduce return link traffic in WiFi, Docsis, LTE, etc. PEPs have
>     split TCP in many ways where delay and/or loss is important,
>     devices that track or change rwnd are out there, as are other
>     devices that have modified other things for better or worese.
>     However we already have RFC3135, RFC3449, a variety of header
>     compression specs, and more recently RFC8404. All of which delve
>     into these topics.
>     >
>     > In an earlier thread, I motivated restoring the focus on methods
>     that observe headers and do not "manipulate" these. It's true that
>     when the WG decided to add the "ossification" examples at the
>     start iof the document, that these were nearly all related to
>     changing headers, but still I think the focus of the remainder
>     should be on methods that do not change headers - That also is the
>     set of methods that could be compatible with end-to-end
>     authentication.
>     >
>
>     Gorry,
>

---

From: Martin Duke <[email-masked]>
Date: Fri, 10 Apr 2020 08:09:27 -0700

Fair enough. I am willing to accept the judgment of the WG on this.

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 Apr 2020 16:24:39 +0100

On 10/04/2020 15:51, Tom Herbert wrote:
> I think the draft is trying to walk a fine line.
Yes. That's a very useful observation. I'm hoping if I disect this 
reply, I'll be able to see exactly the part(s) you are talking to.
> The draft provides
> observation,

I do *NOT* think the draft claims passive observation is benevolent, it 
may be, it may not be, that even might depend on usage.

The draft explicitly says in section 2:

    "This analysis does not judge
    whether specific practises are necessary, or endorse the use of any
    specific approach."

> however doesn't acknowledge there are deployed use cases
> of modification.

It was *NOT* intended to ignore that, only to note that any modification 
can be detected by authentication, and to set the context section 2.1 
did provide examples of this. There are other RFCs that talk more about 
that.

> There are people that would probably agree that maybe
> nodes is bad

It should *NOT* be making that call.

*EXCEPT* it should assert privacy concerns were appropriate.

> and leads to ossification,
It *SHOULD* state that.
> so both observation and modification should be prevented.
That's a judgement call this did *NOT* plan to make.
> A third camp might say we've been modifying TCP fields
This modification is a (sometimes sad, sometime not sad) reality.
> and our users are seeing great benefits so it's
> okay.
The intent is explicitly *NOT* to decide whether the spectrum of 
modifications are good or bad.
> I don't think there is consensus on which of these viewpoints is
> correct,
So, I think we may agree?
> however I believe that the goal of the draft is trying to
> establish a balanced position without judgement,
I agree.
> so not mentioning a

---

If we happen to agree on scope, then I think your present comment 
relates to section 2.1 and I assume this is somewhere around the text 
that starts:

    In-network measurement of transport flow characteristics can be used
    to enhance performance, control cost and improve service reliability.
    To support network operations and enhance performance, some operators
    have deployed functionality that utilises on-path observations of the
    transport headers of packets passing through their network.

... examples ...

    When network devices rely on the presence of a header field or the
    semantics of specific header information, this can lead to
    ossification where an endpoint has to supply a specific header to
    receive the network service that it desires.

    In all these cases, middleboxes with a hard-coded, but incomplete,
    understanding of transport behaviour, interacted poorly with
    transport protocols after the transport behaviour was changed.

    In contrast, transport header encryption prevents an on-path device
    from observing the transport headers, and therefore stops mechanisms
    being built that directly rely on or infer semantics of the transport
    header information.

Which sentences should be improved?

> to whether intermediate nodes observing or modifying end-to-end data

Agree (with the NiT that modification isn't necessarilly prevented by 
authentication: it's detected - that allows it to be prevented).

Is that somehow made unclear by a sentence somewhere that should be fixed?

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Apr 2020 08:50:46 -0700

On Fri, Apr 10, 2020 at 8:24 AM Gorry Fairhurst <[email-masked]> wrote:
> Yes. That's a very useful observation. I'm hoping if I disect this reply, I'll be able to see exactly the part(s) you are talking to.
>
> The draft provides
> I do *NOT* think the draft claims passive observation is benevolent, it may be, it may not be, that even might depend on usage.
>
> It was *NOT* intended to ignore that, only to note that any modification can be detected by authentication, and to set the context section 2.1 did provide examples of this. There are other RFCs that talk more about that.
>
> The intent is explicitly *NOT* to decide whether the spectrum of modifications are good or bad.
>
> If we happen to agree on scope, then I think your present comment relates to section 2.1 and I assume this is somewhere around the text that starts:
>
> Agree (with the NiT that modification isn't necessarilly prevented by authentication: it's detected - that allows it to be prevented).
>

Gorry,

Here is the pertinent sentence from the draft:

"It is important to understand how transport header information is
used by networks, to allow future protocol designs to make an informed
choice on what, if any, transport layer information to expose to the
network."

If this draft isn't going to dive into the uses of transport header
information being modified by the network then I suggest this sentence
should followed by a statement like:

"This document highlights uses of passive observation of transport
headers by network. Use cases where network nodes may modify transport
layer information are out of scope and described in [RFC...]."

Also, I'm not sure the term "expose" is well defined. Does this mean
to only make visible for observation, or to make it both visible and
modifiable? It might not matter here since there are no normative
requirements, but if the term were used elsewhere in a normative
context we may end up regretting any ambiguity.

Tom