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

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Feb 2018 07:51:43 -0800

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

> 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,

Here's what the path looks like

Host_1 - Internet - ILA-R - Network - ILA-N - Host_2

When Host_1 sends to Host_2 the packet is addressed to Host_2's SIR address
(externally visible addressed). The packet is routed without modification
over Internet to an ingress router (ILA-R). This router transforms the
destination with locator for Host_2 which is the rotatable prefix
associated with ILA-N. Packet is forwarded over the network. At ILA-N, the
ILA transformation is reversed so that SIR address is again the
destination.  Packet is then delivered to Host_2.

The reverse path looks the same where ILA transformation is performed by
Host_1's provider.

The path is equivalent to use of encapsulation to provide the network
overlay where ILA-R is replaced by encapsulator and ILA-N is a decapitator.

Tom

---

From: Fred Baker <[email-masked]>
Date: Thu, 1 Feb 2018 09:31:17 -0800

On Jan 31, 2018, at 2:42 PM, Tom Herbert <[email-masked]> wrote:
> 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.

Actually, this is among the more common justifications for IPv4/IPv4 NAT that I hear: obfuscation of the network itself.

Of course, https://www.youtube.com/watch?v=v26BAlfWBm8.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 1 Feb 2018 09:49:44 -0800

> Actually, this is among the more common justifications for IPv4/IPv4 NAT that I hear: obfuscation of the network itself.
The privacy and security aspects of NAT are strong. This has been
validated by law enforcement's intense dislike of it
(https://www.theregister.co.uk/2017/10/18/europol_cgnat/).  If we can
provide the same level of user privacy in IPv6 without resorting to
NAT (and satisfy LI requirements), then that justification to stick
with NAT and IPv4 is eliminated.

> Of course, https://www.youtube.com/watch?v=v26BAlfWBm8.

Very educational! :-).

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 1 Feb 2018 09:53:27 -0800

> On Feb 1, 2018, at 9:49 AM, Tom Herbert <[email-masked]> wrote:
> ...
>  If we can
> with NAT and IPv4 is eliminated

Except that a very strong (and arguably one of the original) motivation for NAT is to artificially differentiate consumer Internet service (which then effectively can’t host servers) from commercial (which then can). 

Joe

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 1 Feb 2018 10:52:10 -0800

Right, if ILA-N runs at my house, which it could, I have your source locator. I know your entry point to the network. If the ILA-R is farther away from you, it is coarser information. 

Dino

> On Feb 1, 2018, at 7:51 AM, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> 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,
> 
> When Host_1 sends to Host_2 the packet is addressed to Host_2's SIR address (externally visible addressed). The packet is routed without modification over Internet to an ingress router (ILA-R). This router transforms the destination with locator for Host_2 which is the rotatable prefix associated with ILA-N. Packet is forwarded over the network. At ILA-N, the ILA transformation is reversed so that SIR address is again the destination.  Packet is then delivered to Host_2.
> 
> The reverse path looks the same where ILA transformation is performed by  Host_1's provider. 
> 
> The path is equivalent to use of encapsulation to provide the network overlay where ILA-R is replaced by encapsulator and ILA-N is a decapitator.
> 
> Tom
>

---

From: Arashmid Akhavain <[email-masked]>
Date: Thu, 1 Feb 2018 19:48:02 +0000

Hi Tom,
Yes, 3GPP has already asked DMM to look in to this. So, shouldn't we all work on this there?

Arashmid

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: 31 January 2018 19:16
To: Ca By <[email-masked]>
Cc: 5GANGIP <[email-masked]>; Behcet Sarikaya <[email-masked]>; [email-masked]; Dino Farinacci <[email-masked]>; Tom Herbert <[email-masked]>
Subject: Re: [5gangip] [Ila] PS draft: New Version Notification for draft-hspab-5gangip-atticps-00.txt

On Wed, Jan 31, 2018 at 4:05 PM, Ca By <[email-masked]> wrote:
>
> On Wed, Jan 31, 2018 at 4:01 PM Dino Farinacci <[email-masked]> wrote:
>>
>> > 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’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
>
>
> 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