Subject: [5gangip] Network tokens draft

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

This is a draft on "Network Tokens" which is of relevance to
facilitate fine grained QoS in 5G networks.

https://tools.ietf.org/html/draft-yiakoumis-network-tokens-01

There is also a mailing list in
https://www.ietf.org/mailman/listinfo/network-tokens

We are planning to present in tsvwg and app aware networking and
possibly have a side meeting on this topic in IETF108.

Thanks,
Tom

---

From: John Grant <[email-masked]>
Date: Fri, 10 Jul 2020 13:10:03 +0100

This adds even more per-packet processing and makes headers even bigger. 
In ETSI ISG NIN https://www.etsi.org/technologies/non-ip-networking 
we're working on reducing them, as mobile operators (and no doubt 
others) want, by getting all this information into the control plane 
where it belongs.

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

On 09/07/2020 18:00, Tom Herbert wrote:
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Ca By <[email-masked]>
Date: Fri, 10 Jul 2020 06:51:16 -0700

> others) want, by getting all this information into the control plane

I would be careful saying what operators wants.

I have never heard an operator say that, and i am a mobile operator

But it is no surprise that someone attempting to replace ip is engaged in
puffery ....

CB

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 07:26:15 -0700

> others) want, by getting all this information into the control plane
John,

Network tokens provide the API between an application on a UE and the
network for the application to specify exactly the service it wants.
At the first hop in the network, the device can compress the headers,
use MPLS, put into some non-IP format, whatever it wants as long as
the user gets the service they've requested and correct protocol
behavior is maintained. If the operator wants to create a state for
every single flow in their network that's their prerogative, but good
luck scaling that to hundreds of billions of flows and getting it to
work seamlessly across mobile events-- the "connectionless" model of
IP replaced "circuit-switched" networks for good reason!

Tom

---

From: Ca By <[email-masked]>
Date: Fri, 10 Jul 2020 07:38:05 -0700

> network for the application to specify exactly the service it wants.

A fundamental principle of mobile qos is that you do not trust the UE, as
it can be compromised to make all traffic high priority. Only the network
can reliably and securely allocate resources based on policy.

> IP replaced "circuit-switched" networks for good reason!

In mobile, the the bearer is a bit of a virtual circuit.  Each UE has one
or more bearers which are assigned an e2e qos policy.  Your cases for
tokens would be stronger if you could show how tokens overcome a defined
challenge that is not solved today.  It is important for credibility to
demonstrate knowledge of the existing approach ... otherwise the suggestion
appears out of context

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 10 Jul 2020 09:39:50 -0500

Tom,

It has already been announced that this list is no longer dealing with 5G
issues.
We decided to move to 6g, please check recent mails.

As such your topic is no longer of interest and we invite you to join us
into the new and exciting area of 6G.

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 07:41:14 -0700

On Fri, Jul 10, 2020 at 7:38 AM Ca By <[email-masked]> wrote:
> A fundamental principle of mobile qos is that you do not trust the UE, as it can be compromised to make all traffic high priority. Only the network can reliably and securely allocate resources based on policy.

Right, that's why network tokens are handed out by the network and
authenticated when they're used. The only thing a UE sees an opaque
stream of bytes. We need protection against spoofing, replay, etc.

> In mobile, the the bearer is a bit of a virtual circuit.  Each UE has one or more bearers which are assigned an e2e qos policy.  Your cases for tokens would be stronger if you could show how tokens overcome a defined challenge that is not solved today.  It is important for credibility to demonstrate knowledge of the existing approach ... otherwise the suggestion appears out of context
>
>>
>> Tom
>>
>> > --
>> > John Grant

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 07:44:37 -0700

On Fri, Jul 10, 2020 at 7:40 AM Behcet Sarikaya <[email-masked]> wrote:
>
> Tom,
>
> It has already been announced that this list is no longer dealing with 5G issues.
> As such your topic is no longer of interest and we invite you to join us into the new and exciting area of 6G.
>

Very well, if people are interested in further discussion please post
on the Network-tokens list.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jul 2020 17:19:19 +0200

Le 10/07/2020 à 16:44, Tom Herbert a écrit :
>> It has already been announced that this list is no longer dealing
>> with 5G issues. We decided to move to 6g, please check recent
>> mails.
>> 
>> As such your topic is no longer of interest and we invite you to
>> join us into the new and exciting area of 6G.
>> 
> 
> Very well, if people are interested in further discussion please
> post on the Network-tokens list.

Or we can think that any new proposed technology could fall under the
ummbrella of 6G rather than that of 5G.  Because 5G is no longer under
development, I think.

By the way, if I wanted to implement a network token concept I would
consider the use of existing Flow Labels field in the IPv6 header.  A
flow label would contain a mapped value of a token.

If I wanted a Network Token to be for an endpoint on a 6G link, then I
would look at what is the 6G link access method of the PHY of the UE.
MAybe that link access method (an *-MA method, a Multiple Access method,
like in CDMA, OFDMA, SCDMA, etc.) could use a Network Token.

And then, maybe putting IP on that 6G link would need a mapping between
a Flow Label and a network token in the *-MA method.

