Subject: [tsvwg] Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

From: The IESG <[email-masked]>
Date: Fri, 05 Feb 2021 16:39:58 -0800

The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Considerations around
Transport Header Confidentiality, Network
   Operations, and the Evolution of Internet Transport Protocols'
  <draft-ietf-tsvwg-transport-encrypt-19.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2021-02-19. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   To protect user data and privacy, Internet transport protocols have
   supported payload encryption and authentication for some time.  Such
   encryption and authentication is now also starting to be applied to
   the transport protocol headers.  This helps avoid transport protocol
   ossification by middleboxes, mitigate attacks against the transport
   protocol, and protect metadata about the communication.  Current
   operational practice in some networks inspect transport header
   information within the network, but this is no longer possible when
   those transport headers are encrypted.

   This document discusses the possible impact when network traffic uses
   a protocol with an encrypted transport header.  It suggests issues to
   consider when designing new transport protocols or features.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/

No IPR declarations have been submitted directly on this I-D.

---

From: "Black, David" <[email-masked]>
Date: Wed, 10 Feb 2021 22:53:23 +0000

Adding TSVWG list, Thanks, --David

-----Original Message-----
From: saag <[email-masked]> On Behalf Of Fernando Gont
Sent: Wednesday, February 10, 2021 5:08 PM
To: Benjamin Kaduk; [email-masked]
Subject: Re: [saag] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

[EXTERNAL EMAIL] 

Hello, Ben,

For some reason, I failed to find the relevant email message on the last-call list :-/

Some very specific comments on some parts:

* Section 5.1:

    For example, an
    endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide
    explicit transport layer information that can be observed and used by
    network devices on the path.

This is not as easy as it sounds. If you convey this information in 
multiple places (e.g. the transport protocol itself (that you cannot 
see), and e.g. IPv6 options), then the two might not much -- and devices 
could e.g. enforce a security policy on contents (e.g., the info in the 
IPv6 options), that the destination endpoint might possibly e.g. ignore.

* Section 5.1:

    Protocol methods can be designed to
    probe to discover whether the specific option(s) can be used along
    the current path, enabling use on arbitrary paths.

This might be a problem of "English as a second language", but the above 
text sounds to me like you can enable use of this feature on arbitrary 
paths.... where's I'd probably argue that what you can do is to 
*disable* the feature on paths where the feature cannot be used, such 
that you may still communicate (albeit without using the aforementioned 
feature).

Another simpler fix might be s/arbitrary/specific/

At the end of the day, when it comes to new features (i.e., features 
that folks do not currently rely on), the folks operating the networks 
trump everything else.  -- same as when folks decide to tunnel things on 
e.g. UDP, but then find out they are rate limited....

Thanks,
Fernando

On 10/2/21 03:25, Benjamin Kaduk wrote:
> You may recall that this draft has a storied history, and that the results
> of the third WGLC included adding a note for the IETF LC that the IETF
> consensus (or lack thereof) is unknown and needs to be explicitly
> determined for this draft
> (https://mailarchive.ietf.org/arch/msg/saag/PQfMkaORBJRE3zkKC8UfLv8JYhU/).
> 
> -Ben
> 
> On Fri, Feb 05, 2021 at 04:39:58PM -0800, The IESG wrote:
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 

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

_______________________________________________
saag mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Feb 2021 09:50:58 +0000

Thanks Fernando,

Please see below:

On 10/02/2021 22:53, Black, David wrote:
> see), and e.g. IPv6 options, then the two might not much -- and devices

This sounds similar to the case of explicitly exposing other 
information. In this case, the network will make decisions on what it 
sees or infers - without knowledge of the contents of the encrypted part 
Would you like to propose some text to help explain this?

> Another simpler fix might be s/arbitrary/specific/

The whole para currently reads:

    An arbitrary path can include one or more network devices that drop
    packets that include a specific header or option used for this
    purpose (see [RFC7872]).  This could impact the proper functioning of
    the protocols using the path.  Protocol methods can be designed to
    probe to discover whether the specific option(s) can be used along
    the current path, enabling use on arbitrary paths.

