Re: [lisp] id locator privacy presentation

[Dino Farinacci <[e-mail]>]

Here are my comments on your slides with respect to what draft-ietf-lisp-eid-anonymity is addressing.


The draft indicates more than one random or crypto EID can be used.


Random EIDs may not survive moves but it is a function of how long you want them to be active. If you do not want to shut down transport connections during moves, you must keep using the EID. And for crypto-EIDs that will usually have a longer lifetime than a random-number generated EID, will have the mobility benefits with session survivability. Crypto-EIDs are longer lived just because you want to contain the cost of key-pair generation.


Obviously LISP-proper has long-lived EIDs by default. So the original EID definition does focus on long-lived EIDs. But we want to go the other way and not associate an EID to a human. But its a moving scale from one side to the other.


In terms of RLOC hiding, it is a hard problem since RLOCs have to appear in outer unencrypted IP headers. But if a service provider can allocate a set of RLOCs to an interface, then a LISP capable system can change the use of RLOCs while rotating ephemeral-EIDs. So the 2-tuple is constantly changing. Also, when lisp-crypto is used no one can see the ephemeral-EID in the packet. All an observer can see is a rotated RLOC and can only associate it with a service-provider. 

If we need more privacy than that, I suggest service providers allocating addresses that don’t have geographical relationship and certainly don’t DNS reverse name them. ;-)


The mapping system can authenticate and authorized lookup users. So not anyone can get the RLOC of an EID. You can only allow all EIDs in an VPN instance-ID to get access and even a subset if you white-list.


An oberver only sees LISP-crypto packet RLOCs and not EIDs. So it doesn’t know who the end-system is just that “its a customer of Comcast” perhaps.


I don’t know what a fixed-point anchor locator means. But in LISP, a provider-assigned RLOC typically doesn’t change. But sitting behind an IPv4 NAT it can. Meaning the address can change but most likely (and often) the (address, port) pair changes due to port changing on NAT state timeout.

Note when RTRs are used as anchor points, remote ITRs that encapsulate only know to use the RLOC of the RTR and doesn’t know the RLOC of the EID. In my implementation, only the RTR lookup request for the EID returns the RLOC of the EID, but others only see the RLOC of the RTR.

So after reading the slide-set and before re-reading your Internet-Draft, I think LISP has all the features for good privacy. I’m not going to claim perfect privacy because you never can but good enough. Please comment.

Thanks,
Dino

> On Mar 29, 2019, at 11:06 AM, Erik Nordmark <[e-mail]> wrote:
> 
> 
> Dino,
> 
> You don't have to wait until the next meeting for a presentation.
> 
> There is the draft:
> https://tools.ietf.org/html/draft-nordmark-id-loc-privacy-00
> 
> The slides:
> https://datatracker.ietf.org/doc/slides-102-intarea-privacy-issues-in-idlocator-separation-systems/
> 
> The video: starts at 1:34:20 in
> https://www.youtube.com/watch?v=PlC0xdk38tc
> 
> It probably makes sense to refer to that in the anonymity draft.
> 
> Regards,
>   Erik
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp