> Roger, > > Having considered this, it appears that the LISP data plane can operate in > trusted or untrusted mode. In the trusted mode, when one XTR receives a > data-plane packet from another, it can trust control plane information that > it might glean from the packet's outer IP header and LISP header. Such trust > is based on the assumption that: > > - the sending XTR is who it claims to be > - the sending XTR is not intentionally offering bad mapping information to > the receiving XTR
Determining "who" is rather nebulous. How can I trust this email is from you Ron? It's because I have ultra meta-data about you. That is, I know you can be versed in LISP so I am likely talking to another LISP spoofer that looks like Ron. So if I am getting packets from an xTR that has a global locator that is your DSL router at your house, I would expect to see the inner source EID be from the mapping. I can tell that the EID->RLOC mapping is authenticated and validated by asking the mapping system, but if Roger managed to get packets to me with BOTH your EID and RLOC, then I really don't know if those packets are coming from Ron. Now how Roger does this will be an amazing feat because a lot of ISPs between Roger and me would be very broken. > In trusted mode, the receiving XTR can glean control information from the > data plane. However, in untrusted mode, the receiving XTR must not do so. > Alternatively, it must send a verifying MAP-REQUEST to the mapping system. If you encrypt data to me, I cannot tell you are actually Roger or Ron. But the conversation between me and Roger (who is spoofing Ron) will be confidential. ;-) We either have total privacy or we have NSA intrusion. ;-) You can't have both so we should have the former. > So far, all of this is covered nicely between RFC 6830 and the LISP threats > document. However, we have yet to explore the threats associated with > unsecured mode operation, where gleaned information cannot be used. This is true. When a system receives an ARP-request it gleans the source information in there to minimize broadcast traffic for returned unicast traffic. That is a benefit willing to receive at a cost of knowing a LAN is secure and scoped (if that is really true, it is another story). So there is a value/risk tradeoff here. > For example, assume that two XTRs and an attacker are connected to the global > Internet. The attacker is neither an XTR nor contained by a LISP site. The > attacker is capable of spoofing its sources address. But will the entire path to any destination let him? > The attacker can launch a DoS attack against an XTRs control plan by sending > a barrage of crafted packets to the victim XTR. Each crafted packet cause the > victim XTR to send a verifying MAP-REQUEST to the mapping system. The attack > stream may be so large that it causes the victim XTR to exceed the rate limit > for MAP-REQUEST messages. You can trust sources less if they ARE NOT in the mapping database. That is, if you are a LISP site, you have more tools be verify trust. Dino > > > Ron > > >> -----Original Message----- >> From: Roger Jørgensen [mailto:[email protected]] >> Sent: Wednesday, May 14, 2014 3:59 AM >> To: Ronald Bonica >> Cc: Ross Callon; [email protected] >> Subject: Re: [lisp] Restarting last call on LISP threats >> >> On Tue, May 13, 2014 at 7:31 PM, Ronald Bonica <[email protected]> >> wrote: >>> Hi Roger, >>> >>> Or asked more explicitly, can the level of security claimed by the threats >> document be achieved without implementing the protocol extensions >> described in lisp-sec and lisp-crypto? >> >> I've been pondering on what to answer you since yesterday but think the >> reply from Joel cover it well. However as an addon to Joel and partly reply >> to >> your question, see more inline. >> >> >> On Tue, May 13, 2014 at 11:56 PM, Joel M. Halpern <[email protected]> >> wrote: >>> Ron, I am having trouble with the question. >>> >>> The threats document describes the threats as they exist today, >>> without the adoption of either document that Roger pointed to. Thus, >>> I do not see any dependence. >>> >>> If there is a threat that is not well described in the base spec or >>> this document, then we should add it. We should add it even if there >>> are proposals to remediate it. But if there is a clear proposal of a >>> missing threat, I missed it. >> >> Your question made me question the purpose of the LISP threats draft - >> should it cover potential problem with RFC6830 and include pointers to other >> work that cover them? That will include we'll get a document that will be >> updated over time and is that a good thing? >> >> The other way to look at LISP threats document is to have it as a "review" of >> RFC6830, point out weaknesses and discuss them but with no references to >> other documents. It will be a upstream document that we can refer to from >> like the two draft I mention. >> >> I don't think LISP threat should point to the two draft I mention, but both >> drafts should have a reference to LISP threat since this will be create a >> more >> stable threat document. >> >> >> >> Then Dino mention: >> >> On Tue, May 13, 2014 at 7:47 PM, Dino Farinacci <[email protected]> >> wrote: >> <snip> >>> The main LISP spec (RFC6830) indicates if you want to trust the mapping >> system you can use the gleaned information as soon as you receive it. And if >> you don't trust the mapping system, you can send a "verifying Map-Request" >> to the mapping system which results in a signed Map-Reply returned ala >> draft-ietf-lisp-sec-06. >> >> >> Is this covered in the document? I didn't see it but it's still early here... >> >> >> >> -- >> >> Roger Jorgensen | ROJO9-RIPE >> [email protected] | - IPv6 is The Key! >> http://www.jorgensen.no | [email protected] > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
