Subject: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 29 Jan 2018 14:39:55 -0600

Hi all,
Dirk and I submitted this PS draft.
We need this to be discussed and improved. Please read and comment.
Also we are soliciting co-authors, please let us know.

Regards,
Dirk & Behcet

A new version of I-D, draft-hspab-5gangip-atticps-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-hspab-5gangip-atticps
Revision:       00
Title:          IP Issues and Associated Gaps in Fifth Generation Wireless
Networks
Document date:  2018-01-28
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-hspab-5gangip-
atticps-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hspab-5gangip-
atticps/
Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-
atticps-00

Abstract:
   This document attempts to make the case for new work that need to be
   developed to be used among various virtualized functions and the end
   user which may be moving.  First a set of use cases on tunneling,
   charging, mobility anchors are developed and then the steps of
   proposed new work is described next.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Mon, 29 Jan 2018 14:16:54 -0800

> We need this to be discussed and improved. Please read and comment.

Hi Behcet,

Thanks for posting the draft. A few comments...

"However it can be argued that it is difficult to derive globally
unique identifiers only using 64 bits.  So it is better to use longer
identifiers, e.g. 80 bits or longer"

Can you elaborate on this?

I think the Privacy issues should be it's own section.
Identifier/locator has both pitfalls and give opportunities to improve
privacy.

"The use of identifiers unique for each user brings privacy issues. If
the identifier is stolen then your traffic can be unlawfully tracked,
there could be serious implications of it."

This is true today when devices have address or assigned a single /64.
One alternative is gives users thousands or millions of addresses
(identifier). Identifier/locator split should facilitate that. Note
that this effect is already provided by NAT since every connection
through a NAT is translated to non-trackable address/port. NAT has
some law enforcement agencies freaking out because of its strong
(inadvertent) privacy!

"Privacy of identifiers is especially an issue for a UE communication
with a server like Google, Facebook, LinkedIn, etc."

You might want to mention that simple identifier rotation [RFC4914] is
not enough these days..

"Privacy issue can be mitigated only if Id-Loc system has proxy mode
of operation.  In proxy mode, user traffic is intercepted by a proxy.
Proxy node which could be placed at the subnet router or site border
router.  The router tunnels the traffic to the server.  In the process
UE identifier becomes hidden and this hopefully removes privacy
issues."

I'm not sure what this means. Multiple identifiers per deivce should
address the privacy issue, Maybe a proxy would have the same effect?

"5G specific identifiers can also used to deal with privacy issues.
IMSI is known to be 64 bit and unique for each UE.  IMSI should not be
exposed to any entities.  It is like 64-identifier.  Instead
identifiers like 5G-GUTI can be used"

I think this is two levels. An identifier in IP identifies a node for
the purpose of being the endpoint of the communication. Something like
IMSI identifies a specific device (and hence user). In the best case
scenario, IP identifiers don't reveal the identity of users and they
can be made externally visible. IMSI is by its nature sensitive
information and only visible in a trusted domain. A mapping system
will need to map identifiers to identities (like an IMSI) so the
system needs to be secured.

A big item missing in this section is locator security. Fine grained
locators used in cellular system could be used to infer the
geo-location of devices and hence users, thus enabling stalkers
everywhere.  So locators need restricted visibility somehow..

Tom

> URL:
> https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00
>
>
> Abstract:
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Jan 2018 11:53:28 +0100

In this draft, during the discussion about GTP, how about including this 
table originated by d.lake at Surrey:

       Generation of Mobile Network vs Protocol

4G    5G Equivalent    Protocol
---------------------------------------
S1        N3            GTP
S5/S8     N9            Not yet defined
SGi       N6            IP
S11       N4            PFCP

Alex

Le 29/01/2018 à 21:39, Behcet Sarikaya a écrit :
> Title:          IP Issues and Associated Gaps in Fifth Generation 
> Wireless Networks
> <https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt>
> Status: https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/ 
> <https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/>
> <https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00>
> Htmlized: 
> <https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00>
> 
> 
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org 
> <http://tools.ietf.org>.
> 
> The IETF Secretariat
> 
> 
> 
>

---

From: <[email-masked]>
Date: Tue, 30 Jan 2018 12:53:17 +0000

I think there is an error in this table from my further research.

The final row should read:

Sxa/Sxb  N4   PFCP

Reading 29.244 (thank you Lionel) it seems that N4 does not currently define anything in addition to current CUPS Sxa/b (but over PFCP rather than Diameter) but N4 COULD be expanded for other uses.

David

Sent from my iPhone
_____________________________
From: Alexandre Petrescu <[email-masked]>
Sent: Tuesday, January 30, 2018 10:58 am
Subject: Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt
To: <[email-masked]>

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 30 Jan 2018 09:44:47 -0600

Hi Tom,

Thanks Tom for your detailed review.
We need more of these.

Folks please read and comment!

> Can you elaborate on this?

