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

[Eric Rescorla <[e-mail]>]

On Wed, Oct 11, 2017 at 1:13 PM, Dino Farinacci <[e-mail]> 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
>
>