Subject: Re: [Network-tokens] [TLS] Network Tokens I-D and TLS / ESNI

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Jul 2020 15:46:44 -0700

> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
> >
> >
> >
> > On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema
> > <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >     On 6/25/2020 11:11 PM, Melinda Shore wrote:
> >
> >         On 6/25/20 3:29 PM, Erik Nygren wrote:
> >
> >             One quick comment is that binding tokens to IP addresses
> >             is strongly counter-recommended.
> >             It doesn't survive NATs or proxies, mobility, and it is
> >             especially problematic in IPv6+IPv4 dual-stack environments.
> >
> >         There's been a bunch of past work done developing similar
> >         sorts of protocols, and for what it's worth I wrote up a
> >         mechanism for using address tags and address rewrites, but
> >         unfortunately Cisco decided to patent it. Anyway, thre are
> >         ways of dealing with this problem that don't require binding
> >         the address to the token ("all technical problems can be
> >         solved by introducing a layer of indirection").
> >
> >     There is also an interesting privacy issue. The token is meant to
> >     let a provider identify some properties of the connection. I
> >     suppose there are ways to do that without having it become a
> >     unique identifier that can be tracked by, well, pretty much
> >     everybody. But you have better spell out these ways.
> >
> >
> > You are right that for the duration of a token, one could use it to
> > identify an endpoint (either application or most likely a combination
> > of user/application). Tokens expire and intermediary nodes cannot
> > correlate tokens with each other as they are encrypted. So tracking
> > cannot happen across different tokens (of the same user), or between
> > token-enabled and non-token-enabled traffic. I guess similar type of
> > tracking happens when users are not behind a NAT and their IP address
> > can be used to track them. Would it make sense to have the user add a
> > random value to a token, and then encrypt it with the network's public
> > key, so that each token becomes unique and cannot be tracked. Would
> > that address the privacy concerns better?
>
> That would certainly be better. The basic rule is that any such
> identifier should be used only once. Pretty much the same issue as the
> session resume tickets.
>
> >
> >     Then, there are potential interactions with ESNI/ECH. The whole
> >     point of ECH is to keep private extensions private. The token
> >     extension would need to be placed in the outer envelope, which is
> >     public but does not expose seemingly important information like
> >     the SNI or the ALPN.
> >
> >
> > Ah, I was not aware that ESNI can now include all CH extensions -
> > thanks for the pointer. Yes, the token would have to stay on the outer
> > envelope so the network can process it. The main idea is you can
> > encrypt everything that is client-server specific, and just keep a
> > token to explicitly exchange information with trusted networks.
> >
> >     There are also implications for QUIC, in which the TLS data is
> >     part of an encrypted payload. The encryption key of the TLS
> >     carrying initial packets is not secret in V1, but it might well
> >     become so in a future version.
> >
> >
> > Haven't looked into QUIC yet, but is on the list of things to do. If
> > anyone is interested to help us explore this, please let me know.
>
> You may want to have that discussion in the QUIC WG. If you are building
> some kind of QoS service, you probably want it to work with QUIC too.
>
I view the use of TLS to carry tokens as a temporary hack to make
something work quickly. There are several obvious problems that
prevent that from being the general solution: it's specific to
TLS/TCP, it requires intermediate nodes to parse into TCP payloads, it
requires tracking connection state in the network.

IMO, the real solution is to encode tokens in HBH options. This
addresses the aforementioned problems, works with any transport
protocol (including QUIC, IPsec tunnels, arbitrary encapsulations),
eliminates state and need for DPI in the network.

Of course the naysayers will bring up the fact that HBH options aren't
ubiquitously supported by routers. I think there are some ways around
this:
   1) Network tokens really only make sense to the network that issued
them, so their use could be restricted to that limited domain where
they are consumed.
   2) Packets that are leaving the limited domain that carry network
tokens in HBH options could be filtered and the HBH option is removed
(see proposal draft-herbert-6man-eh-attrib-01 to allow intermediate
nodes to remove options).

Limiting the visibility of tokens to the local network also helps
their security.

Tom

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Thu, 09 Jul 2020 23:28:13 +0000

On Thu, Jul 09, 2020 at 3:46 PM, Tom Herbert < [email-masked] > wrote:

