Subject: Re: [Ila] [5gangip] 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: Alexandre Petrescu <[email-masked]>
Date: Thu, 1 Feb 2018 23:27:48 +0100

Le 01/02/2018 à 00:50, Ca By a écrit :
> On Wed, Jan 31, 2018 at 2:25 PM Dino Farinacci <[email-masked] 
> <mailto:[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.

Well, I think there is a link, but it is long.

A cellular deployment starts to deliver shorter-than-64 prefixes (i.e. 
/56) to end user.  This is for use cases like tethering.  Soon, it will 
be asked that these /56s be stable (just like user asks today that a 
IPv4 address be 'fixed'), i.e. to resist upon handovers, stay stable. 
Then, it will be asked that these stay stable not only during handovers 
between SGW but also between PGW.  Then, it will be realized that the 
only way to achieve it is with Mobile IP.  But that has problems in 
Route Optimization (there is an RFC for that).  The only way to solve 
that is with id/loc.

Another way I look at this is the following: there are too many tunnels, 
too many layers and encapsulations.  The only to way reduce that number 
is with techniques like Routing Header, or id/loc split.

But I can agree with you the link may not be very obvious.  Or that 
maybe my speculation is too long.  Or maybe someone qualify this as 
'Research'.

Alex

> 
> 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]
>     <mailto:[email-masked]>> wrote:n
>      >
>      >
>      > 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.
>      >
>      > 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.
>      >
>      > 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!
>      >
>      > 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.)"
>      >
>      > "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..
>      >
>      > Sure.
>      >
>      > "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?
>      >
>      > Again please provide some text.
>      >
>      > As I said, I don't know what this proxy mode of operation is in
>     an idloc system.
>      >
>      > "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.
>      >
>      > How?
>      >
>      > 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.
>      >
>      >
>      > 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.
>      >
>      >
>      > 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.
>      >
>      > 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.
>      >
>      > 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..
>      >
>      >
>      > 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
>      >
>      > _______________________________________________
>      > 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
> 
> 
> 
> _______________________________________________
> ila mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ila
>