Re: [lisp] [Ideas] WG Review: IDentity Enabled Networks (ideas)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Wed, Oct 11, 2017 at 1:13 PM, Dino Farinacci <farinacci@xxxxxxxxx> wrote:
> When the payload is encrypted, it does not.
>
> Are the handshakes that establish the cryptographic keys used to encrypt the payload themselves encrypted? If it's IKE, the answer is probably yes, but if not, I don't know.

For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTLS could be used but it would take more RTTs to get mappings in the encapsulator (causing more packet loss).

> So let me ask you these follow-up questions:
>
> (1) If a host sources a packet with its identifier in one VM and an encapsulator in another VM (in the same physical system) encapsulates the packet but encrypts the payload before encapsulation, has the identifier remain private?
>
> (2) If in (1), the packet is decapsulated by an intermmediate point, and then reencapsulated but the packet is encrypted with a new session key (from a new ECDH exchange) to the destination, has the identifier remained private?
>
> Generally, I don't tend to think of things as being "private" or "non-private". Rather we talk about who has a given capability or piece of information. I think it's clear that in these cases the identifier was available to the machine doing the deencapsulation/reencapsulation. Obviously, that's worse for privacy than having it not have that information. How much worse depends on a lot of factors.

It needs the information for table lookups. So how private/trackable are IP addresses in packets today?

Uh really terrible? That's why things like Tor exist.

I'm not sure it's useful to continue with the technical side of the present discussion. We're not trying to design a system here. The requirements for the system the WG is to design is is properly the kind of question that needs to be hashed out for the charter for the WG.

-Ekr

 

> In this particular, work, however, it seems like the privacy concerns are about:
>
> 1. Whether the ID mapping systems reveal who is talking to who.

The charter talks about no designs or solutions. In LISP, the mappings are not revealed to the world, you need to sign Map-Registers (to make your network location available to others) and you need to sign Map-Requests (for retrieving network location).

And if you cannot get network location, you can't send packets (i.e. DoS) the destination or any nodes close to the destination (much better than what we have on the Internet today where anyone can send packets anywhere).

> 2. Whether this creates persistent identifiers that would otherwise be destroyed when people changed their location

We can solve this quite easily. I’ll use Bitcoin wallet addresses as an example. You can keep changing them for every transaction so there is no association analysis. We have a working group draft in the LISP WG that does just that.

> Maybe Christian and Stephen would like to say more about their concerns
> -Ekr

Would welcome.

Dino



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]