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

[Dino Farinacci <[e-mail]>]

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

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

> 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" <[e-mail]> wrote:
> 
>> 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
>> 
>> On 9/8/13 10:15 PM, Dino Farinacci wrote:
>>>> Hello Noel,
>>>> 
>>>>> Err, that would get the address and name of the ITR, not the actual
>>>>> source
>>>>> host.
>>>> 
>>>> 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.
>>> 
>>> 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.
>>> 
>>>> 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.
>>> 
>>> 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
>>> 
>>>> 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
>>>> 
>>>> 
>>>>> 
>>>>> 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
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>