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
