Subject: Re: [lisp] Fwd: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA

From: [email-masked] (Noel Chiappa)
Date: Sun, 8 Sep 2013 10:04:33 -0400 (EDT)

> From: Marc Binderberger <[email-masked]>

    > Lisp is separating Identity from Location but this doesn't mean the
    > RLOC can not be used to identify you. In case of static setups this is
    > obvious, take the RLOC, go to the ISP, get the (physical) address and
    > name.

Err, that would get the address and name of the ITR, not the actual source
host.

Depending on all sorts of factors, that plus the encrypted packet _might_ get
them the identity of the actual originator (not, for example, if the ITR has
discarded the key used to encrypt the packet by the time the subpoena
arrives...)

	Noel

---

From: Edward Lopez <[email-masked]>
Date: Sun, 8 Sep 2013 15:04:44 +0000

Key generation/management/distribution would be the real difficulty.  It would be desirable to use symmetric encryption (Ex. AES256) to encrypt LISP payloads.  Therefore, we use certs & asymmetric encryption (some form of ECC) at the time of xTR registration to provide a method to distribute keys to authenticated site members.

Another consideration is to encrypt just the EID header, and have EIDs use IPSec (thus LISP would in effect encrypt the outer IPSec ESP header).  Someone in the RLOC space would then require two keys to decrypt the message fully, and the encryption load would be distributed between EIDs and xTRs

Ed Lopez

Sent from my iPhone ... Sorry for any auto-correct errors

On Sep 8, 2013, at 10:04 AM, "Noel Chiappa" <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Sun, 8 Sep 2013 18:30:24 +0000

I think it would actually be quite interesting to use "standard" public key encryption, rather than symmetric encryption in LISP. This would reduce the need for negotiations, not require pairs of ITRs and ETRs to share the same map server, etc. Admittedly it might not be practical for other reasons.. (may need to store lots of large keys, might be too slow, etc)

Here's one way to do it:
You could easily attaching a PGP key id to the RLOCs in the mapping record returned in map-replies. When an ITR receives a map-reply, the ITR could grab the public key from one of the well-known keyservers, and use that public key for encrypting traffic to that ETR.

Best regards,

Michiel

---

From: Edward Lopez <[email-masked]>
Date: Sun, 8 Sep 2013 20:10:02 +0000

I agree that asymmetric encryption may be more desirable in theory, but in practice symmetric encryption supports much higher performance loads

Ed Lopez - Fortinet
VP, Carrier Solutions
1090 Kifer Road
Sunnyvale, CA 94086
+1 703 220 0988

---

From: Marc Binderberger <[email-masked]>
Date: Sun, 8 Sep 2013 22:50:14 +0200

Hello Noel,

> Err, that would get the address and name of the ITR, not the actual source

this thread started with a subject of how to save the Internet from the 
all-powerful agencies. Lisp was not invented to hide your identity, 
it's only separating it from the location - this doesn't mean the 
location information cannot reveal your (real life) identity. At the 
end the agencies want your name, not your (inner) IP address.

If the xTR is close to you, e.g. your DSL router runs the xTR, then the 
locator is effectively a 1:1 mapping to your identity. If the xTR is 
your office branch router, well, then we have already  (a) a router to 
try to break in  and (b) a physical office location to look for you.

And if the xTR is further away from your Internet connection point then 
chances are you can get wire-tapped on your way to/from the xTR, i.e. 
Lisp would not help you at all.

That's all I wanted to say with my statement about "static setups".

Complete different story is if Lisp could make encryption e.g. between 
company office sites much easier, more scalable etc.. Independent from 
the original subject that would be a real benefit.

Regards, Marc

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 8 Sep 2013 19:04:25 -0700

> I think it would actually be quite interesting to use "standard" public key encryption, rather than symmetric encryption in LISP. This would reduce the need for negotiations, not require pairs of I…

Correct. If we don't start with the above assumptions, anything else will be too complicated to implement and deploy and therefore, corners will be cut, and insecurity will continue.

> You could easily attaching a PGP key id to the RLOCs in the mapping record returned in map-replies. When an ITR receives a map-reply, the ITR could grab the public key from one of the well-known ke…

Do you not want to solve man-in-the-middle attacks? Is this recommendation solely for providing data privacy?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 8 Sep 2013 19:06:28 -0700

> I agree that asymmetric encryption may be more desirable in theory, but in practice symmetric encryption supports much higher performance loads

But with asymmetric we can use a two packet exchange (the Map-Request and Map-Reply), store the public key only in the mapping database (no other components necessary), allow an ITR to send Map-Requests to the map-resolver where Map-Replies are sent from an ETR connected to another map-server (the map-resolver is not the map-server for the ETR).

Yes, it is slow, but that is the cost for the best security.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 8 Sep 2013 19:15:35 -0700

> end the agencies want your name, not your (inner) IP address.

Marc, you may have not followed Noel's point. Let me explain with more detail.

(1) I sit at a LISP site, I have an EID assigned to me. I want to send packet and don't want anyone in the core to know I am sending.

(2) My EID comes out of an EID-prefix that is assigned to the site I currently reside in. There are a pair of ITRs that encapsulate traffic for packets I source.

(3) When I source packets, my EID is known by routers inside of the site, but when the packet hits the ITR, the ITR will encrypt the entire packet it is about to encapsulate. So the outer IP header, the UDP header, and the LISP header is sent in the clear. Everything after the LISP header is encrypted.

(4) I propose that the ITR use a public-key stored in the mapping database. It does not need to be protected during transport. The only parties that have the private-key the ETRs at the destination site (and you can h a public/private pair per ETR).