>>> On Fri, Jun 26 , 2020 at 7:29 AM, Christian Huitema
>>> < huitema@ huitema. net ( [email-masked] ) <mailto: huitema@ huitema.
>>> net ( [email-masked] ) >> wrote:
>>> 
>>> 
>>> 
>>> One quick comment is that binding tokens to IP addresses is strongly
>>> counter-recommended.
>>> It doesn't survive NATs or proxies, mobility, and it is especially
>>> problematic in IPv6+IPv4 dual-stack environments.
>>> 
>>> 
>>> 
>>> There's been a bunch of past work done developing similar sorts of
>>> protocols, and for what it's worth I wrote up a mechanism for using
>>> address tags and address rewrites, but unfortunately Cisco decided to
>>> patent it. Anyway, thre are ways of dealing with this problem that don't
>>> require binding the address to the token ("all technical problems can be
>>> There is also an interesting privacy issue. The token is meant to let a
>>> provider identify some properties of the connection. I suppose there are
>>> ways to do that without having it become a unique identifier that can be
>>> tracked by, well, pretty much everybody. But you have better spell out
>>> these ways.
>>> 
>>> 
>>> 
>>> 
>>> identify an endpoint (either application or most likely a combination of
>>> user/application). Tokens expire and intermediary nodes cannot correlate
>>> tokens with each other as they are encrypted. So tracking cannot happen
>>> across different tokens (of the same user), or between token-enabled and
>>> non-token-enabled traffic. I guess similar type of tracking happens when
>>> users are not behind a NAT and their IP address can be used to track them.
>>> Would it make sense to have the user add a random value to a token, and
>>> then encrypt it with the network's public key, so that each token becomes
>>> unique and cannot be tracked. Would that address the privacy concerns
>>> better?
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> That would certainly be better. The basic rule is that any such identifier
>> should be used only once. Pretty much the same issue as the session resume
>> tickets.
>> 
>> 
>> 
>>> 
>>> 
>>> Then, there are potential interactions with ESNI/ECH. The whole point of
>>> ECH is to keep private extensions private. The token extension would need
>>> to be placed in the outer envelope, which is public but does not expose
>>> seemingly important information like the SNI or the ALPN.
>>> 
>>> 
>>> 
>>> 
>>> Ah, I was not aware that ESNI can now include all CH extensions - thanks
>>> for the pointer. Yes, the token would have to stay on the outer envelope
>>> so the network can process it. The main idea is you can encrypt everything
>>> that is client-server specific, and just keep a token to explicitly
>>> exchange information with trusted networks.
>>> 
>>> 
>>> 
>>> 
>>> There are also implications for QUIC, in which the TLS data is part of an
>>> encrypted payload. The encryption key of the TLS carrying initial packets
>>> is not secret in V1, but it might well become so in a future version.
>>> 
>>> 
>>> 
>>> 
> something work quickly. There are several obvious problems that prevent
> that from being the general solution: it's specific to TLS/TCP, it
> requires intermediate nodes to parse into TCP payloads, it requires
> tracking connection state in the network.
> 
> 
> 
> 
> IMO, the real solution is to encode tokens in HBH options. This addresses
> the aforementioned problems, works with any transport protocol (including
> QUIC, IPsec tunnels, arbitrary encapsulations), eliminates state and need
> for DPI in the network.
> 
> 
> 
> 
> 
> 
> 
> 
> 

+ Christian as I think he posted at the tls mailing list. Lots of interesting points.

Define "temporary" and "quickly" :) Tokens reflect a relationship between an end-user/app and a network, so you want apps/users to be able to insert these tokens to their traffic. Agreed that IPv6 can work with multiple transports and is more generic,  but you will then have to find ways to pass the token all the way from the user/app down to the IPv6 socket. TLS/QUIC is much closer to the end-user/developer, and most high-level frameworks (e.g., OkHTTP, web browsers) expose APIs to define certain properties. This is not the case with IPv4/IPv6 (e.g., I don't think it's possible to set DSCP bits from OkHTTP or Javascript).

In terms of connection state and whether you want to do it per-flow or per packet. I think there is an overall trade-off here around how big is the token, how much state it introduces at the network, and what are the processing capabilities in terms of processing and decrypting tokens.

For example, you can have a token which is a 128-bit random/opaque value that you use per-packet as a HBH option, but then the network needs to keep state for all the valid tokens, and accept some risk of a replay attack. The other alternative is to have a token that is encrypted and is therefore longer, but has enough information for the network to decrypt it and process it without requiring any state at all.