I think it also say cryptographically generated ids. Otherwise
administratively assigned ids could be unique and shorter, e.g.
IEEE 48 bit and 64 MAC addresses, 3GPP assigned IMSI, etc.
Thanks for pointing this.

> (identifier). Identifier/locator split should facilitate that.

Please suggest some text.

> Note
> This reminds me some people say ILA is a NAT.

> Sure.

> Again please provide some text.

> can be made externally visible.

How?

> IMSI is by its nature sensitive
When do you need to access the mapping system is the issue I think.
We did not want to get into this a lot in the draft it is more control
plane.

> everywhere.  So locators need restricted visibility somehow..
Good point. But how? Again, some text please.

Behcet

> Wireless

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Tue, 30 Jan 2018 20:46:34 +0000

At least in the context of 3GPP 5G the PCF/PCRF knows the user identity (IMSI & MSISDN) and can know the mobile location (ULI) when starting any new service that may need unique routing (not default routing to TAI selected UPF). When PCF/PCRF creates flow rules it can do so by adapting IP header information particularly when using IPv6 UE addressing. We can also use dynamic DNS FQDN matches to create PCC rules. Leveraging CDN’s and anycast for key services can greatly improve resilience and closest service endpoint.

Since we know fiber topology and back haul locations; plus we know the locations of all on-net UPF’s/SAE-GW’s; there can be only a small number of alternate routes to best service location when the default location is not the best.

At least for 3GPP operators I am familiar with; they all have some regionalized topology that aligns with L1/L2 topology. Labels can be used to select next P/PE when using MPLS VPN for backbone which is common in North America and other parts of the world. Plus default routes are often managed using a dynamic routing protocol like BGP. These operators are all moving towards UPF/SAE-GW located in top markets. When small it was common to have at least two locations for disaster handling. The number of locations grew as these operators grew and as more capacity was needed.

Thus it always amounts to a spoke and hub topology and it’s always best to locate at least in each major hub location. The top 4 mobile operators in US have been 8-50 hub locations and 16-60 mobile core locations. So for bigger markets that aren’t already a hub it makes sense to locate a mobile core in a market aligned with fiber topology and content locations (e.g. host locations).

This network architecture must align with peering locations and with on-net paths to content. It also should align with IPX interconnect locations but only very big players optimize path to roaming PLMN thru multiple advertised routing locations. The IPX provided may optimized but for the most part the visited network has no visibility into the home network.

In any solution, we desire the default path to be the optimal path the majority of the time. We also want to select the optimal UPF for any given network/APN. Looking at the top 100 sites for mobile Internet traffic, AT&T only needs one or two alternate routes to/from UPF to cover 90% of the home mobile traffic. If AT&T executes to plan thru 2023 then default may cover 78% of traffic. This holds true even as more traffic switches from HTTP|HTTPS to QUIC.

Food for thought but I doubt we need the ability to define many unique service paths. UE’s leveraging the same cp

Sent from my iPhone

On Jan 30, 2018, at 7:46 AM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom,

On Mon, Jan 29, 2018 at 4:16 PM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Jan 29, 2018 at 12:39 PM, Behcet Sarikaya

Hi Behcet,

I think it also say cryptographically generated ids. Otherwise administratively assigned ids could be unique and shorter, e.g.
IEEE 48 bit and 64 MAC addresses, 3GPP assigned IMSI, etc.
Thanks for pointing this.

Note

Sure.

How?

When do you need to access the mapping system is the issue I think.
We did not want to get into this a lot in the draft it is more control plane.

Behcet

Tom

> https://www.ietf.org/internet-drafts/draft-hspab-5gangip-atticps-00.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dhspab-2D5gangip-2Datticps-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=7dyEB2UFH7E1g1h6pcV8s3QyJs1bENkBx8yjCVlRrEA&e=>
> Status:
> https://datatracker.ietf.org/doc/draft-hspab-5gangip-atticps/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhspab-2D5gangip-2Datticps_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=MH8iYJXADVHjnJbj01V7pAdz2ilNoW_ycyduJYrgTEQ&e=>
> Htmlized:       https://tools.ietf.org/html/draft-hspab-5gangip-atticps-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dhspab-2D5gangip-2Datticps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=vIZMCC0M5mLj9LDfZaEWn02ZE0IPlISdgkAtsuZP1Kw&e=>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hspab-5gangip-atticps-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dhspab-2D5gangip-2Datticps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=EloR12uUIk3R7PPOE_64kRzs1ThFDB9wKRuhPU6fP2w&e=>
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=1hqo0Z8nUbNsD-WYGkTPTRQjOxvWbUDn160TLBZVJgs&e=>.
>
> The IETF Secretariat
>
>
>
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=lTpbqlECzLv3MxdsjJnvl_vKg51Ho8w8Zi1zW4LMf1s&e=>
>

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=lTpbqlECzLv3MxdsjJnvl_vKg51Ho8w8Zi1zW4LMf1s&e=

---

