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

[Ca By <[e-mail]>]

On Wed, Jan 31, 2018 at 2:25 PM Dino Farinacci <[e-mail]> 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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/5gangip
>
> _______________________________________________
> 5gangip mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/5gangip
>