Alex

>>>> This adds even more per-packet processing and makes headers
>>>> even bigger. In ETSI ISG NIN
>>>> https://www.etsi.org/technologies/non-ip-networking we're
>>>> working on reducing them, as mobile operators (and no doubt 
>>>> others) want, by getting all this information into the control
>>>> plane where it belongs.
>>>> 
>>> John,
>>> 
>>> Network tokens provide the API between an application on a UE and
>>> the network for the application to specify exactly the service it
>>> wants. At the first hop in the network, the device can compress
>>> the headers, use MPLS, put into some non-IP format, whatever it
>>> wants as long as the user gets the service they've requested and
>>> correct protocol behavior is maintained. If the operator wants to
>>> create a state for every single flow in their network that's
>>> their prerogative, but good luck scaling that to hundreds of
>>> billions of flows and getting it to work seamlessly across mobile
>>> events-- the "connectionless" model of IP replaced
>>> "circuit-switched" networks for good reason!
>>> 
>>> Tom
>>> 
>>>> -- John Grant Nine Tiles, Cambridge, England +44 1223 862599
>>>> and +44 1223 511455 http://www.ninetiles.com
>>>> 
>>>> 
>>>>> We are planning to present in tsvwg and app aware networking
>>>>> and possibly have a side meeting on this topic in IETF108.
>>>>> 
>>>>> Thanks, Tom
>>>>> 
>>>>> _______________________________________________ 5gangip
>>>>> mailing list [email-masked] 
>>>> _______________________________________________ 5gangip mailing
>>>> list [email-masked] 
>>> _______________________________________________ 5gangip mailing
>>> list [email-masked] 
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 08:25:19 -0700

> a Flow Label and a network token in the *-MA method.

Alex,

It's an interesting question. Maybe post the question to
Network-tokens and cross post to 6G list, I don't think anyone would
complain.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 10 Jul 2020 17:54:45 +0200

> Network-tokens and cross post to 6G list, I don't think anyone would

Thank you for the suggestion.

I think that is a problem.

There is no 6G email list.  This one is called 5gangip.

I think all the mailing lists at IETF might constitute candidate 
technologies for the 6G networks.

I might have comments for each one of those technologies, but should I 
go to each email list at IETF and post?

The large number of email lists at IETF is represented by the small size 
of the scrolling bar at the right when browsing this page:
https://www.ietf.org/mailman/listinfo/?__cf_chl_jschl_tk__=84443e7849ee0b9f1e50ba8a67f06c677196bd85-1594396207-0-AdsPt1Ml6oDEkm7YZNq113HKnW5CWYJrW8a15ICBRAzpJQyOTGfmETkTsqicfWwWhi8g8iC4WyLCRkFcvKtjvGxD2lku9mEbvGUYmLDT0GDrRI6WIa6Q1XV6Lg8tz6RdvkeeKf0jjXLWwRvBf9KNEIBMnew4vOrpKD_cHFIt1xBPKWD7XyDxs5a_T993kGXna-oMsQLTIOFFxVy3sZ7AEfxa6sDvMoWUy1EA59P07mIIRhXiFAhkO2EslUqbUKPCK-iTh-Tc2ulN6rnQWW6fXjmbCll8vOceMkPBobxF1oMh

That URL is large itself because it contains a token.  That security 
token is because cloudflare checked by browser before it shown me the 
page, an IETF webserver practice that I dont like and that I find pure 
intrusion and delay inducing.

The problem is the following: I tried to access a simple URL that I know 
by heart (https://ietf.org/mailman/listinfo) but the webserver preferred 
to secure it back to me, introduce delay, and enlarge the URL.

I might be simply overwhelmed :-)

Alex

---

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

subscribed late and can't reply inline to follow-up comments. Short response to Ca By's point on whether the network trusts the UE.

"A fundamental principle of mobile qos is that you do not trust the UE, as
it can be compromised to make all traffic high priority. Only the network
can reliably and securely allocate resources based on policy."
The basic architecture for network tokens is agnostic on the trust relationships between UE, app provider, network and server. It provides mechanisms to encrypt/sign a token, and metadata to prevent replay and spoofing attacks so that operators can adjust it to the appropriate trust model. It borrows a lot from the ideas implemented in JWT, CWT and OAUTH2.

Yiannis

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

On Thu, Jul 09, 2020 at 10:00 AM, Tom Herbert < [email-masked] > wrote:

> 
> 
> 
> This is a draft on "Network Tokens" which is of relevance to facilitate
> fine grained QoS in 5G networks.
> 
> 
> 
> https:/ / tools. ietf. org/ html/ draft-yiakoumis-network-tokens-01 (
> https://tools.ietf.org/html/draft-yiakoumis-network-tokens-01 )
> 
> 
> 
> https:/ / www. ietf. org/ mailman/ listinfo/ network-tokens (
> https://www.ietf.org/mailman/listinfo/network-tokens )
> 
> 
> 
> We are planning to present in tsvwg and app aware networking and possibly
> have a side meeting on this topic in IETF108.
> 
> 
> 
> Thanks,
> Tom
> 
> 
>

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Fri, 10 Jul 2020 17:02:40 +0000

"In mobile, the the bearer is a bit of a virtual circuit.  Each UE has one
or more bearers which are assigned an e2e qos policy.  Your cases for
tokens would be stronger if you could show how tokens overcome a defined
challenge that is not solved today.  It is important for credibility to
demonstrate knowledge of the existing approach … otherwise the suggestion
appears out of context"
We are actually building a prototype that combines tokens with a dedicated bearer for an LTE network, and provides E2E QoS both at uplink and downlink. Implementation happens at https://github.com/network-tokens/. Happy to share more details if you are interested.

Y.

=====================
Yiannis Yiakoumis
Co-Founder & CEO

On Fri, Jul 10, 2020 at 9:35 AM, Yiannis Yiakoumis < [email-masked] > wrote:

> 
> subscribed late and can't reply inline to follow-up comments. Short
> response to Ca By's point on whether the network trusts the UE.
> 
> 
> 
> The basic architecture for network tokens is agnostic on the trust
> relationships between UE, app provider, network and server. It provides
> mechanisms to encrypt/sign a token, and metadata to prevent replay and
> spoofing attacks so that operators can adjust it to the appropriate trust
> model. It borrows a lot from the ideas implemented in JWT, CWT and OAUTH2.
> 
> 
> 
> 
> Yiannis
> 
> 
> 
> 
> 
> =====================
> Yiannis Yiakoumis
> Co-Founder & CEO
> https:/ / selfienetworks. com ( https://selfienetworks.com ) |
> +1-650-644-7857
> 
> 
> 
> On Thu, Jul 09, 2020 at 10:00 AM, Tom Herbert < tom@ herbertland. com (
> [email-masked] ) > wrote:
> 
>> 
>>

---

From: Ca By <[email-masked]>
Date: Fri, 10 Jul 2020 10:15:44 -0700

On Fri, Jul 10, 2020 at 10:03 AM Yiannis Yiakoumis <
[email-masked]> wrote:

> We are actually building a prototype that combines tokens with a dedicated
> bearer for an LTE network, and provides E2E QoS both at uplink and
> downlink. Implementation happens at https://github.com/network-tokens/ .
> Happy to share more details if you are interested.
>
>
> Y.
>

But why is this better than the existing bearer / pcrf model?

What problem are you solving that is novel or better than the existing
approach?

Just saying your model is a great is not helpful.

> On Fri, Jul 10, 2020 at 9:35 AM, Yiannis Yiakoumis <
> [email-masked]> wrote:
>
>> On Thu, Jul 09, 2020 at 10:00 AM, Tom Herbert <[email-masked]>
>> wrote:
>>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 10 Jul 2020 10:22:21 -0700

On Fri, Jul 10, 2020 at 10:16 AM Ca By <[email-masked]> wrote:

>> We are actually building a prototype that combines tokens with a
>> dedicated bearer for an LTE network, and provides E2E QoS both at uplink
>> and downlink. Implementation happens at
>> https://github..com/network-tokens/ <https://github.com/network-tokens/> .

One advantage is that it moves the solution into the IP layer so it can be
used with a broader range of technologies. For instance, when a phone
connects to a Wifi router the application uses the same interface to get
tokens from that provider.

Tom

>>> https://selfienetworks..com <https://selfienetworks.com> |
>>> +1-650-644-7857
>>>
>>>

---

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

The problem that we are solving is that QoS/bearers, zero-rating etc require complex application signatures to map and classify traffic to the desired service (TFT and packet filters in 3GPP-speak). These are very expensive and manual to maintain, they are inaccurate, vulnerable to fraud, bad for privacy, and don't work with upcoming protocols like ESNI. We had 85% failure rate on integrations based on application signatures because of the reasons mentioned above.

The approach we take with network tokens is that traffic differentiation services should be complemented with access management practices, not traffic classification. And network tokens are merely a mechanism to facilitate access management here.

Y.

=====================
Yiannis Yiakoumis
Co-Founder & CEO

On Fri, Jul 10, 2020 at 10:15 AM, Ca By < [email-masked] > wrote:

> 
> On Fri, Jul 10, 2020 at 10:03 AM Yiannis Yiakoumis < yiannis@ selfienetworks.
> com ( [email-masked] ) > wrote:
> 
> 
>> downlink. Implementation happens at https:/ / github. com/ network-tokens/
>> ( https://github.com/network-tokens/ ). Happy to share more details if you
>> are interested.
>> 
>> 
>> 
>> 
>> Y.
>> 
>> 
> 
> 
> 
>> On Fri, Jul 10, 2020 at 9:35 AM, Yiannis Yiakoumis < yiannis@ selfienetworks.
>> com ( [email-masked] ) > wrote:
>> 
>> 5gangip@ ietf. org ( [email-masked] )
>> https:/ / www. ietf. org/ mailman/ listinfo/ 5gangip (
>> https://www.ietf.org/mailman/listinfo/5gangip )
> 
> 
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 10 Jul 2020 16:06:24 -0500

Alex, the list name is hopefully going to change to 6g soon.

Behcet