From: AshwoodsmithPeter <[email-masked]>
Date: Tue, 30 Jan 2018 21:06:08 +0000

Terry,

How has your experience been with entropy and ECMP/LAG ? Are you generally getting enough diversity from ECMP and/or LAG ?

Peter

From: 5gangip [mailto:[email-masked]] On Behalf Of FIGURELLE, TERRY F
Sent: Tuesday, January 30, 2018 3:47 PM
To: [email-masked]
Cc: Tom Herbert <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

At least in the context of 3GPP 5G the PCF/PCRF knows the user identity (IMSI & MSISDN) and can know the mobile location (ULI) when starting any new service that may need unique routing (not default routing to TAI selected UPF). When PCF/PCRF creates flow rules it can do so by adapting IP header information particularly when using IPv6 UE addressing. We can also use dynamic DNS FQDN matches to create PCC rules. Leveraging CDN's and anycast for key services can greatly improve resilience and closest service endpoint.

Since we know fiber topology and back haul locations; plus we know the locations of all on-net UPF's/SAE-GW's; there can be only a small number of alternate routes to best service location when the default location is not the best.

Thus it always amounts to a spoke and hub topology and it's always best to locate at least in each major hub location. The top 4 mobile operators in US have been 8-50 hub locations and 16-60 mobile core locations. So for bigger markets that aren't already a hub it makes sense to locate a mobile core in a market aligned with fiber topology and content locations (e.g. host locations).

Food for thought but I doubt we need the ability to define many unique service paths. UE's leveraging the same cp
Sent from my iPhone

Hi Behcet,

Note

How?

Behcet

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 30 Jan 2018 15:28:05 -0600

On Tue, Jan 30, 2018 at 2:46 PM, FIGURELLE, TERRY F <[email-masked]> wrote:

> At least in the context of 3GPP 5G the PCF/PCRF knows the user identity
> (IMSI & MSISDN) and can know the mobile location (ULI) when starting any
> new service that may need unique routing (not default routing to TAI
> selected UPF). When PCF/PCRF creates flow rules it can do so by adapting IP
> header information particularly when using IPv6 UE addressing. We can also
> use dynamic DNS FQDN matches to create PCC rules. Leveraging CDN’s and
> anycast for key services can greatly improve resilience and closest service
> endpoint.
>
> Since we know fiber topology and back haul locations; plus we know the
> locations of all on-net UPF’s/SAE-GW’s; there can be only a small number of
> alternate routes to best service location when the default location is not
> the best.
>
> At least for 3GPP operators I am familiar with; they all have some
> regionalized topology that aligns with L1/L2 topology. Labels can be used
> to select next P/PE when using MPLS VPN for backbone which is common in
> North America and other parts of the world. Plus default routes are often
> managed using a dynamic routing protocol like BGP. These operators are all
> moving towards UPF/SAE-GW located in top markets. When small it was common
> to have at least two locations for disaster handling. The number of
> locations grew as these operators grew and as more capacity was needed.
>
> Thus it always amounts to a spoke and hub topology and it’s always best to
> locate at least in each major hub location. The top 4 mobile operators in
> US have been 8-50 hub locations and 16-60 mobile core locations. So for
> bigger markets that aren’t already a hub it makes sense to locate a mobile
> core in a market aligned with fiber topology and content locations (e.g.
> host locations).
>
> This network architecture must align with peering locations and with
> on-net paths to content. It also should align with IPX interconnect
> locations but only very big players optimize path to roaming PLMN thru
> multiple advertised routing locations. The IPX provided may optimized but
> for the most part the visited network has no visibility into the home
> network.
>
>

> In any solution, we desire the default path to be the optimal path the
> majority of the time. We also want to select the optimal UPF for any given
> network/APN. Looking at the top 100 sites for mobile Internet traffic, AT&T
> only needs one or two alternate routes to/from UPF to cover 90% of the home
> mobile traffic. If AT&T executes to plan thru 2023 then default may cover
> 78% of traffic. This holds true even as more traffic switches from
> HTTP|HTTPS to QUIC.
>
>
As I understand from the above paragraph, if 5G used an identifier locator
system and not GTP-U type of tunneling, the UE packet would reach the
optimal UPF or the next UPF probably a bit less optimal?

Behcet

