Hi Sharon,
We may be talking about an XTR that is sick due to a bug or attack. We may also
be talking about an attacker that isn't an XTR at all, just impersonating one.
Ron
> -----Original Message-----
> From: Sharon [mailto:[email protected]]
> Sent: Monday, May 26, 2014 12:06 PM
> To: Joel M. Halpern
> Cc: Ronald Bonica; Damien Saucez; Roger Jorgensen; LISP mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
>
> Joel, thanks for clearing.
> It was hard to follow.
>
> If the challenge is for a distributed mapping system to keep track and protect
> itself from a "sick" xTR, sick because of a bug or an attack..
> Then perhaps we could maintain mapping lookup per sec counters per xTR in
> the mapping. It adds some overhead to the mapping, but doesn't slow down
> forwarding. Can be aggregated by map servers for efficiency.
>
> --szb
>
> On May 26, 2014, at 8:46 AM, "Joel M. Halpern" <[email protected]>
> wrote:
>
> Top posting to make sure I am understanding:
>
> You asssert that any xTR is subject to a DoS attack. And that such a DoS
> attack can render the mapping system unusable.
>
> It targeting an ITR, this would need to be from within ths cope the ITR
> serves.
> I believe that is discussed.
>
> If I have connected the dots correctly, the attack you are contemplating is
> sending a large stream of packets with different inner source addresses to an
> ETR. This would prompt the ETR to check with the mapping system about
> each and every address.
>
> If I have understood this properly, while there are several very effective
> mitigations, that does not change the basic message that this is an attack,
> and
> as such ought to be described in the threats document. There are clealry a
> number of variations on this attack. For example, using the same outer
> source address makes mitigation easier, while using different outer source
> addresses either requires a bot-net or a large unchecked BCP38 hole (and
> those can be used for MANY attacks on many systems.) Both presumably
> should be described.
>
> Have I captured your request accurately?
>
> Yours,
> Joel
>
> > On 5/26/14, 1:06 AM, Ronald Bonica wrote:
> > *From:*Damien Saucez [mailto:[email protected]]
> > *Sent:* Friday, May 23, 2014 9:07 AM
> > *To:* Ronald Bonica
> > *Cc:* Dino Farinacci; Roger Jorgensen; LISP mailing list list
> > *Subject:* Re: [lisp] Restarting last call on LISP threats
> >
> > Hello Ronald,
> >
> > On 22 May 2014, at 22:57, Ronald Bonica <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >
> >
> > Dino,
> >
> > Today's Internet is not as fragile as you think. This mail traversed
> > many routers between my house and yours. If those routers are
> > well-managed, there is nothing that I can do from my house that will
> > cause any of those routers to consume control plane resources.
> > Therefore, there is nothing that I can do from my house that will
> > cause a DoS attack against those routers' control planes.
> >
> > We tend to disagree with that, for example you have ICMP today...
> >
> > */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn’t make a
> > very good routing protocol. That’s why we don’t use it for routing. By
> > contrast, LISP map-request messages are susceptible to DoS attacks and
> > they do carry routing information./*
> >
> >
> >
> > In LISP, separation between the forwarding and control plane is
> > lost. As a matter of course, forwarding plane activity causes
> > control plane activity. Since forwarding plane bandwidth exceeds
> > control plane bandwidth, DoS attacks against the control plane are
> > possible.
> >
> > In order to be complete, the threats document must describe the DoS
> > threat. It should also describe mitigations, if any exist.
> >
> > DoS is already explained and the definition given:
> >
> > " A Denial of Service (DoS) attack aims at disrupting a specific
> >
> > targeted service either by exhausting the resources of the victim
> > up
> >
> > to the point that it is not able to provide a reliable service to
> >
> > legit traffic and/or systems or by exploiting vulnerabilities to
> > make
> >
> > the targeted service unable to operate properly.
> >
> > "
> >
> > is covering the case you mention.
> >
> > */[RPB] /*
> >
> > */You might want to add the following details to section 5.2:/*
> >
> > *//*
> >
> > -A DoS attack can be launched by anybody who can send a packet to the
> > XTR’s LOC
> >
> > -DoS attacks can render an XTR inoperable
> >
> > -DDoS attacks can render the mapping system inoperable.
> >
> > This is what differentiates LISP from today’s routing system.
> >
> > Ron
> >
> > Damien Saucez
> >
> >
> >
> >
> > Ron
> >
> >
> >
> > -----Original Message-----
> > From: Dino Farinacci [mailto:[email protected]]
> > Sent: Wednesday, May 21, 2014 6:58 PM
> > To: Ronald Bonica
> > Cc: Roger Jorgensen; [email protected] <mailto:[email protected]>
> > Subject: Re: [lisp] Restarting last call on LISP threats
> >
> >
> > The attacker sends a flow of crafted packets to the victim
> > XTR. Each packet
> >
> > is a well-formed LISP data packet. It contains:
> >
> >
> > - an outer IP header (LOC->LOC)
> > - a UDP header
> > - a LISP Header
> > - an IP header (EID->EID)
> > - payload
> >
> >
> > Just like a regular packet I can send to your home router today.
> > So yes okay.
> > So let's continue. See comments below.
> >
> >
> > Each packet contains control plane information that is new
> > to the victim
> >
> >
> > Be more specific about what control information are in these
> > encapsulated
> > packets.
> >
> >
> > XTR. For example, the victim XTR has no mapping information
> > regarding
> >
> > either the source LOC or source EID prefix. Rather than gleaning
> > this mapping
> > information from the crafted packet, the victim XTR sends a
> > verifying MAP-
> > REQUEST to the mapping system.
> >
> >
> > Assume that the attack flow is large (N packets per second).
> > Assume also
> >
> > that the XTRs rate limit for MAP-REQUEST messages is less than N
> > packets
> > per second. Has the attack not effectively DoS'd the victim XTR?
> >
> > It caches the rate the rate the packets are coming in and
> > eventually stops
> > sending Map-Requests completely.
> >
> > It cannot stop the incoming rate of packets today just like a
> > roque BGP
> > attacker can send millions of packets per second to a peer
> > regardless if it
> > does or does not have the peer authentication key.
> >
> >
> > To make this attack work, every packet in the attack flow
> > may need to have
> >
> > a unique, spoofed, source LOC.
> >
> > An implementation can detect that after rate limiting 1000s of
> > such requests
> > are happening that it just stops operation.
> >
> > What if I sent a Juniper 20 million routes today?
> >
> > The Internet is very fragile and LISP IS NOT making it worse.
> > And in some
> > cases it is making it better with integrated techniques.
> >
> > Dino
> >
> >
> > _______________________________________________
> > lisp mailing list
> > [email protected] <mailto:[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