(5) Men in the middle cannot decrypt the encapsulated packet because they don't have the private key and it is never transmitted on the network. All they know is that a packet came from some site that is connected to ISP foobar. So what, that is coarse information.

(6) The key is obtained by the ITR the same time it is getting the RLOC address for encapsulation. Both come together and if the EID or *key* changes, we treat it as a mobility event where a new registration is sent to the mapping database to advertise a new RLOC address and/or a new key.

This is pretty simple. Yes it is slow. But so what. We can throw hardware technology at it or we can have th math guys come up with as good but less expensive algorithms.

> try to break in  and (b) a physical office location to look for you.

It's not all that simple. EIDs can roam around. So if the RLOC at my house is encapsulating packets because you came over for dinner, it isn't me that is sourcing. I might be blamed for your wrong-doing, but all I would say is "I only live there".   ;-)

Dino

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Sep 2013 05:01:30 -0400

Doesn't this depend upon where the ITR is?
If, as is usually proposed, the ITR is a piece of CPE, then it will hide 
the content of my message (good), and my individual EID (okay), but it 
won't hide which site is sending the packet, which is an awful lot of 
information.

Also, moving the ITR to the PE router merely means that all the 
information is collectible at that point.  And we have observable data 
that collectible => will be collected.

Yours,
Joel

---

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Mon, 9 Sep 2013 10:28:32 +0000

Even in the case where the ITR is on the CPE we might be able to do better.

For IPv6 RLOCs, we could use temporary IPv6 addresses (IPv6 privacy
extension, rfc4941 I think) as the RLOCs in outgoing packets. That way,
you couldn't discover the EID by doing a "reverse lookup" on the RLOC in
the mapping system.

This would be especially useful if the IPv6 prefix on your uplink is used
on a multipoint link, if it's just used on a point-to-point link it's a
bit pointless :)

Best regards,

Michiel

On 09/09/2013 10:01, "Joel M. Halpern" <[email-masked]> wrote:

>> (1) I sit at a LISP site, I have an EID assigned to me. I want to send
>>packet and don't want anyone in the core to know I am sending.
>>
>> (2) My EID comes out of an EID-prefix that is assigned to the site I
>>currently reside in. There are a pair of ITRs that encapsulate traffic
>>for packets I source.
>>
>> (3) When I source packets, my EID is known by routers inside of the
>>site, but when the packet hits the ITR, the ITR will encrypt the entire
>>packet it is about to encapsulate. So the outer IP header, the UDP
>>header, and the LISP header is sent in the clear. Everything after the
>>LISP header is encrypted.
>>
>> (4) I propose that the ITR use a public-key stored in the mapping
>>database. It does not need to be protected during transport. The only
>>parties that have the private-key the ETRs at the destination site (and
>>you can h a public/private pair per ETR).
>>
>> (5) Men in the middle cannot decrypt the encapsulated packet because
>>they don't have the private key and it is never transmitted on the
>>network. All they know is that a packet came from some site that is
>>connected to ISP foobar. So what, that is coarse information.
>>
>> (6) The key is obtained by the ITR the same time it is getting the RLOC
>>address for encapsulation. Both come together and if the EID or *key*
>>changes, we treat it as a mobility event where a new registration is
>>sent to the mapping database to advertise a new RLOC address and/or a
>>new key.
>>
>> This is pretty simple. Yes it is slow. But so what. We can throw
>>hardware technology at it or we can have th math guys come up with as
>>good but less expensive algorithms.
>>
>> It's not all that simple. EIDs can roam around. So if the RLOC at my
>>house is encapsulating packets because you came over for dinner, it
>>isn't me that is sourcing. I might be blamed for your wrong-doing, but
>>all I would say is "I only live there".   ;-)
>>
>> Dino
>>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Sep 2013 09:43:24 -0700

> If, as is usually proposed, the ITR is a piece of CPE, then it will hide the content of my message (good), and my individual EID (okay), but it won't hide which site is sending the packet, which is an awful lot of information.

Like I said, it depends on the granularity of hiding.

> Also, moving the ITR to the PE router merely means that all the information is collectible at that point.  And we have observable data that collectible => will be collected.

Right which I would not suggest.

It looks like Crowcroft's source-less packets is the direction people may want to go?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 9 Sep 2013 09:45:39 -0700

> you couldn't discover the EID by doing a "reverse lookup" on the RLOC in

Well in today's deployments there are no RLOC records in the mapping database. So finding an EID associated with an RLOC is a different thing to do today. And this is goodness.

But not to take away from your point. But if those private addresses are not injected into the underlying routing protocol and PE boxes run URPF, those packets will be dropped.

Dino

---

From: "Michiel Blokzijl (mblokzij)" <[email-masked]>
Date: Tue, 10 Sep 2013 14:39:10 +0000

Hi Dino,

You're right in the sense that the mapping system doesn't expose an "API" for doing reverse lookups.

It would however be possible to do reverse lookups on the map servers (since we register EID->RLOC mappings), or based on aggregate EID->RLOC mapping data, such as from what lispmon.net provides - the latter basically does address-space scans as far as I know. I guess as long as you don't have access to the map-servers, it will become more and more difficult and to do this as LISP becomes more widely deployed. As it takes longer to compile this kind of a database, the time accuracy also decreases. All of this is probably a good thing indeed :-)

> But not to take away from your point. But if those private addresses are not injected into the underlying routing protocol and PE boxes run URPF, those packets will be dropped.

As long as you use private addresses from the IPv6 prefix(es) you're allowed to use I don't think uRPF will be an issue, but I suppose the benefit would also be marginal :(

Best regards,

Michiel