> Food for thought but I doubt we need the ability to define many unique
> service paths. UE’s leveraging the same cp
>
> Sent from my iPhone
>
> On Jan 30, 2018, at 7:46 AM, Behcet Sarikaya <[email-masked]>
> wrote:
>
> Hi Tom,
>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dhspab-2D5gangip-2Datticps-2D00.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=7dyEB2UFH7E1g1h6pcV8s3QyJs1bENkBx8yjCVlRrEA&e=>
>> > Status:
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhspab-2D5gangip-2Datticps_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=MH8iYJXADVHjnJbj01V7pAdz2ilNoW_ycyduJYrgTEQ&e=>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dhspab-2D5gangip-2Datticps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=vIZMCC0M5mLj9LDfZaEWn02ZE0IPlISdgkAtsuZP1Kw&e=>
>> > Htmlized:
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dhspab-2D5gangip-2Datticps-2D00&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=EloR12uUIk3R7PPOE_64kRzs1ThFDB9wKRuhPU6fP2w&e=>
>> >
>> >
>> > Abstract:
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=1hqo0Z8nUbNsD-WYGkTPTRQjOxvWbUDn160TLBZVJgs&e=>
>> .
>> >
>> > The IETF Secretariat
>> >
>> >
>> >
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=lTpbqlECzLv3MxdsjJnvl_vKg51Ho8w8Zi1zW4LMf1s&e=>
>> >
>>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_
> sNxa2NTxwl2paJIf4zw&m=TFlH-VCA0u4QrB76_ya25aWiCnF5UW5SmVZWAoAUKoo&s=
> lTpbqlECzLv3MxdsjJnvl_vKg51Ho8w8Zi1zW4LMf1s&e=
>
>

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Wed, 31 Jan 2018 01:28:05 +0000

Just had procedure in hospital. So a bit loopy and I tend to jump around and be long winded on my best days. So forgive my brain dump ;)

We use both widely and in many ways. More than even I know ;)

We widely use LAG and had a bit of learning experience on hashing plus port combinations which we had to accommodate into our overall design.

We get great distribution with two links, really good with four (great for 3 links and good for fourth plus improving). Depending on the vendor and line card the distribution on some of the links can be unbalance unless you work closely with that vendor. We have both box and box-cross (box-X, bow-box, pick your term). Within facility. All facilities are dual entry and we try to be unique path (not any same vault).

Depending on the link we detect or detect&correct in 1-5 seconds. We have a ton of live metrics and some amazing engineering on the MPLS backbone but I can’t share that information. Convergence is optimize and we get some really good numbers but I can’t share that either.

We have some pretty slick smartphone Apps which support controlled need to know information. Plus we enable our employees to be field testers and to report issues for all of our services.

We tend to overkill on design so things can run at capacity with any complete line card failure, supervisor failure, compute failure, etc. Site failures are split to at least two other sites by tracking area at same topology label length. Plus three major region IXC locations can handle both any in region site failure and any IXC site failure.

We also have an adaptive APN DNS that has configured topology and near-real-time GSN latency, utilization and health information. We are extending this to become our VSSF in 5G mobile core. For the MPLS VPN routing we have configured three region failover (east, central, west) which aligns with our three IXC zones that connect to IPX (Syniverse). We also use this for regional failover on APN’s with that feature where we have two or more connections to corporate data centers (Intranet). We have three sub regions per major region for SGW:PGW selection.

We exchange info with IPX who matches our regional routing failover design. This is critical for our Auto VoLTE (Connect Car) solution with other North American countries.

We set contestants like total latency budget for VoLTE but it turns out top bandwidth requires even tighter latency budget.

I feel that we need < 5ms cell site to Internet interface on UPF/SAE-GW. AT&T backbone carries ~60% of US Internet traffic. Rest is via tier1 ISP connections or direct data center connections (MIS, GMIS, AVPN). We have on-site equipment in all the big players US data centers (Apple, Amazon, Facebook, Google, IBM, video content {Netflix, HBO, STARZ,...}, Microsoft,...).

Sent from my iPhone

On Jan 30, 2018, at 1:06 PM, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:

Terry,

Peter

From: 5gangip [mailto:[email-masked]] On Behalf Of FIGURELLE, TERRY F
Sent: Tuesday, January 30, 2018 3:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>; 5GANGIP <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

Hi Behcet,

Note

How?

Behcet

Tom

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Wed, 31 Jan 2018 02:00:34 +0000

You really have two things to solve for. Cell site to UPF/SAE-GW and UPF to service.

Since eliminate GTP allows for using two different cell site to UPF paths and the fact that best UPF to service path may differ by UPF the optimal solution may be same UPF for two services or different UPF for two services. Obviously we hope for same and that is the default but reality is for one or more sets of services they do not have lowest total path latency using default UPF.

That is one problem that is possible to address without GTP.

Sent from my iPhone

On Jan 30, 2018, at 1:28 PM, Behcet Sarikaya <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Jan 30, 2018 at 2:46 PM, FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>> wrote:
At least in the context of 3GPP 5G the PCF/PCRF knows the user identity (IMSI & MSISDN) and can know the mobile location (ULI) when starting any new service that may need unique routing (not default routing to TAI selected UPF). When PCF/PCRF creates flow rules it can do so by adapting IP header information particularly when using IPv6 UE addressing. We can also use dynamic DNS FQDN matches to create PCC rules. Leveraging CDN’s and anycast for key services can greatly improve resilience and closest service endpoint.

As I understand from the above paragraph, if 5G used an identifier locator system and not GTP-U type of tunneling, the UE packet would reach the optimal UPF or the next UPF probably a bit less optimal?

