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