I think both are viable, and it should be up to the network operator to decide what type of tokens it uses. if you look at how OATH2 and the IAM industry deals with it is that they support both.

> 1) Network tokens really only make sense to the network that issued them,
> so their use could be restricted to that limited domain where they are
> consumed.
> 2) Packets that are leaving the limited domain that carry network tokens
> in HBH options could be filtered and the HBH option is removed
> (see proposal draft-herbert-6man-eh-attrib-01 to allow intermediate nodes
> to remove options).
> 
> 
> 
> Limiting the visibility of tokens to the local network also helps their
> security.
> 
> 
> 
> 

I am not a big fan of the assumption that tokens are relevant only to the local network, and can be issued only by it. In a zero-rating or firewall scenario, the token would be specific to the application provider (and maybe issued and signed by them), which is likely not co-located with the network. This is detailed on the application token in the I-D.

Yiannis

> 
> 
> 
> Tom
> 
> 
> 
> 
> --
> Network-tokens mailing list
> Network-tokens@ ietf. org ( [email-masked] )
> https:/ / www. ietf. org/ mailman/ listinfo/ network-tokens (
> https://www.ietf.org/mailman/listinfo/network-tokens )
> 
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Jul 2020 16:51:46 -0700

On Thu, Jul 9, 2020 at 4:28 PM Yiannis Yiakoumis <[email-masked]>
wrote:

> On Thu, Jul 09, 2020 at 3:46 PM, Tom Herbert <[email-masked]> wrote:
>
>> protocols, and for what it's worth I wrote up a mechanism for using address
>> tags and address rewrites, but unfortunately Cisco decided to patent it.
>> Anyway, thre are ways of dealing with this problem that don't require
>> binding the address to the token ("all technical problems can be solved by
>> introducing a layer of indirection").
>>
>> for the pointer. Yes, the token would have to stay on the outer envelope so
>> the network can process it. The main idea is you can encrypt everything
>> that from being the general solution: it's specific to TLS/TCP, it requires
>> intermediate nodes to parse into TCP payloads, it requires tracking
>> connection state in the network.
>>
> Define "temporary" and "quickly" :) Tokens reflect a relationship between
> an end-user/app and a network, so you want apps/users to be able to insert
> these tokens to their traffic. Agreed that IPv6 can work with multiple
> transports and is more generic,  but you will then have to find ways to
> pass the token all the way from the user/app down to the IPv6 socket.
> TLS/QUIC is much closer to the end-user/developer, and most high-level
> frameworks (e.g., OkHTTP, web browsers) expose APIs to define certain
> properties. This is not the case with IPv4/IPv6 (e.g., I don't think it's
> possible to set DSCP bits from OkHTTP or Javascript).
>

Hi Yiannis,

We don't need to find ways to pass the token, there are already sockets
APIs to do that.

The issue with network devices reading transport layer payload is that port
numbers, which are used to distinguish TLS, QUIC payloads, etc. are not
protocol numbers. They are only interpreted by the end points (RFC7605).
The network never really knows if port 80 for TCP is HTTP, or for UDP is
QUIC. It's an approximation that may be incorrect. Similarly, if the
application uses some other port numbers for their protocols then they're
out of luck unless the network knows about those. All of this was brought
up in the SPUD discussions a while back, other than adding magic numbers
into the payload, which is probabilistically correct, there really wasn't
much of an answer to the problem. There's other issues like segmentation of
the TLS header, ossification of TLS headers, etc. Honestly, I doubt that
network tokens in transport payload with the intent that intermediate
devices parse them is something that could be standardized in IETF.

A secondary issue that you might want to consider is security. A rogue
application can easily spoof tokens in TLS or QUIC packets, the OS is out
of the loop on what applications put in their payload. Setting an extension
header on a socket requires going through the OS which can apply policy to
see if the system configuration permits that, so it's going to be harder
for random applications to spoof tokens.

Tom

> In terms of connection state and whether you want to do it per-flow or per
> packet. I think there is an overall trade-off here around how big is the
> token, how much state it introduces at the network, and what are the
> processing capabilities in terms of processing and decrypting tokens.
>
> For example, you can have a token which is a 128-bit random/opaque value
> that you use per-packet as a HBH option, but then the network needs to keep
> state for all the valid tokens, and accept some risk of a replay attack.
> The other alternative is to have a token that is encrypted and is therefore
> longer, but has enough information for the network to decrypt it and
> process it without requiring any state at all.
>
> I think both are viable, and it should be up to the network operator to
> decide what type of tokens it uses. if you look at how OATH2 and the IAM
> industry deals with it is that they support both.
>
>> ubiquitously supported by routers. I think there are some ways around this:
> I am not a big fan of the assumption that tokens are relevant only to the
> local network, and can be issued only by it. In a zero-rating or firewall
> scenario, the token would be specific to the application provider (and
> maybe issued and signed by them), which is likely not co-located with the
> network. This is detailed on the application token in the I-D.
>
> Yiannis
>
> Tom
>>
>> --
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/network-tokens
>>
>
>

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Fri, 10 Jul 2020 00:33:09 +0000

On Thu, Jul 09, 2020 at 4:51 PM, Tom Herbert < [email-masked] > wrote:

> 
> On Thu, Jul 9, 2020 at 4:28 PM Yiannis Yiakoumis < yiannis@ selfienetworks.
> com ( [email-masked] ) > wrote:
> 
> 
>> On Thu, Jul 09, 2020 at 3:46 PM, Tom Herbert < tom@ herbertland. com (
>> [email-masked] ) > wrote:
>> 
>> 
>>> 
>>>> 
>>>> 

Hi Tom,

> We don't need to find ways to pass the token, there are already sockets

How can an Android/iOS/web developer interact with these socket APIs? Are there side ways to do it while using the high-level frameworks available there, or do you have to skip them and build your code directly using sockets? Both STUN and TLS support custom extensions, and we've been able to use tokens with OpenSSL/BoringSSL (but we had to build and load our own version along with the app). If we make tokens a standard extension, then other frameworks will pick it up right away and they will become available for everyone to use (the same way it happened with SNI and ALPN).

> 
> The issue with network devices reading transport layer payload is that
> port numbers, which are used to distinguish TLS, QUIC payloads, etc. are
> not protocol numbers. They are only interpreted by the end points
> (RFC7605). The network never really knows if port 80 for TCP is HTTP, or
> for UDP is QUIC. It's an approximation that may be incorrect. Similarly,
> if the application uses some other port numbers for their protocols then
> they're out of luck unless the network knows about those. All of this was
> brought up in the SPUD discussions a while back, other than adding magic
> numbers into the payload, which is probabilistically correct, there really
> wasn't much of an answer to the problem.
> 
> 

Yes, you don't have guarantees here. We have an implementation were tokens are carried over STUN messages during WebRTC calls. We assume that every UDP packet is STUN and parse it based on expected type-len fields as long as it gives us something valid. We haven't looked at the probability of error and performance penalty yet, these would be good things to understand. But given the trend towards programmable hardware/software packet parsers, I am optimistic.

> 
> There's other issues like segmentation of the TLS header, ossification of
> TLS headers, etc.
> 
> 

Would DTLS help to assume that header is within a single packet?

> 
> Honestly, I doubt that network tokens in transport payload with the intent
> that intermediate devices parse them is something that could be
> standardized in IETF.
> 
> 

Why is that? Isn't this how all firewalls/DPI/TDF etc work today ? I think it's a good point to bring up into the TSV discussion and get feedback.

> of the loop on what applications put in their payload. Setting an
> extension header on a socket requires going through the OS which can apply
> policy to see if the system configuration permits that, so it's going to
> be harder for random applications to spoof tokens.
> 
> 

The role of the OS in describing and enforcing the desired policy is an important point and requires lots of discussion. Holding off for now though...

>> that you use per-packet as a HBH option, but then the network needs to
>> keep state for all the valid tokens, and accept some risk of a replay
>> attack. The other alternative is to have a token that is encrypted and is
>> therefore longer, but has enough information for the network to decrypt it
>> and process it without requiring any state at all.
>> 
>> 
>>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 9 Jul 2020 18:38:17 -0700

On Thu, Jul 9, 2020 at 5:33 PM Yiannis Yiakoumis
<[email-masked]> wrote:
>
>
> On Thu, Jul 09, 2020 at 4:51 PM, Tom Herbert <[email-masked]> wrote:
>>
>> On Thu, Jul 9, 2020 at 4:28 PM Yiannis Yiakoumis <[email-masked]> wrote:
>>>
>>>> One quick comment is that binding tokens to IP addresses is strongly counter-recommended.
>>>> It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.
>>>>
>>>> There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, thre are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").
>>>>
>>>> There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.
>>>>
>>>> You are right that for the duration of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?
>>>>
>>>> That would certainly be better. The basic rule is that any such identifier should be used only once. Pretty much the same issue as the session resume tickets.
>>>>
>>>> Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.
>>>>
>>>> Ah, I was not aware that ESNI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.
>>>>
>>>> There are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.
>>>>
>>>> Haven't looked into QUIC yet, but is on the list of things to do. If anyone is interested to help us explore this, please let me know.
>>>>
>>>> You may want to have that discussion in the QUIC WG. If you are building some kind of QoS service, you probably want it to work with QUIC too.
>>>>
>>>> I view the use of TLS to carry tokens as a temporary hack to make something work quickly. There are several obvious problems that prevent that from being the general solution: it's specific to TLS/TCP, it requires intermediate nodes to parse into TCP payloads, it requires tracking connection state in the network.
>>>>
>>>> IMO, the real solution is to encode tokens in HBH options. This addresses the aforementioned problems, works with any transport protocol (including QUIC, IPsec tunnels, arbitrary encapsulations), eliminates state and need for DPI in the network.
>>>>
>>>>
>>>
>>>
>> We don't need to find ways to pass the token, there are already sockets APIs to do that.
>
>
>> The issue with network devices reading transport layer payload is that port numbers, which are used to distinguish TLS, QUIC payloads, etc. are not protocol numbers. They are only interpreted by the end points (RFC7605). The network never really knows if port 80 for TCP is HTTP, or for UDP is QUIC. It's an approximation that may be incorrect. Similarly, if the application uses some other port numbers for their protocols then they're out of luck unless the network knows about those. All of this was brought up in the SPUD discussions a while back, other than adding magic numbers into the payload, which is probabilistically correct, there really wasn't much of an answer to the problem.
>
>
>> There's other issues like segmentation of the TLS header, ossification of TLS headers, etc.
>
>
>> Honestly, I doubt that network tokens in transport payload with the intent that intermediate devices parse them is something that could be standardized in IETF.
>
>
> Why is that? Isn't this how all firewalls/DPI/TDF etc work today? I think it's a good point to bring up into the TSV discussion and get feedback.
>
Yiannis,

It's because host-to-network signaling in UDP payload has been tried
before in IETF, tsvwg specifically, and failed to go anywhere. Please
take a look at SPUD, draft-hildebrand-spud-prototype-03 (there was
even a BOF or two on it with some pretty animated discussion!). It's
likely SPUD will be brought up in any TSV discussions :-).