Behcet

Sent from my iPhone

Hi Tom,

Hi Behcet,

Note

Sure.

How?

Behcet

Tom

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 31 Jan 2018 14:40:23 +0000

Keep in mind the UPF’s must be spread to multiple servers to get the benefit of parallelizing the load. So one UPF is really a set of parallel UPF’s each with different addresses.

Peter

From: 5gangip [mailto:[email-masked]] On Behalf Of FIGURELLE, TERRY F
Sent: Tuesday, January 30, 2018 9:01 PM
To: [email-masked]
Cc: Tom Herbert <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

Behcet

Hi Behcet,

Note

How?

Behcet

Tom

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Wed, 31 Jan 2018 16:03:26 +0000

Not always.

Some solutions use a single VIP then relay internally using layer2. Other start with a VIP then assign unique IIP tunnel endpoints in the response load distributing or load balancing.

This is similar to vendors EPC product line. AT&T’s vEPC leverages an SDN controller and a GTP load balancer that integrates with APN DNS. This will evolve to support slicing (VSSF).

Traditional load balancers and firewalls can have issues when there are many GTP tunnels between the same IP endpoints. It doesn’t hash well. If they include the TEID in the hash algorithm this is resolved. We had to push to get that feature.

Sent from my iPhone

On Jan 31, 2018, at 6:40 AM, AshwoodsmithPeter <[email-masked]<mailto:[email-masked]>> wrote:

Peter

Behcet

Hi Behcet,

Note

How?

Behcet

Tom

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 31 Jan 2018 21:17:14 +0000

From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: 30 January 2018 16:28
To: FIGURELLE, TERRY F <[email-masked]>
Cc: Tom Herbert <[email-masked]>; 5GANGIP <[email-masked]>
Subject: Re: [5gangip] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

In any solution, we desire the default path to be the optimal path the majority of the time. We also want to select the optimal UPF for any given network/APN. Looking at the top 100 sites for mobile Internet traffic, AT&T only needs one or two alternate routes to/from UPF to cover 90% of the home mobile traffic. If AT&T executes to plan thru 2023 then default may cover 78% of traffic. This holds true even as more traffic switches from HTTP|HTTPS to QUIC.
[Arashmid]
The choice of ID-LOC data path on its own cannot guarantee UE packets reaching their optimal UPF.
IMO the way we map IDs to LOCs, ID-LOC mapping record constructs and the way we distribute this info. is what allows packets from different UEs to reach their respective optimal UPF.

Behcet

Hi Behcet,

Note

How?

Behcet

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 14:02:54 -0800

> Please suggest some text.

Here is my postulated privacy exploit that defeats periodic address
rotation [RFC4951]  and would be solved by single use addresses (a
different address per connection).

   -

   The attacker creates an “always connected” app that provides some
   seemingly benign service and users download the app.
   -

   The app includes some sort of persistent identity. For instance, this
   could be a login to account.
   -

   The backend server for the app logs the user identity and IP address
   they are using each time they connect.
   -

   When an address change happens, existing connections on the user device
   are disconnected. The app will receive a notification and immediately
   attempt to reconnect using the new source address.
   -

   The backend server will see the new connection and log the new IP
   address as being used by the user.
   -

   Thus, the server has a real-time record of users and the IP address they
   are using.
   -

   The attacker gains access to packet traces taken at some point in the
   Internet. The addresses in the captured packets can be time correlated with
   the server database to deduce the identity of the source of packets for
   flows communications unrelated to the app.

>> This reminds me some people say ILA is a NAT.
Mark Smith provided the best explanation as to why ILA is not NAT:

"The process ILA performs is a perfect transform, once at ingress to the
ILA domain, into the ILA domain's address space, and a perfect
transformation back at ILA egress. If the transformation isn't perfect,
then a fault has occurred.

The other reason I'd avoid "translate" is that it in the IETF it carries
with it the association with IPv4 NAT and its drawbacks. ILA doesn't suffer
from these issues because of the full reversal of the address changes upon
egress from the ILA domain.

