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

Dino Farinacci <> Wed, 11 October 2017 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 981451342DF; Wed, 11 Oct 2017 13:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uP33ybxaUfcz; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0E691330C1; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
Received: by with SMTP id b85so1873087pfj.13; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=omD/jzmAGtRvmPhYaA4R3ozEGotE0Wc5ccebyDMcEbw=; b=ZzlBsMsqunyigHGNOa3Ju+Gzo6zo7rl6q9wyfMhY5n2RYCdq5cb5IHCCkpOLVkTr9T t9MzopETYgTyW6sK5Pwd/Pon90WVdjeQJbDgxQ3MCLLLNQf5Kt0CqFXsJZKIOouQ5tuq J4O4x28npTiY1dhiTEipbVtfDvNPqci/Sw1rtAVrrl/zSxaa3qgTI+u2ZvzqElpR35rt 9lDmKDglqZOXODTBIBsFCztlO8FI9+4v43BdmOZ3FPaNXPEOEYd6Rgtkqwp0z6Npedkd ITSyi1jOGz0yUwFogf6MWCtOzuZAzqcFkh6WytBkRQhrebmSiyy8xvue4yZi2alxYNCw yjUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=omD/jzmAGtRvmPhYaA4R3ozEGotE0Wc5ccebyDMcEbw=; b=WaNpqZZKaZSKZKfLn72gqLi4fgg0xfQ7bTe51yIVl5qKDtITbci6UoH4RMXA2t4hK9 pyFXf+qgZNifHzG4cazDzMcAmcBSxkyZ607P0e+cCJuCe2JXKoXLlP+/YHRn97s+0wfA IfuM22pgSyvloEAUSbXdv6765JjzXlSQzUgVPeGrh2OEVSHN02ooZyqBEOLrw//omtqw mr5afNffeBXdKBFZz74FsMbn+DxcKUZiSTmhI2+cfi597X/xjpJ1GZZH+2F6nqkBD2pu Ph+ksIhrnJW7hnr6CsEg43oH+yPCx/ZBJsQeOfWOpF0UAC/n+kYalFHiR4zLstydNcGC vgFg==
X-Gm-Message-State: AMCzsaWlJ5R8Ifxevn/WYi7iwEl4fCIjMoBgl/rBGprMcEejqDpkgFli vfvg/DTzFCKZoGGNGIocuMUnmRM7
X-Google-Smtp-Source: AOwi7QAEeAVcn6/I5jmYsNr5MiAAPDZMp64Fg2RjjbplYEe6XkvVNdUTfHkQCsngebtLjggqzkndSA==
X-Received: by with SMTP id p25mr158145pgc.26.1507752789320; Wed, 11 Oct 2017 13:13:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a25sm25523054pfc.143.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Oct 2017 13:13:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Wed, 11 Oct 2017 13:13:07 -0700
Cc: Christian Huitema <>, "" <>, "" <>, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Oct 2017 20:13:12 -0000

> 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?

> 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.