Firewalls and DPI typically operate outside of the auspices of IETF
protocol specifications. Other than spin-bit in UDP, I don't believe
there are any other cases where protocols allow intermediate devices
to look at payload. In fact, DPI is actually one leading cause of
protocol ossification so there's a lot of motivation to eliminate it
(this is why transport protocols are moving to not just encrypting
payload but also the transport headers). This is another ongoing
discussion in TSV that will likely be brought up (see
draft-ietf-tsvwg-transport-encrypt-13 and all the animated discussion
around that :-) ). To that end moving network tokens in extension
headers eliminates the need for DPI and resolves the tussle around
transport layer header encryption.

Tom

>> A secondary issue that you might want to consider is security. A rogue application can easily spoof tokens in TLS or QUIC packets, the OS is out of the loop on what applications put in their payload. Setting an extension header on a socket requires going through the OS which can apply policy to see if the system configuration permits that, so it's going to be harder for random applications to spoof tokens.
>
>
>>>> Of course the naysayers will bring up the fact that HBH options aren't ubiquitously supported by routers. I think there are some ways around this:
>>>> 1) Network tokens really only make sense to the network that issued them, so their use could be restricted to that limited domain where they are consumed.
>>>> 2) Packets that are leaving the limited domain that carry network tokens in HBH options could be filtered and the HBH option is removed
>>>> (see proposal draft-herbert-6man-eh-attrib-01 to allow intermediate nodes to remove options).
>>>>
>>>> Limiting the visibility of tokens to the local network also helps their security.
>>>
>>>

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Fri, 10 Jul 2020 01:51:07 +0000

