|
The fundamental problem with GIST is that is allows normal
hosts (laptops, desktops, …) to send traffic to the control plane of
routers. This opens up a new vector for hosts to be the source of DDOS attacks
against the control plane of the routers. Note that such DDOS attacks are not
just theory -- in fact multi-gigabit DDOS attacks against routers have occurred
and do occur, and thus protecting against these is critical. It is therefore
normal for service providers to prohibit "host to router" signaling
packets (such as RSVP packets) from entering their network from the customer
networks, for example by discarding these at the CE/PE boundary. Unfortunately the fact that such DDOS attacks are
facilitated is not dependent upon the method that the router uses to recognize
the packets as signaling packets. So long as a host has the ability to send
traffic to the control plane of routers, then attackers will be able to harness
the power of thousands of compromised hosts to attack routers. Of course the same issue could come up with RSVP. It became
a standards track protocol a very long time ago, and would probably face the
same scrutiny if it were a new protocol being proposed today. The current
widespread use of RSVP is generally in ISPs limited to support of MPLS within a
service provider. The same issue comes up in terms of DDOS attacks against
application servers. Here one issue is that we don't have an alternative: hosts
have to be able to send traffic to servers. Also, in general at least the
largest DDOS attacks against servers need to be dealt with by putting
appropriate packet filters / rate limits in place in routers (assuming that the
router network is operating, and wasn't taken down by a different DDOS attack).
In terms of the right want to deal with such DOS attacks:
The reality is that it would be quite a major undertaking to deploy sufficient
protection to allow hosts in general to signal to the router's control plane
while still protecting against such attacks. For example control traffic would
need to be rate limited at pretty much every entry to every major service
provider network, and the effect that any DDOS attack would have on legitimate
control traffic would need to be understood. If the attack came from a very
large number of sources, then the rate at each entry point might be quite low,
implying that either the widely deployed rate limits would need to also be very
low, or they would need to be adjusted in response to an attack. All of this
would need to be documented. However, the amount of difficulty that would be
encountered in deploying such a system suggests that this is not an appropriate
thing to put into the IETF standards track unless and until there is clear and
well documented motivation for whatever new signaling protocol is being
proposed. It is also possible that a signaling protocol could be used
in a sort of "walled garden" scenario, where the hosts that are
permitted to initiate control traffic are known and are protected from
compromise. The current use of RSVP within some enterprise networks could be
thought of as one example of such a "walled garden". If deployment
experience of NSIS is collected from the experiment and presented with a clear
definition of the walled garden within which the protocol can be safely
operated, then this work might be more likely to be progressed to standards
track (with the description of how and why the deployment is limited to that
garden). Ross (speaking for myself, but having discussed the issue
with other IESG members) From: iesg-bounces at ietf.org
[mailto:iesg-bounces at ietf.org] On Behalf Of Gerald
Ash
|