> 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