On Thu, Jul 09, 2020 at 6:38 PM, Tom Herbert < [email-masked] > wrote:

> 
> 
> 
> On Thu, Jul 9 , 2020 at 5:33 PM Yiannis Yiakoumis
> < yiannis@ selfienetworks. com ( [email-masked] ) > wrote:
> 
> 
>> 
>> 
>> On Thu, Jul 09, 2020 at 4:51 PM, Tom Herbert < tom@ herbertland. com (
>>>>> counter-recommended. It doesn't survive NATs or proxies, mobility, and it
>>>>> is especially problematic in IPv6+IPv4 dual-stack environments.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>> How can an Android/iOS/web developer interact with these socket APIs? Are
>> there side ways to do it while using the high-level frameworks available
>> there, or do you have to skip them and build your code directly using
>> sockets? Both STUN and TLS support custom extensions, and we've been able
>> to use tokens with OpenSSL/BoringSSL (but we had to build and load our own
>> version along with the app). If we make tokens a standard extension, then
>> other frameworks will pick it up right away and they will become available
>> for everyone to use (the same way it happened with SNI and ALPN).
>> 
>> 
>> 
>>> 
>>> 
>> Yes, you don't have guarantees here. We have an implementation were tokens
>> are carried over STUN messages during WebRTC calls. We assume that every
>> UDP packet is STUN and parse it based on expected type-len fields as long
>> as it gives us something valid. We haven't looked at the probability of
>> error and performance penalty yet, these would be good things to
>> understand. But given the trend towards programmable hardware/software
>> packet parsers, I am optimistic.
>> 
>> 
>> 
>>> 
>>> 
>> Why is that? Isn't this how all firewalls/DPI/TDF etc work today ? I think
>> it's a good point to bring up into the TSV discussion and get feedback.
>> 
>> 
>> 
> 
> 
> 
> Yiannis,
> 
> 
> 
> 
> before in IETF, tsvwg specifically, and failed to go anywhere. Please take
> a look at SPUD, draft-hildebrand-spud-prototype-03 (there was even a BOF
> or two on it with some pretty animated discussion!). It's likely SPUD will
> be brought up in any TSV discussions :-).
> 
> 
> 
> 
> protocol specifications. Other than spin-bit in UDP, I don't believe there
> are any other cases where protocols allow intermediate devices to look at
> payload. In fact, DPI is actually one leading cause of protocol
> ossification so there's a lot of motivation to eliminate it
> (this is why transport protocols are moving to not just encrypting payload
> but also the transport headers). This is another ongoing discussion in TSV
> that will likely be brought up (see draft-ietf-tsvwg-transport-encrypt-13
> and all the animated discussion around that :-) ). To that end moving
> network tokens in extension headers eliminates the need for DPI and
> resolves the tussle around transport layer header encryption.
> 
> 
> 
> Tom
> 
> 
> 
> 

