Subject: Re: [Ideas] [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Sat, 6 May 2017 18:24:38 +0000

FYI The work for a common control plane architecture across all identifier-locator protocols is underway in IDEAS.
Here is a pointer to the PS and it references to companion documents in section 10 as well.

ideas-problem-statement-01<https://tools.ietf.org/html/draft-padma-ideas-problem-statement-01>

I am also copying the IDEAS alias.

Thanks
Padma

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 05, 2017 7:14 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Dear Marco, and all,

Thanks for all the valuable comments – regarding many addressing ILA we saw that we need to clarify more our scope as mentioned in the PS draft to work on access connectivity and session management in case of multiple technologies – while mobility is only one aspect of (but for many use cases can be kind of neglected). Thus we believe to address an issue not yet dealt with elsewhere in IETF in that detail.
And BTW from ILA we basically want to inherit the concept and principle but need to change a lot … as you already discussed here.
Thanks!
Best Regards
Dirk

From: 5gangip [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Freitag, 5. Mai 2017 10:45
To: [email-masked]; Ca By
Cc: [email-masked]; von Hugo, Dirk; Lorenzo Colitti
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Good comments and I think we should rather talk about identifier-locator addressing as a principle not about a
particular specification at this point in time. Address re-write can be a suitable principle to steer traffic without the
need to encapsulate. I don’t see a problem applying the principle to both, per-host /64 and IPv6 addresses.

Btw, I see this as enabler to de-couple a serving anchor node from the actual IP address or per-host prefix
that it anchors. Traditionally the mobile device address/prefix is assigned from the anchor’s network (topologically
correct) hence serves as routable identifier up to the anchor node. Address/prefix re-write enables steering
downlink traffic to a new anchor node after anchor relocation (or anchor movement as pointed out below in
this eMail thread) in case IP address continuity is required by the device or its applications.

marco

From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Donnerstag, 4. Mai 2017 17:40
To: Ca By
Cc: [email-masked]<mailto:[email-masked]>; Lorenzo Colitti; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Hi Cameron,

Thanks for your constructive comments as always.
Please see inline.

On Thu, May 4, 2017 at 7:43 AM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 4, 2017 at 3:39 AM Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

this draft mentions using ILA for mobility But ILA cannot be used as is for UE addressing because ILA only supports mobility of individual IPv6 addresses, not prefixes. That contravenes IETF best practices for IPv6 address allocation, which say that networks should either allow hosts to form IPv6 addresses at will, or to assign a /64 prefix to each host. See RFC 7934.

All current 3G and 4G networks follow those best practices, because they assign a /64 prefix to the UE. These are very widely deployed (hundreds of millions of subscribers). We should ensure that 5G networks can do the same.

Cheers,
Lorenzo

I fully agree with Lorenzo.  ILA does not have sufficient capabilities to match GTP based mobility we have today.

You mean ILA as in draft-herbert-nvo3-ila-04?
Absolutely.
As we describe in the PS, we need many revisions on that hopefully as part of our 5G IP work.
Maybe the new protocol will need to be given a different name, not to inherit all these comments :)

A step backwards is unacceptable.
Sure.

It is also not clear how ILA would support slicing.  Being able to move the mobility anchor / PPF dynamically will be a key component for many 5G usecases.

You mean UPF? This is what we have in 5G architecture, yes it is virtualized PGW.
Thanks for pointing the slicing issue, that is something we need to look into.

Regards,

Behcet
Regards,
Cameron

On Wed, May 3, 2017 at 11:00 PM,  <[email-masked]<mailto:[email-masked]>> wrote:
> Dear all,
>
> As announced yesterday we have uploaded the problem statement draft you find
> below.
>
> Thanks for reading, discussing, commenting …!
>
>
>
> Best Regards – also on behalf of all the authors
>
>
>
> Behcet & Dirk
>
>
>
>
>
> On Tue, May 2, 2017 at 4:25 PM, <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> A new version of I-D, draft-xyx-5gip-ps-00.txt
> has been successfully submitted by Behcet Sarikaya and posted to the
> IETF repository.
>
> Name:           draft-xyx-5gip-ps
> Revision:       00
> Title:          5G IP Access Mobility and Session Management Protocols
> Document date:  2017-05-02
> Group:          Individual Submission
> Pages:          14
> URL:
> https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-xyx-5gip-ps/
> Htmlized:       https://tools.ietf.org/html/draft-xyx-5gip-ps-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-00
>
>
> Abstract:
>    This document builds upon 5G IP issues work and - based on a
>    simplified 5G system architecture - attempts to make the case for a
>    possible set of new protocols that need to be developed to be used
>    among various virtualized functions in a 5G network.
>
>
>
>
> 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<http://tools.ietf.org>.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/5gangip
>
_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: <[email-masked]>
Date: Mon, 8 May 2017 07:41:56 +0000

Hi all,

Although I agree that an introduction needs to be short I am wondering whether “data integrity” and “confidentiality” should be this close together without more explanation.

“As these communications will most likely be unmonitored, there are
   concerns regarding their discovery (privacy) , accessibility
   (possible breach) and data integrity (confidentiality).
"

How about changing that sentence to

“As these communications will most likely be unmonitored, there are
   concerns regarding their discovery (privacy) , accessibility
   (possible breach) and data protection (confidentiality, integrity).
”

Cheers
Axel

From: Ideas [mailto:[email-masked]] On Behalf Of Padmadevi Pillay Esnault
Sent: Saturday, May 06, 2017 8:25 PM
To: [email-masked]; [email-masked]
Cc: Padmadevi Pillay Esnault
Subject: Re: [Ideas] [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Thanks
Padma

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, May 05, 2017 7:14 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Dear Marco, and all,

From: 5gangip [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Freitag, 5. Mai 2017 10:45
To: [email-masked]<mailto:[email-masked]>; Ca By
Cc: [email-masked]<mailto:[email-masked]>; von Hugo, Dirk; Lorenzo Colitti
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

marco

Hi Cameron,

Cheers,
Lorenzo

Regards,

Behcet
Regards,
Cameron

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Mon, 8 May 2017 14:45:36 +0000

Hello Axel

Thanks for the suggestion. We should make this change, looks clearer.
Cheers
Padma

PS Pertaining to ideas therefore bccing 5gangip

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 08, 2017 12:42 AM
To: Padmadevi Pillay Esnault; [email-masked]; [email-masked]
Subject: RE: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Hi all,

Cheers
Axel

Thanks
Padma

Dear Marco, and all,

marco

Hi Cameron,

Cheers,
Lorenzo

Regards,

Behcet
Regards,
Cameron

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 00:10:39 +0000

+ IDEAS

https://tools.ietf.org/html/draft-padma-ideas-use-cases-00 

Section 7 covers this use case - I saw you are part of this (may be this use case didn't come from you)

This is being worked out  and solution would be put forth soon..

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2017 5:00 PM
To: Uma Chunduri <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

On Wed, May 10, 2017 at 4:47 PM, Uma Chunduri <[email-masked]> wrote:
>
>         >No, the source address does not change, TCP connections don't break.
>
> Source address can change if UE moves from UPF serving area.
> But, now I see your case is (R)AN mobility case (same UPF serving area).
>
>         >Please see my example I posted previously. Overlay networks (tunnels) are used between EnodeBs and gateways.
>                 >A distributed mapping service is run that these nodes share, so the Internet can communicate with mobile hosts and mobile hosts can communicate between themselves.
>                >This method is transparent to hosts including UEs and there are no changes need to transport layer. It's a fairly straightforward use of tunneling once an efficient mapping system is in place.
>
> I get that.
>
> Then this is may be good for 4G, but I guess we are talking about 5G here and I assumes PGW/UPF mobility and hence the Source IP address change is considered in your solution.
>
In that case the TCP connection would break regardless. Transport layer mobility, like QUIC, might then be solution.

> --
> Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 17:58:04 -0700

> This is being worked out  and solution would be put forth soon..
Okay, I think I see the confusion.

In an Identifier/Locator split there are two addresses that are
associate with a node. One is the identifier that expresses the
logical and persistent address of the node ("who")-- this what
applications see and what might returned from DNS if an addressed is
looked by domain name. The other address is the locator, this
expresses where the node is current at ("where"). As a mobile node
moves from place to place it's location changes so it's locator
changes. But, it's identifier address does not change-- that uniquely
identifies the node regardless of where it's at. In order to send to a
node (by it's identifier address, a some point in the path, someone
needs to know to that to reach the addressed node the packet has to be
sent to its locator address. So there is a mapping from identifier to
locator and then packet is forwarded to locator address (by
encapsulation, segment routing, ILA, etc.). This really equivalent to
virtual to physical address mapping, or home address to mobile
address.

So it's really the locator address for a node that changes, not the
the identifier. The system needs to ensure that packets delivered to
the application always get the identifier address and that keeps
source address persistent.

Tom

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 10 May 2017 20:07:17 -0700

Herewith a suggested substitute for existing section 8.  Rationale
below:

<start>
8 Security considerations.

At the problem statement level of abstraction it's important to
identify the issues within scope.  And equally important to identify
those outside scope.  

5g represents infrastructure at layers 1, 2, and 3 of the ISO model.
Each of those layers contains security issues.  

But 5G does not include issues at layers 4 and up.  Therefore the
security issues here are outside scope:
  - authenticity, integrity and confidentiality of content data (aka
payload) is outside scope.  These are layer 6 and 7 issues, almost
always end-to-end (meaning beyond reach of 5g).  
  - connection integrity encompasses two issues: identity of the end
system that a subscriber is connecting to and reliable delivery of all
packets.  The former has been handled, with greater or lesser security
with DNS and the connection setup protocols in TCP (as an example of a
transport protocol).  Scope (see if I'm reading this right): these
requirements and features are not changed and they are outside 5g
scope. That said, the volatility of the infrastructure (rapid address
changes) makes the problem harder and cascading requirements may
emerge.
  - layer 3 security concerns include authenticity of infrastructure
nodes (is this router bogus or true?).  This is where the VPN language
belongs (Tom Herbert's comments from Friday, for example).  These are
within scope.
  - layer 2 security issues include a host of possibilities.  But frame
address integrity is clearly in scope, and suitable for
standardization.
  - layer 1 security issues are outside scope, largely because they are
1) single vendor issues and 2) volatile technological issues not
suitable for standardization.

<end>

Rationale.  First, security should not be bolted on after we thrash
everything else; needs to be built in.  The existing rather boilerplate
is not, IMHO, very appropriate to get this started.
   Secondly, even before considering requirements, some scoping (or, if
it suits you, a sorting model) is necessary to organize things.  In my
experience the ISO Reference Model is made to order.
   Pick at whether this or that is in scope or out, but we need to
thrash that early, like now, before we progress to requirements and
from there to proposed solutions.

Help?

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 May 2017 20:20:49 -0700

> source address persistent.
And this stable identifier has horrendous privacy issues. Or can have,
especially if you were to have a design in which a mobile device has
just one such identifier and keeps it all the time. It becomes a
beautiful tracking beacon.

-- Christian Huitema

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 21:17:20 -0700

> beautiful tracking beacon.
Identifiers (anything that is persistent over time that can be
tracked) needs to be obfuscated to prevent the tracking. I believe
WAVE already has done some good work towards that end.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 05:36:26 +0000

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Wednesday, May 10, 2017 5:58 PM
To: Uma Chunduri <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

[Uma]: I don't see any confusion.
               I was just saying the solution you described here https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html
               doesn't solve IP address change case (UPF change) but only addresses (R)AN mobility.

In an Identifier/Locator split there are two addresses that are associate with a node. One is the identifier that expresses the logical and persistent address of the node ("who")-- this what applications see and what might returned from DNS if an addressed is looked by domain name. The other address is the locator, this expresses where the node is current at ("where"). As a mobile node moves from place to place it's location changes so it's locator changes. But, it's identifier address does not change-- that uniquely identifies the node regardless of where it's at. In order to send to a node (by it's identifier address, a some point in the path, someone needs to know to that to reach the addressed node the packet has to be sent to its locator address. So there is a mapping from identifier to locator and then packet is forwarded to locator address (by encapsulation, segment routing, ILA, etc.). This really equivalent to virtual to physical address mapping, or home address to mobile address.
So it's really the locator address for a node that changes, not the the identifier. The system needs to ensure that packets delivered to the application always get the identifier address and that keeps source address persistent.

[Uma]: Precisely  and I don't see how you get that stable identifier in ILA where you split Identity and Locator (ILA) logically  in the same UE address where your host on the other end is communicating to (in your example https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html )

Tom

> Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti
> <[email-masked]>; [email-masked]; [email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 05:45:00 +0000

>And this stable identifier has horrendous privacy issues. Or can have, especially if you were to have a design in which a mobile 
                >device has just one such identifier and keeps it all the time. It becomes a beautiful tracking beacon.

Fully agree and this must be considered as one of the mandatory security aspect in the solution space (HIP solves this by anonymizing by generating the hashes for identifiers)

--
Uma C.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 May 2017 09:31:45 -0500

> source address persistent.
Folks, these are Tom's personal thinking. Those that are not mentioned in
the PS draft are not in scope.

Behcet

> > Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti <
> [email-masked]>; [email-masked]; [email-masked]
> >>         >Please see my example I posted previously. Overlay networks
> (tunnels) are used between EnodeBs and gateways.
> >>                 >A distributed mapping service is run that these nodes
> share, so the Internet can communicate with mobile hosts and mobile hosts
> can communicate between themselves.
> >>                >This method is transparent to hosts including UEs and
> there are no changes need to transport layer. It's a fairly straightforward
> use of tunneling once an efficient mapping system is in place.
> >>
> >> I get that.
> >>
> >> Then this is may be good for 4G, but I guess we are talking about 5G
> here and I assumes PGW/UPF mobility and hence the Source IP address change
> is considered in your solution.
> >>
> > In that case the TCP connection would break regardless. Transport layer
> mobility, like QUIC, might then be solution.
> >
> >> --
> >> Uma C.
> >>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 May 2017 14:04:23 -0500

> the PS draft are not in scope.

Let me clarify. I apologize if I offended anybody. No offense folks.
We are not in the business of policing people.
In our list mails are written freely and people write whatever they think,
i.e. it is an IETF list.

Regards,

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 May 2017 16:12:40 -0700

On Wed, May 10, 2017 at 10:36 PM, Uma Chunduri <[email-masked]> wrote:
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
>                I was just saying the solution you described here
> https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html
> In an Identifier/Locator split there are two addresses that are associate
> with a node. One is the identifier that expresses the logical and persistent
> address of the node ("who")-- this what applications see and what might
> returned from DNS if an addressed is looked by domain name. The other
> address is the locator, this expresses where the node is current at
> ("where"). As a mobile node moves from place to place it's location changes
> so it's locator changes. But, it's identifier address does not change-- that
> uniquely identifies the node regardless of where it's at. In order to send
> to a node (by it's identifier address, a some point in the path, someone
> needs to know to that to reach the addressed node the packet has to be sent
> to its locator address. So there is a mapping from identifier to locator and
> then packet is forwarded to locator address (by encapsulation, segment
> routing, ILA, etc.). This really equivalent to virtual to physical address
> mapping, or home address to mobile address.
> So it's really the locator address for a node that changes, not the the
> identifier. The system needs to ensure that packets delivered to the
> application always get the identifier address and that keeps source address
> persistent.
>
> [Uma]: Precisely  and I don't see how you get that stable identifier in ILA
> where you split Identity and Locator (ILA) logically  in the same UE address
> where your host on the other end is communicating to (in your example
> https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html )
>

The procedures are described in the ILA draft also
(https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila). For
instance Scenario 7 shows Internet host to tenant system.
>>> Then this is may be good for 4G, but I guess we are talking about 5G here
>>> and I assumes PGW/UPF mobility and hence the Source IP address change is
>>> considered in your solution.
>>>