> 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.
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 > > 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lisp >>>> >>> _______________________________________________ >>> lisp mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp >> _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