Got it.  Appreciate the pointers and understand reservations and concerns. I think we should take our chances for two reasons:

* network tokens attempt to do endpoint-network coordination in a way that puts privacy and security considerations first.

* having an explicit and secure way to coordinate with the network can facilitate encrypting everything else without pushback from valid business cases that are widely deployed today.

>> The role of the OS in describing and enforcing the desired policy is an
>> important point and requires lots of discussion. Holding off for now
>> though...
>> 
>> 
>> 
>>> 
>>> 
>>> Tom
>>> 
>>> 
>>> 
>>>> 
>>>>

---

From: Lars Eggert <[email-masked]>
Date: Mon, 20 Jul 2020 09:25:09 +0300

Hi,

> likely SPUD will be brought up in any TSV discussions :-).

while SPUD/PLUS was the last major attempt in this space, history in the IETF/IRTF goes back much further, e.g., at least to https://irtf.org/concluded/eme

Lars

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Mon, 20 Jul 2020 19:30:44 +0000

Thanks for sharing Lars. Is there any piece of wisdom that can act as learning from EME? The high-level overview is interesting, but all links to draft/discussion seem to be broken unfortunately.

Best,

Yiannis

=====================
Yiannis Yiakoumis
Co-Founder & CEO
https://selfienetworks.com | +1-650-644-7857

On Sun, Jul 19, 2020 at 11:25 PM, Lars Eggert < [email-masked] > wrote:

> 
> 
> 
> Hi,
> 
> 
> 
> On 2020-7-10, at 4:38, Tom Herbert < tom@ herbertland. com (
> while SPUD/PLUS was the last major attempt in this space, history in the
> IETF/IRTF goes back much further, e.g., at least to https:/ / irtf. org/ concluded/
> eme ( https://irtf.org/concluded/eme )
> 
> 
> 
> Lars
> 
> 
>