Every host on the Internet is subject to a DoS attack. An xTR is no more so.
I am also not clear on how a DoS attack on an xTR would create any more risk
than an attack directly against the mapping system.
Joel describes Ronald's scenario of an attack where a large stream of packets
with different inner source addresses to an ETR. I don't call this an attack.
I call this our steady-state. These would be the PxTR's we operate across the
US. The PxTR's on the beta-network are no different. We take in packets from
anywhere. This is a "Free" attacker if you will. All that really means is
that you do not have to incur the computational cost of encapsulating the
packet.
I would defer to Dino and others on the list, but I do not believe that the ETR
does a reverse lookup on every packet. At least that is not the behavior we
observe. What we see happen is that the packet is decapsulated and sent to the
destination. If a valid destination host responds, then the ITR does a
map-request for the reply packet. There is not a 1:1 relationship between the
number of packets and the number of map-requests.
Map-replies for IP addresses return prefixes. These prefixes can cover larger
address spaces than the map-request and limit the number of future map-requests
needed.
Can you provide more specific details on how you see the xTR rendering the
mapping system unusable?
For what its worth, I still support the decision for last call and not to place
mitigations within the document. Without knowing the specifics of a
configuration and implementation, that just leads to a false sense of security.
________________________________________
From: lisp [[email protected]] on behalf of Ronald Bonica
[[email protected]]
Sent: Monday, May 26, 2014 11:57 AM
To: Joel M. Halpern; Damien Saucez
Cc: Roger Jorgensen; LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats
Inline.....
> -----Original Message-----
> From: Joel M. Halpern [mailto:[email protected]]
> Sent: Monday, May 26, 2014 11:47 AM
> To: Ronald Bonica; Damien Saucez
> Cc: Roger Jorgensen; LISP mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
>
> 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.
[RPB]
Exactly!
>
> It targeting an ITR, this would need to be from within ths cope the ITR
> serves.
[RPB]
I don't understand this sentence. Please try again.
> I believe that is discussed.
[RPB]
Given that I don't understand the sentence above, I have no idea if this
sentence is true.
>
> 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.
[RPB]
Exactly!
>
> 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.
[RPB]
Even if there are effective mitigations, the attack should be described.
However, I am not convinced that an effective mitigation exists.
> There are clealry a number of variations on this attack.
[RPB]
True!
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.
[RPB]
Yes, both should be described.
Also, recall that large BCP38 holes exist in today's internet.
>
> Have I captured your request accurately?
[RPB]
Pretty much.
Thanks for taking the effort.
Ron
>
> 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
