Subject: [tsvwg] To encrypt or no encrypt in draft-ietf-tsvwg-transport-encrypt-01

From: Tom Herbert <[email-masked]>
Date: Tue, 20 Nov 2018 11:02:50 -0800

Hello, I have a few comments on the the draft relating considering the
trade offs of encrypting the transport header..

My general comment is that IMO the draft is too biased towards not
encrypting transport headers. The benefits of encrypting the transport
header aren't fully explored. In particular, the benefits of encrypted
the transport header should be in its own section and elaborated to
provide a balanced comparison with section 6. There are several
benefits that I think are missing in the current description also,
like the fact that encryption deters intermediate nodes from
maintaining transport state, authentication prevents intermediate
nodes from changing transport header, the end to end model is upheld.
saving the costs of DPI into the transport layer in hardware.

I think there should more discussion around the use of extension
headers as the current draft too easily dismisses them as not being
viable. From a protocol perspective, extension headers clearly are a
superior solution as they are a protocol agnostic means to let hosts
signal the network. For instance the draft talks a lot about
measurement, and in fact there are now proposed extension headers to
provide that sort of thing.

Also, both the benefits and implications need to be better quantified
if a protocol developer is considering the trade offs. For instance,
the draft says:

"Some Internet users have valued the ability to protect identity, user
location, and defend against traffic analysis"

I would like to the meet the Internet user that is not concerned about
their privacy and security! I believe this applies to all users and
the need for security and privacy is ubiquitous especially as the
Internet evolves to support "life critical" applications.

To contrast, the draft also says:

"Independent observation by multiple actors is important for
scientific analysis."

"Important" is relative term that's used in several places in the
draft in describing the benefits of not encrypting transport header. I
don't know why this is important, or at least why this could be more
important than something like user security. Neither is it clear that
the need scientific for scientific analysis creates protocol
requirements that are applicable across the whole Internet.

To me, it's clear what the costs are in not securing transport header
(loss of security, privacy, and increased likelihood of protocol
ossification), but it's not clear what the what the tangible benefits
are to the users if the transport header is purposely exposed to the
network? Will transport protocols become more efficient somehow? Is
this actually stronger security somehow? Is measurement based on
transport header information so understood and specified that it's
used every where and all user benefits somehow?

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 Nov 2018 08:09:28 +0000

Thanks for your feedback, we will be revising the draft this week.

