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

[Alexandre Petrescu <[e-mail]>]

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

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 <[e-mail]
>     <mailto:[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] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/5gangip
> 
>     _______________________________________________
>     5gangip mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/5gangip
> 
> 
> 
> _______________________________________________
> ila mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ila
>