I think this last sentence can indeed be improved, and I suggest 
something like:

    Protocol methods can be designed to
    probe to discover whether the specific option(s) can be used along
    the current path, enabling or disabling their use on the path.

Is that better?

> e.g. UDP, but then find out they are rate limited....
Agree.
> Fernando
Best wishes,

Gorry

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 14:58:00 -0300

On 11/2/21 06:50, Gorry Fairhurst wrote:
[....]
> information.

Yes. ANything where you have two copies of the same information, and 
different parties are likely to act on different copies, is prone to the 
same thing.

(I guess, unless you can enforce that the two match, and have a strong 
requirement that all parties check that, and otherwise drop the packet 
-- something that in practice, many don't)

> In this case, the network will make decisions on what it 

I'd be happy to. I'll craft text and come back to you on this one.

>     the current path, enabling or disabling their use on the path.

That's perfect, and indeed addressed my comment.

Thanks!

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 Feb 2021 11:18:43 -0700

> different parties are likely to act on different copies, is prone to the
Fernando,

When the transport layer is encrypted, network devices would only see
the plaintext EH and that is only what that is what they can act on.
At the destination, we could try to rectify transport information in
HBH with decrypted plaintext transport headers, but I suspect that
wouldn't typically be done. The HBH information is only operationally
useful to the network, not the transport endpoints that have access to
the transport header. The only point of the end host comparing the
data would be to enforce the network's security policy, but it's not
common that end hosts actually know what the network security policies
are.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 15:40:02 -0300

On 11/2/21 15:18, Tom Herbert wrote:
[...]
> the transport header.

Then this is what an attacker would do:
He/she would advertise on a HBH option something that looks sensible to 
the guy enforcing a network-based security policy, and then at transport 
would do what he/she needs to do. :-)

e.g., HBH could advertise that my packets are directed to ports 80/443, 
while in transport they are actually directed to port, say, 22.

> The only point of the end host comparing the

The point for the end-node comparing both values is so that it makes 
sense in the first place to enforce a security policy based on e.g. 
HBH-conveyed information.

Otherwise, the operator/admin knows that attackers will do what I'd 
suggested above, and they wouldnt even bother to try to enforce security 
policy which is circumvent-able  "by design", so to speak :-)

If consistence cannot be guaranteed, then the mechanism won't be useful 
for enforcing security policies.

Thanks,

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 11 Feb 2021 11:10:42 -0800

> while in transport they are actually directed to port, say, 22.

Wasn't this the sort of problem that AH was intended to solve?

Mike Heard

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 Feb 2021 12:11:07 -0700

> while in transport they are actually directed to port, say, 22.
It's more likely that information in the HBH would be generic and
abstract, afterall the whole point of encrypting the transport header
is to hide information from the network that it doesn't require, not
to just blindly volunteer the same information somewhere else in the
packet. Port numbers, for instance, are not required for delivery and
in fact are prone to misinterpretation in the network (RFC7605)-- IMO
it makes no sense to put those in a HBH option.

Regardless of HBH though, if the preponderence of transport headers
are encrytped then network security policiy that relies on the
information will need to change.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 16:27:47 -0300

> information will need to change.

The folks running networks might as well argue that if you want your 
protocol to be successfully deployed (or at all deployed), your protocol 
might need to change.

It's a tussle. ANd I see valid arguments on both sides.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 Feb 2021 12:43:19 -0700

> protocol to be successfully deployed (or at all deployed), your protocol
Perhaps, but in order to change the protocol to satisfy the
requirements of folks running networks, we'd need to know *what* the
requirements are. For instance, if someone were to say that networks
require more information than what is in the IP header to successfully
deliver packets, then I will immediately ask that they specify
*exactly* what information they need. Until/unless that is answered we
are left guessing as to what may or may not be acceptable in various
networks and the tussle continues.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 18:19:20 -0300

[....]
> requirements are.

src IP address, dst ip address, upper layer protocol type, src port 
number, dst port number

> For instance, if someone were to say that networks
> deliver packets,

That assumes that networks just blindly forward packets based on the dst 
(and possibly src) addresses. But operational practice suggests that 
that's not the case.

Thanks,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Feb 2021 16:44:30 -0500