On 20/11/2018, 19:02, Tom Herbert wrote:
> trade offs of encrypting the transport header.
>
> encrypting transport headers.
The document is about what we understand based on what is being 
currently done.
> The benefits of encrypting the transport header aren't fully explored.
> In particular, the benefits of encrypted
On this:
> viable.
That was not intended:
The current text says:
"... measurements may be made by adding additional protocol headers 
carrying operations, administration and management (OAM) information to 
packets at the ingress to a maintenance domain (e.g., an Ethernet 
protocol header with timestamps and sequence number information using a 
method such as 802.11ag or in-situ OAM (I-D.ietf-ippm-ioam-data) and 
removing the additional header at the egress of the maintenance domain. 
This approach enables some types of measurements, but does not cover the 
entire range of measurements described in this document."

- Do you know of more to say? I suggest we change the final para in that 
section to say:
"Current measurements suggest it can be undesirable to rely on methods 
requiring the presence of network options or extension headers..."
>  From a protocol perspective, extension headers clearly are a
It currently said: "... Another example of a network-layer approach is 
the IPv6 Performance and Diagnostic Metrics (PDM) Destination Option. ..."
> location, and defend against traffic analysis"
Actually the full sentence reads:

"Some Internet users have valued the ability to protect identity, user 
location, and defend against traffic analysis, and have used methods 
such as IPsec Encapsulated Security Payload (ESP), Virtual Private 
Networks (VPNs) and other encrypted tunnel technologies. "

This could have been written:

"Internet users who have valued the ability to protect identity, user 
location, and defend against traffic analysis, have used methods such as 
IPsec Encapsulated Security Payload (ESP), Virtual Private Networks 
(VPNs) and other encrypted tunnel technologies. "
> their privacy and security!
The concerns are not all the same - and the threats are not all the same.
> I believe this applies to all users and
I'd agree that "life critical" applications demand more consideration of 
security and privacy.
> "Independent observation by multiple actors is important for
I think this is a basis for scientific investigation, at least where I work.
> important than something like user security.
The thing is Sceurity isn't something that just can be provided - it is 
always risk-assesment, more "encryption" is a trade-off, and inpsecting 
packet headers is not the only threat that would need to be considered.
> Neither is it clear that
Taking one important transport consideration as ane example: congestion 
collapse there is a long standing tradition of using research data to 
select congestion control methods.
> network?
We did not want to predict the future. We neither of us have crystal 
balls. So all we can do is describe the network we know, note current 
practice, and try to understand how the growing volume of encrypted 
traffic could impact current practice.
>   Will transport protocols become more efficient somehow?
Some people think that has happened with research and measurement of TCP.
> Is this actually stronger security somehow?
I could imagine operators of some networks being concerned about 
secuirty. There could be boxes to help you detect threats or manage your 
security and prevent people misusing your company network, or protecting 
you from DDOS, whatever. One would need a trust relationship to make 
this useful, but in some cases that may be possible. But we don't plan 
to go there in this ID.
> Is measurement based on
Thanks agian,

Gorry

---

From: <[email-masked]>
Date: Wed, 21 Nov 2018 10:32:53 +0000

Hi Tom,

[snip]
[TH] Is measurement based on transport header information so understood and specified that it's used every where and all user benefits somehow?

[RG]
Unfortunately not. In "An Internet-Wide Analysis of Traffic Policing" Tobias Flach et al. (research done by University of Southern California and Google) recommends some "Solutions for ISPs": 

"The enforcing ISP could configure policers with smaller burst sizes. This would prevent TCP’s congestion window from growing too far beyond the policing
rate." 

"Thus, ISPs that employ shaping have to trade off between minimizing loss rates through larger buffers that introduce higher memory costs, and minimizing latency through small buffers."

An ISP likely benefits from being able to measure some TCP related properties when starting to follow this guidance. 

Regards,

Ruediger

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Nov 2018 09:18:40 -0800

> requiring the presence of network options or extension headers..."

Gorry,

I disagree with any conclusion drawn from RFC7872, which I assume are
you are referring to, that extension headers should be or have been
deprecated. That precludes the possibility that the situation could be
improved. I believe it can be, and steps are being taken to make them
more practical. Please see my presentation to 6man wg "Making IPv6
options an option".

The advantage of extension headers is that they were designed to carry
the sort of information that is being requested in this draft. But, as
opposed to blindly exposing the whole transport header, end hosts have
the ability to selectively control what is exposed to the network and
it's transport protocol agnostic. If the host knows that the network
needs RTT it can share that information. If the network wants to know
which packets are retransmissions (something you can't get from TCP
header, but we've been asked to provide before) then that can be
provided in an EH. In fact, one could convey arbitrary internal
transport state information, like CWND,  to the network if needed.
Furthermore, the exposed information could be scoped in EH by
encryption. For example, an end host, might trust its local network,
but not the whole Internet so it can limit exposure-- this is what we
are doing in FAST.

A few years ago there was a very similar discussion in IETF about the
implications of turning up TLS on transport payloads. There were
similar concerns raised that ISPs were losing access to valuable
information in http that could be used to optimize communications.
But, in the end, the need for security was the greater good and all
major content providers have turned it on. I believe the same path
will be followed for new transport protocols (as demonstrated by
QUIC). The security benefits, as well as the defense against protocol
ossification, outweigh the benefits of the network to parse the
transport layer. While this might be viewed as a loss for networks
today, I think it creates an opportunity to promote networks and hosts
to work in concert to solve problems. Hosts may in fact be willing to
share transport layer information if it benefits their communications,
but they will want to do that with an understanding of how the
information will be used and who is accessing the information. Sharing
transport layer information should be explicit and extension headers
are the right vehicle for that.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 Nov 2018 17:37:29 +0000

On 21/11/2018, 17:18, Tom Herbert wrote:
> On Wed, Nov 21, 2018 at 12:09 AM Gorry Fairhurst<[email-masked]>  wrote:
> deprecated.
I do not understand why you think that I think so.

(To be clear: If you saw my talk in 6MAN with Bob Hinden, you would 
realise I also actually am proposing a hop by hop extension, albeit with 
intial deployment targeting data centres - but it would be nice to work 
more places).
> That precludes the possibility that the situation could be
> improved.
That's why I rephrased to "currently". We did measurements this week, 
and clearly there is scope for improvement in deployability, but then I 
think that important use cases are only just emerging, so this could 
indeed change.
> I believe it can be, and steps are being taken to make them
> provided in an EH.
I'm interested, but unless you tell me different, I'd guess the 
retransmission thing has not been widely deployed - if it has what is 
operational experience of using it?
>   In fact, one could convey arbitrary internal
And that returns information to the non-encrypted part, which could
have utility - of course, providing it matches what the protocol is 
actually doing.
> information in http that could be used to optimize communications.
Yes, but that really is a very different thing. I'm surprised you are 
even suggesting that http could be a cause of congetsion collapse or 
unfair sharing for the Internet when it is carried over TCP.
> QUIC).
You may well be correct, the ID we're talking about does not preclude 
that in any way.
> The security benefits, as well as the defense against protocol
> to work in concert to solve problems.
Maybe - and that's a good conversation to have.
> Hosts may in fact be willing to
> transport layer information should be explicit
That may well make some sense, if commonly done.
> and extension headers are the right vehicle for that.
And I am not sure that thsi use yet has consensus, but is fun to 
speculate with.

Just to be sure - this document was never intended to sketch the rules 
for going forward or to restrict the design space, it was trying to 
bring into the open what has been done with transport headers in the 
network (excluding PEPs - which are kind of another interesting story) 
and what functions we should consider going forward.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Nov 2018 10:33:39 -0800

> think that important use cases are only just emerging, so this could

Right, so the possibility of using EH in lieu of unencrypted transport
headers should be expounded upon here.

> unfair sharing for the Internet when it is carried over TCP.

Who said anything about congestion collapse? Unless I'm misreading the
draft, the premise seems to be that same intermediate devices are
consuming information from transport headers in order to optimize
communication. If the transport layer is encrypted, then those
optimizations are loss. That's effectively the same thesis offered by
the opponents to encrypting payload.

But, I will extrapolate from your point that networks need transport
layer information because they can take an active and important role
in preventing congestion collapse and fair sharing of resources. I'll
also assume that "TCP" here is a placeholder for any transport
protocol that runs over IP, lest TCP is the now only protocol that
we're allowed to run over the Internet. Given that, then the pertinent
question to be asked by a transport protocol developer is "What are my
requirements? What specific transport layer header information MUST be
exposed to the network to achieve proper operation? What is the best
way to meet those requirements and my users' requirements for
security?"

> and what functions we should consider going forward.
Yes, that is important, but the document's subject are specifically
the implications of network operation and evolution of the Internet.
The conclusion of this document seems to be that the implications
require the protocol designer to make a fundamental choice:

"The choice of whether future transport protocols encrypt their
protocol headers therefore needs to be taken based not solely on
security and privacy considerations, but also taking into account the
impact on operations, standards, and research."

That makes it sound as though this is a binary decision at protocol
design time. Either encrypt and get security, or don't encrypt and get
benefits of network participating in transport protocols. As I pointed
out, I don't believe this is necessarily a such a fateful decision.
There should be alternatives. What we want is both security and hosts
and the network productively working together. Even if network
operations is currently tuned to optimizing and parsing just TCP,
deriving a more generic, extensible, and protocol agnositic model is
certainly relevant to the evolution of the Internet.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 21 Nov 2018 19:56:05 +0000

On 21/11/2018, 18:33, Tom Herbert wrote:
> On Wed, Nov 21, 2018 at 9:37 AM Gorry Fairhurst<[email-masked]>  wrote:
If it is used, please point me towards what is actually deployed.
> way to meet those requirements and my users' requirements for
That may well be the next stage. That's a good question to work upon.
> impact on operations, standards, and research."
Thanks for seeing this, I think there is scope to change this.
There's a section that says:
"A transport protocol design can encrypt selected header fields, while 
also choosing to authenticate the entire transport header. This allows 
specific transport header fields to be made observable by network 
devices. ...."
> certainly relevant to the evolution of the Internet.
I think the point that not all headers need to be treated the same can 
reasonably be added to the conclusion. ... and I'll propose mentioning 
extension headers alongside where we mention DSCP in the network layer.

- and I like the idea of designing a generic protocol agnositic model 
for this, if there was some way to suggest people would deploy it, that 
is another proposal for people to consider.

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Nov 2018 12:59:02 -0800

> specific transport header fields to be made observable by network

You could do that, but at the cost of considerable added complexity to
each transport protocol. This also requires changes that would hit the
problem of protocol ossification. For instance, if TCP were modified
to do this one would have to consider how existing deployed
implementations deal with the change. Also, doing a lot of work for
this in a transport protocol other than UDP or TCP might be a waste of
time. It's clear middlebox vendors are motivated to only support the
most commonly deployed transport protocols.

> is another proposal for people to consider.
Another point I can make in favor of a generic approach is that
deriving information from transport headers is limited. Even if a
protocol designer decides to not encrypt so that the network can parse
the headers, there's no guarantee the information is accessible in
packets at runtime. For instance, TCP header is currently not
encrypted, but if it's buried in an encapsulated packet or an
encrypted tunnel the network has no access to the information. Putting
the information in the network layer headers resolves this. There's
already one example in that the flow label can be used to associate
different packets as belonging to the same flow even if the transport
header and its ports aren't visible.

Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 21 Nov 2018 22:12:09 -0800

> header and its ports aren't visible.
Or can either group different transports together by using a common flow
label, or allow different parts of a single transport connection to be
treated as different flows using different flow labels.

Let's not forget - transport info is defined only at the endpoints;
everything else that even tries to look at them is making an assumption
about their meaning anyway.

Joe

---

From: Derek Fawcus <[email-masked]>
Date: Sat, 24 Nov 2018 19:22:53 +0000

On Wed, Nov 21, 2018 at 12:59:02PM -0800, Tom Herbert wrote:
> 
> Also, doing a lot of work for

So which other existant transport protocols would you desire middleboxes support?
I know of some where UDP-Lite and DCCP (and partial SCTP) support were added,
simply because they're a trival extension over supporting UDP.

SCTP is a non trivial extension for NAT, but again a trivial extension
for a naive firewall.

As long as one is aware of them, one can handle all bar the SCTP NAT case
more or less for free.  The problem is being aware of them, and the lifetime
of deployed boxes.

DF

---

From: Tom Herbert <[email-masked]>
Date: Sat, 24 Nov 2018 12:22:17 -0800

> So which other existant transport protocols would you desire middleboxes support?

All of them, including those that haven't been invented yet. The only
way this is possible is if middleboxes stop tying to support one
transport protocol at a time, and instead implement their
functionality using generic mechanisms that apply across all transport
protocols.

> more or less for free.  The problem is being aware of them, and the lifetime

The awareness requirement is _the_ problem. We need solutions that
don't require middelboxes be aware of specific transport protocols.
For instance, with IPv6, the NAT problem should be going away.
Firewall and Service Tickets (FAST) include a proposal achieve the
functionality of stateful firewalls without requiring any DPI,
transport state in the network. or transport protocol specific
implementation in middleboxes.

Tom

---

From: Derek Fawcus <[email-masked]>
Date: Sat, 24 Nov 2018 21:53:07 +0000

> For instance, with IPv6, the NAT problem should be going away.

Except IPv6 has been in that state for the last 20 years,  recently 
it has started to gain increased use, but I rather suspect that NAT
is going to be a fixture for at least the next 20 years.

So the only viable approach I see in the short term is the QUIC like
approach, things built upon UDP.

> implementation in middleboxes.

The problem I see with the FAST approach, is a chicken and egg one in
connecting from client to server.  The client may well acquire a ticket
to allow traffic to pass its local firewall, but it does nothing at
the start of the connection for aiding passing any firewall at the server.

So since these servers already have stateful firewalls in front of them
(examining TCP/UDP headers), I expect they will remain.  At most one
could have a traditional firewall at the server, accepting initial
packets at some low rate (hence state required), and once connected
create a ticket for subsequent packets to get better service w/o
header knowledge; but you've still got that protocol ossification.

The only other way I see around that is if the local ticket agent
communicates with a remote agent (say using UDP), to get a remote
ticket up front, and then the client initiates its proper transport
connection including both tickets.  That way the network can be
agnostic of that transport connection, but would still know about
UDP, and have a traditional firewall for UDP.  So also an extra RTT
in making a connection.

(Is draft-herbert-fast-03 the most recent version?)

DF