(So how come I don't like NAT at all, yet am ok with what ILA is doing? The
full reversal of the address charges at ILA egress is the first reason.
Secondly, within the ILA domain, the ingress ILA device is a host, that is
in effect originating the packet within the ILA domain it is sending to the
egress ILA device, which is also a host or end-point within the ILA domain.

The ILA domain is effectively a virtual link layer or an underlay network
for the traffic being carried between hosts outside of the ILA domain. As
long as the ILA domain is perfectly transparent to the overlay network and
its hosts, then what ever happens within the ILA domain doesn't matter,
similar to how link layer compression, as long as fully and perfectly
reversed, also doesn't matter.)"

>> Again please provide some text.
As I said, I don't know what this proxy mode of operation is in an idloc
system.

>> can be made externally visible.

The mapping of an identifier to a user of device is only known by the local
network. Outside of the local trusted network a third party should not be
able to infer identity of geo-location of a user solely based on IP
addresses. For that, something like IMSI can't be used to make addresses
without some sort of mapping or obfuscation.

> We did not want to get into this a lot in the draft it is more control
IMO, it's going to be hard not to include the control plane in discussions.
That's where most of the major issues of idloc are, particularly in scaling
and securing the mapping database.

> Good point. But how? Again, some text please.
Here is my postulated stalker exploit that illustrates the dangers of
exposed locators to the users:

   -

   Suppose that a user device participates in an identifier/locator
   protocol such that they cache locators and use locators to directly send to
   peer devices.
   -

   A hacker might tap all packets sent or received on the network
   interfaces which makes locators visible to them.
   -

   In order to be able to tap packets a user needs root access to the
   device. There are instructions on the web to root an Android device.
   Similarly, jailbreaking can be done to circumvent restrictions on an
   iPhone to gain the equivalent of root access.
   -

   Once root access has been obtained, packets can be tapped using tcpdump
   or similar packet sniffer application.
   -

   With the tap running and packet addresses being captured, the hacker
   just needs to drive around send traffic between two devices in their car.
   They can observe the locators that are assigned to the their device, and
   from this can create a geo map of locators.
   -

   Given that one hacker can do this, then thousands will do it and web
   sites will spring up that provide locator geo maps.
   -

   Efforts to obfuscate or rotate identifiers does not help much here.
   Obfuscation complicates routing in the network such that more
   transformations need to happen there. Locator rotation is defeated if there
   are enough devices to keep the maps up to date in a mashup.
   -

   The net effect is that this enables a stalker attack. An individual
   simply initiates a communication with their target. For instance, this
   could be a chat or phone call. If in doing this the locators for the device
   belonging to the target are made visible to the hacker, then the physical
   location of the target can be deduced using the locator geo maps described
   above.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 14:25:01 -0800

Tom, this is why addresses need to be obfuscated. And you can’t do that with address translation/transformation. I’m a fan of ILA, but the IPv6 header must be sent in the clear, and that is problematic for this issue.

Dino

> On Jan 31, 2018, at 2:02 PM, Tom Herbert <[email-masked]> wrote:
> 
> 
> Here is my postulated privacy exploit that defeats periodic address rotation [RFC4951]  and would be solved by single use addresses (a different address per connection).
> 
> 	• The attacker creates an “always connected” app that provides some seemingly benign service and users download the app.
> 	• The app includes some sort of persistent identity. For instance, this could be a login to account.
> 	• The backend server for the app logs the user identity and IP address they are using each time they connect.
> 	• When an address change happens, existing connections on the user device are disconnected. The app will receive a notification and immediately attempt to reconnect using the new source address.
> 	• The backend server will see the new connection and log the new IP address as being used by the user.
> 	• Thus, the server has a real-time record of users and the IP address they are using.
> 	• The attacker gains access to packet traces taken at some point in the Internet. The addresses in the captured packets can be time correlated with the server database to deduce the identity of the source of packets for flows communications unrelated to the app.
>  
> Note
> "The process ILA performs is a perfect transform, once at ingress to the ILA domain, into the ILA domain's address space, and a perfect transformation back at ILA egress. If the transformation isn't perfect, then a fault has occurred.
> 
> The other reason I'd avoid "translate" is that it in the IETF it carries with it the association with IPv4 NAT and its drawbacks. ILA doesn't suffer from these issues because of the full reversal of the address changes upon egress from the ILA domain.
> 
> (So how come I don't like NAT at all, yet am ok with what ILA is doing? The full reversal of the address charges at ILA egress is the first reason. Secondly, within the ILA domain, the ingress ILA device is a host, that is in effect originating the packet within the ILA domain it is sending to the egress ILA device, which is also a host or end-point within the ILA domain.
> 
> The ILA domain is effectively a virtual link layer or an underlay network for the traffic being carried between hosts outside of the ILA domain. As long as the ILA domain is perfectly transparent to the overlay network and its hosts, then what ever happens within the ILA domain doesn't matter, similar to how link layer compression, as long as fully and perfectly reversed, also doesn't matter.)"
>  
> As I said, I don't know what this proxy mode of operation is in an idloc system.
>  
> The mapping of an identifier to a user of device is only known by the local network. Outside of the local trusted network a third party should not be able to infer identity of geo-location of a user solely based on IP addresses. For that, something like IMSI can't be used to make addresses without some sort of mapping or obfuscation. 
>  
>  
> IMO, it's going to be hard not to include the control plane in discussions. That's where most of the major issues of idloc are, particularly in scaling and securing the mapping database.
>  
> Here is my postulated stalker exploit that illustrates the dangers of exposed locators to the users:
>  
> 	• Suppose that a user device participates in an identifier/locator protocol such that they cache locators and use locators to directly send to peer devices.
> 	• A hacker might tap all packets sent or received on the network interfaces which makes locators visible to them. 
> 	• In order to be able to tap packets a user needs root access to the device. There are instructions on the web to root an Android device. Similarly, jailbreaking can be done to circumvent restrictions on an iPhone to gain the equivalent of root access.
> 	• Once root access has been obtained, packets can be tapped using tcpdump or similar packet sniffer application.
> 	• With the tap running and packet addresses being captured, the hacker just needs to drive around send traffic between two devices in their car. They can observe the locators that are assigned to the their device, and from this can create a geo map of locators.
> 	• Given that one hacker can do this, then thousands will do it and web sites will spring up that provide locator geo maps.
> 	• Efforts to obfuscate or rotate identifiers does not help much here. Obfuscation complicates routing in the network such that more transformations need to happen there. Locator rotation is defeated if there are enough devices to keep the maps up to date in a mashup.
> 	• The net effect is that this enables a stalker attack. An individual simply initiates a communication with their target. For instance, this could be a chat or phone call. If in doing this the locators for the device belonging to the target are made visible to the hacker, then the physical location of the target can be deduced using the locator geo maps described above.
>  
> Tom
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 14:42:57 -0800

> Tom, this is why addresses need to be obfuscated. And you can’t do that with address translation/transformation. I’m a fan of ILA, but the IPv6 header must be sent in the clear, and that is problem…
Dino,

It's not the addresses that need to be obfuscated, it's the identity
of the user that sourced the packet that needs to remain hidden. As
shown my postulated attack, if a user repeatedly the uses same address
in unrelated flows, it would be easy for a third party to deduce their
identity in their flows. NAT is an example of a process that
obfuscates identity to provide good privacy.

Tom

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 14:55:15 -0800

> It's not the addresses that need to be obfuscated, it's the identity

I think both. 

> of the user that sourced the packet that needs to remain hidden. As

And I think there will be non-human users using such addresses. They need to be protected too. If you have a “default network to send anywhere”, then anything can be attacked.

> obfuscates identity to provide good privacy.

It doesn’t help. If Tom is protected from sending packets from his house, I still can deduce its Tom’s house.

You have to change and obfuscate EIDs and you have to keep using different RLOCs. Cat and mouse game.

Dino

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 15:18:37 -0800

> It doesn’t help. If Tom is protected from sending packets from his house, I still can deduce its Tom’s house.

That should only be true if you are my network provider. To anyone
else the only thing they should be able to deduce from an address is
that the packet originated from a random user of my network provider.

> You have to change and obfuscate EIDs and you have to keep using different RLOCs. Cat and mouse game.
For best privacy you would keep using different source addresses
(identifiers) for different flows, Locators are not an issue if their
visibility is restricted to the provider network, so that neither UEs
nor external nodes ever see them .

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 15:25:02 -0800

> that the packet originated from a random user of my network provider.

I can tcpdump packets on my router for packets you send before the locator is translated back to the sir-prefix. And count on the locator being in DNS for a reverse lookup so I can get some ascii text that gives me a clue.

> nor external nodes ever see them .

Don’t you want your provider to not track you?

Dino

---

From: Ca By <[email-masked]>
Date: Wed, 31 Jan 2018 23:50:58 +0000

On Wed, Jan 31, 2018 at 2:25 PM Dino Farinacci <[email-masked]> wrote:

> Tom, this is why addresses need to be obfuscated. And you can’t do that
> with address translation/transformation. I’m a fan of ILA, but the IPv6
> header must be sent in the clear, and that is problematic for this issue.
>
> Dino

And again, i really have no idea on what problem Tom and Dino are trying
solve that they think a mobile operator would want to implement.

I see Tom and Dino jockeying their solutions, but they are not solutions to
problems that network operators have articulated.

I believe at one point this listed agreed to produce requirements but then
quickly decided it was better to have secret group (design team?) write a
white paper about  id / loc.

IMHO id / loc has zero traction in mobile , it is not present in any of the
well publicized “5G” deployments that are currently going on.

On this list, id/loc is a solution looking for a problem.

Just $0.02 about the echo chamber we are in.

>
> > On Jan 31, 2018, at 2:02 PM, Tom Herbert <[email-masked]> wrote:n
> >
> >
> >       • The attacker creates an “always connected” app that provides
> some seemingly benign service and users download the app.
> >       • The backend server for the app logs the user identity and IP
> address they are using each time they connect.
> >       • When an address change happens, existing connections on the user
> device are disconnected. The app will receive a notification and
> immediately attempt to reconnect using the new source address.
> >       • The attacker gains access to packet traces taken at some point
> in the Internet. The addresses in the captured packets can be time
> correlated with the server database to deduce the identity of the source of
> packets for flows communications unrelated to the app.
> >
> > Note
> > (So how come I don't like NAT at all, yet am ok with what ILA is doing?
> The full reversal of the address charges at ILA egress is the first reason.
> > The ILA domain is effectively a virtual link layer or an underlay
> network for the traffic being carried between hosts outside of the ILA
> domain. As long as the ILA domain is perfectly transparent to the overlay
> network and its hosts, then what ever happens within the ILA domain doesn't
> matter, similar to how link layer compression, as long as fully and
> perfectly reversed, also doesn't matter.)"
> >
> > The mapping of an identifier to a user of device is only known by the
> local network. Outside of the local trusted network a third party should
> not be able to infer identity of geo-location of a user solely based on IP
> > IMO, it's going to be hard not to include the control plane in
> discussions. That's where most of the major issues of idloc are,
> particularly in scaling and securing the mapping database.
> >
> >       • Suppose that a user device participates in an identifier/locator
> >       • A hacker might tap all packets sent or received on the network
> >       • In order to be able to tap packets a user needs root access to
> the device. There are instructions on the web to root an Android device.
> Similarly, jailbreaking can be done to circumvent restrictions on an iPhone
> to gain the equivalent of root access.
> >       • Once root access has been obtained, packets can be tapped using
> tcpdump or similar packet sniffer application.
> >       • With the tap running and packet addresses being captured, the
> hacker just needs to drive around send traffic between two devices in their
> car. They can observe the locators that are assigned to the their device,
> and from this can create a geo map of locators.
> >       • Given that one hacker can do this, then thousands will do it and
> web sites will spring up that provide locator geo maps.
> >       • Efforts to obfuscate or rotate identifiers does not help much
> here. Obfuscation complicates routing in the network such that more
> >       • The net effect is that this enables a stalker attack. An
> individual simply initiates a communication with their target. For
> instance, this could be a chat or phone call. If in doing this the locators
> for the device belonging to the target are made visible to the hacker, then
> the physical location of the target can be deduced using the locator geo
> maps described above.
> >
> > Tom
> >

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 16:01:17 -0800

> And again, i really have no idea on what problem Tom and Dino are trying solve that they think a mobile operator would want to implement. 

I’m trying to solve for the general case. And if possible, then 5G could benefit regardless if anyone thinks it is needed or not.

> I see Tom and Dino jockeying their solutions, but they are not solutions to problems that network operators have articulated. 

We both are trying to make both solutions better.

> I believe at one point this listed agreed to produce requirements but then quickly decided it was better to have secret group (design team?) write a white paper about  id / loc.  

Note the [email-masked] mailing list is copied. 

> IMHO id / loc has zero traction in mobile , it is not present in any of the well publicized “5G” deployments that are currently going on. 

Then you can ignore us. But many of us want to think out loud freely and learn from each other.

> Just $0.02 about the echo chamber we are in. 

You will have to use your email filters then.

Dino

---

From: Ca By <[email-masked]>
Date: Thu, 01 Feb 2018 00:05:58 +0000

On Wed, Jan 31, 2018 at 4:01 PM Dino Farinacci <[email-masked]> wrote:

> I’m trying to solve for the general case. And if possible, then 5G could
> benefit regardless if anyone thinks it is needed or not.
>
> > I see Tom and Dino jockeying their solutions, but they are not solutions
> to problems that network operators have articulated.
>
> > I believe at one point this listed agreed to produce requirements but
> then quickly decided it was better to have secret group (design team?)
> write a white paper about  id / loc.
>
> > IMHO id / loc has zero traction in mobile , it is not present in any of
> the well publicized “5G” deployments that are currently going on.
>

Ack.  Just contributing to the archive that 2 protocol wonks doting on
their own creations is not a working group or 5G.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 16:08:40 -0800

> I can tcpdump packets on my router for packets you send before the locator is translated back to the sir-prefix. And count on the locator being in DNS for a reverse lookup so I can get some ascii t…

Again, that is only true if your router is in the provider network  If
locators imply geo-location, which they likely would in a mobile
network, then exposing them to anyone outside of the trusted network
is asking for trouble.
> Don’t you want your provider to not track you?

It's inherent in the operations  that my provider tracks me in order
to be able to forward packets. But, I have a contractual agreement
with the provider to do that and protect privacy. For anyone outside
of my provider, I don't want them to be able to track me. This is why
I don't want locators to be visible outside of the network. That would
include UEs attached to the network (they are not trusted devices) and
putting locators in DNS.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 31 Jan 2018 16:16:12 -0800

On Wed, Jan 31, 2018 at 4:05 PM, Ca By <[email-masked]> wrote:
>> > then quickly decided it was better to have secret group (design team?) write
>> > a white paper about  id / loc.
>>
> Ack.  Just contributing to the archive that 2 protocol wonks doting on their
> own creations is not a working group or 5G.
>
Ca,

3GPP CT4 working group has initiated a study of user plane protocol in
5GC for Release-16. Our intent is for ILA to be a candidate for that
study.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 31 Jan 2018 17:32:58 -0800

What if you and I are running ILA and are attached to different providers. How do you get packets to me if my locators are not exposed outside my provider?

Dino

> On Jan 31, 2018, at 4:08 PM, Tom Herbert <[email-masked]> wrote:
>