> Then this is what an attacker would do: He/she would advertise on a HBH
    > option something that looks sensible to the guy enforcing a
    > network-based security policy, and then at transport would do what
    > he/she needs to do. :-)

    > while in transport they are actually directed to port, say, 22.

That's silly amount of subterfuge.
Since you have the cooperation of the target machine, just run SSH on port 443.
In fact,  https://packages.debian.org/buster/sslh  does this for you.

Network middle boxes need to get the *($%#$% out of transport protocols.
Back in 1996 (!) I explained how to have authorized audit boxes for IPsec
using securityhop-by-securityhop ESP and end-to-end AH.
It requires the blessing of the end points, and we regularly do way more
complex and stupider things in TLS today.
People thought my solution was crazy.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 19:04:33 -0300

On 11/2/21 18:44, Michael Richardson wrote:
> Since you have the cooperation of the target machine,

Not always. And not always you're so free to change the service port.

> just run SSH on port 443.

Indeed. But that's not the point. The point is that if the network wants 
to block specific traffic, I needs to tell what the traffic is about.

> Network middle boxes need to get the *($%#$% out of transport protocols.

There are operational reasons for which the peek at transport.

Thanks,

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Feb 2021 17:31:51 -0500

> networks and the tussle continues.

15+ years, when "transport-friendly ESP" was litigated (and to my surprise
got a protocol number), the 3G people went on and on about how much better
they could do if we (the IPsec people) would show them TCP information.
I asked, repeatedly, for details of this supposed improvement.
I got nothing in justification.  My request was simple: if you want me to
increase my risk, then show me what the benefit is.
(_Show me the money_)
I now know that really, they were dealing with ad-hoc solutions to
bufferbloat, but they didn't know that then.

BTW: nobody uses TF-ESP. It's totally and completely dead. There was never
any benefit worth the risk.

Fernando says they need src/dst port, but I disagree.
They want every bit they can get, including the encrypted insides of TLS, but
they have no idea really, what legal things they actually want to do with it.

Showing your layer-4 header is unlawful search in my opinion.
The pen-registry only needs to have the destination number to connect the call.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 Feb 2021 16:19:29 -0700

> they have no idea really, what legal things they actually want to do with it.
That's why I chose my words carefully and asked that "they specify
*exactly* what information they need". What MUST a host stack or
application expose to the network concerning it's traffic? (i.e. we
need the draft describing this in normative language).

It's also hard not to notice how similar these discussions are with
those that occurred when TLS was being brought up. Some network
providers argued vehemently that if they aren't able to inspect HTTP
payload they can't provide the services and security their customers
need. They lost those arguments, as I suspect similar arguments that
transport layer shouldn't be encrypted will also fail.

Tom

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 22:55:48 -0300

> increase my risk, then show me what the benefit is.

Well, this is how operators' version of it: RFC7872. -- i.e.: "Your ESP 
packets probably don't go through. **Show me the money**".

> Fernando says they need src/dst port, but I disagree.

Ask operators. That's what I did.

> they have no idea really, what legal things they actually want to do with it.

There's folks that probably want as much as they can get.. But the vast 
majory of them want IP `transport header, for load-balancing, variety of 
ACLs, et al.

[...]
> The pen-registry only needs to have the destination number to connect the call.

For networks where packets flow frelly between any arbitrary nodes, yes.

I doubt such networks exists, except in specific walled gardens.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 11 Feb 2021 23:07:14 -0300

[....]
> transport layer shouldn't be encrypted will also fail.

FWIW, I'm certainly *not* arguing that the transport layer should not be 
encrypted. I'm simply pointing out that operators do more things with 
packets that blindly forward packets on a per-packet and per-dst-address 
basis. And that that, there are consequences of them not being able to 
access IP+transport metadata.

When it comes to QUIC, it could well be the case that then only thing 
they care in this respect is IP header + UDP header... and e.g. rate 
limit as they do for some other UDP traffic.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Fri, 12 Feb 2021 07:47:12 -0700

Fernando,

Yes, this draft describes those consequences. But what has not been
adequately discussed IMO has been the negative consequences of network
devices acting on transport layer information. In particular, this
leads to protocol ossification and creates a myriad of impediments for
application developers trying to build applications to work across the
whole Internet. For instance, if you say that QUIC is the only UDP
protocol allowed on the Internet., i.e. identified by UDP port 443,
then how could we ever deploy a new UDP protocol? This also leads to
arms escalation between application developers and network operators,
for instance if I do know that UDP port number 443 is the only port
number allowed the network then I'll simply wrap my new UDP protocol
in a UDP datagram to 443. You might complain that such things might be
purposely bypassing your network security, yes they do, however host
developers have no obligation to abide by some arcane set of network
security policies that are unwritten and inconsistent across the
Internet.

I do believe that network operators and their users could benefit from
getting more information in a packet than just Ip addresses. But I
also believe that exposure of information should be volutary as
opposed to mandatory, and it should be be very clear what the value is
the to the user in exposing information. IMO, HBH is the best vehicle
to express this information and there is some good work in Network
tokens, FAST, and APN around this.

Tom

---

From: Sebastian Moeller <[email-masked]>
Date: Fri, 12 Feb 2021 09:23:04 +0100

Hi Tom,

More below inline, prefixed with [SM].

On 11 February 2021 20:43:19 CET, Tom Herbert <[email-masked]> wrote:
>*exactly* what information they need.

[SM] While I only run my own home network, and hence only marginally qualify network operator at best, I do use per-flow queueing, currently based on a 5-tupel, ot dst/src IP addresses, protocol, and dst/src port. That works amazingly well, so if possible I would like to be able to keep getting access to a stable representation of the port numbers, but I do not care whether these stable representations are veridical or hashed, and I don't care about an occasional hash collision.
Since I am vaguely familiar with game theory, I would very much like to be able to access the same field as used by the protocol itself (as anything that can be gamed for an undeserved advantage, will be gamed). That is something like IPv6's flowlabel is less ideal than the real port numbers.

Best Regards
        Sebadtian

 Until/unless that is answered we

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2021 19:34:13 -0300

Hi, Tom,

[....]
> whole Internet. For instance, if you say that QUIC is the only UDP

The fact that QUIC employs UDP should probably already say a lot. :-)

(yes, they were right, and very pragmatic about it)

> then how could we ever deploy a new UDP protocol? 

Please see above.

> This also leads to

And operators might as well argue that they won't leave their production 
networks open to attack for the sake of not constraining future protocol 
development....

> the to the user in exposing information.

If it's voluntary, in many (most?) cases it cannot be relied upon, and 
hence is not of much use.

> IMO, HBH is the best vehicle

RFC7872 seems to suggest otherwise.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Fri, 12 Feb 2021 18:53:02 -0700

> RFC7872 seems to suggest otherwise.
I disagree. RFC7872 was one snapshot in time and is now coming up on
five years since it was published; since then RFC8200 was published
with relaxed requirements for intermediate nodes and there is a lot
more active work on extension headers. Besides that, we don't need or
expect 100% of the Internet to support EH, we can use it
opportunistically when we know the path works (e.g. the destination is
a server within the user's provider network that supports the
features).

Tom

---

From: Fernando Gont <[email-masked]>
Date: Fri, 12 Feb 2021 23:07:54 -0300

On 12/2/21 22:53, Tom Herbert wrote:
[....]
> more active work on extension headers.

There's a lot of active work on EHs, yes. You can use them in limited 
domains. But you'll likely have a bitter experience otherwise.

(To share you my own: I recently replaced my IPv4-transport tunnels with 
IPv6-transport tunnels... but but some failed. Why?  Because, Linux 
employs (by default) a tunnel encapsulation limit option, which requires 
a DO header to be inserted. And such packets often get dropped)

You may get the same when trying to use ESP, too.

RFC8200 changed the processing of HBH. But there are general 
implications of EHs (in general) -- RFC8200 has changed nothing about 
that (and in fact, it couldn't have).

> Besides that, we don't need or

That's indeed a different scenario (a so-called "limited domain") -- 
i.e. your network, your rules.

But I believe the discussion here is about the implications on an 
Internet-wide scope.

Thanks,