[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt

Hi Ross, 
 
As you said, the same issue comes up with RSVP. Then, one could wonder why
TSVWG still develops extensions to a protocol that may cause such a harm. 
 
Your comment is interesting since it argues for an architecture that we were
not allowed to work on for many, many years (namely one that is closer to a
bandwidth broker approach) and that actually lead to the "path-coupled"
design of NSIS (following the RSVP model). We had some documents in NSIS
describing how NSIS could be used for  "path-decoupled signaling" with
minimal or no changes. No work was allowed to be done...

You also know that you cannot gain deployment experience in such an
environment when there is no Standards Track document out there.
 
Ciao
Hannes
________________________________

	From: nsis-bounces at ietf.org [mailto:nsis-bounces at ietf.org] On Behalf
Of Ross Callon
	Sent: 12 June, 2009 06:18
	To: Gerald Ash; iesg at ietf.org
	Cc: NSIS
	Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
	
	

	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
	Sent: 09 June 2009 13:19
	To: iesg at ietf.org
	Cc: Martin Stiemerling; Jerry Ash; NSIS
	Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt

	 

		> There is an updated GIST draft that again contains RAO 

	> as interception mechanism 

	 

	1. Can someone from the IESG please explain how GIST can
(eventually) progress from Experimental to PS given that it again uses RAO
as the interception mechanism?  The reversion back to RAO seems ludicrous
given that this was the basis for GIST getting hung up in the IESG to begin
with.  For GIST to emerge from Experimental to PS, the IESG will have to
then accept RAO for PS, which it could not do after all this time.  This is
a Catch 22: It will therefore be impossible for GIST to advance beyond
Experimental to PS.

	 

	2. We're still waiting for the IESG "majority opinion" to be posted,
which supports the overall technical justification for the downgrade, as
request back in April.

	 

	Jerry
	
	--- On Wed, 6/3/09, Martin Stiemerling <Stiemerling at nw.neclab.eu>
wrote:

		
		From: Martin Stiemerling <Stiemerling at nw.neclab.eu>
		Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
		To: "NSIS" <nsis at ietf.org>
		Date: Wednesday, June 3, 2009, 9:07 AM

		Hi all,
		
		There is an updated GIST draft that again contains RAO as
interception mechanism and addresses an issue with the ABNF of the
stack-profile. 
		
		The draft is now categorized as experimental and will go
again to the IESG.
		
		  Martin
		
		> -----Original Message-----
		> From: i-d-announce-bounces at ietf.org
<http://us.mc636.mail.yahoo.com/mc/compose?to=i-d-announce-bounces at ietf.org>
[mailto:i-d-announce-
		> bounces at ietf.org
<http://us.mc636.mail.yahoo.com/mc/compose?to=bounces at ietf.org> ] On Behalf
Of Internet-Drafts at ietf.org
<http://us.mc636.mail.yahoo.com/mc/compose?to=Internet-Drafts at ietf.org> 
		> Sent: Wednesday, June 03, 2009 2:30 PM
		> To: i-d-announce at ietf.org
<http://us.mc636.mail.yahoo.com/mc/compose?to=i-d-announce at ietf.org> 
		> Cc: nsis at ietf.org
<http://us.mc636.mail.yahoo.com/mc/compose?to=nsis at ietf.org> 
		> Subject: I-D Action:draft-ietf-nsis-ntlp-20.txt
		> 
		> A New Internet-Draft is available from the on-line
Internet-Drafts
		> directories.
		> This draft is a work item of the Next Steps in Signaling
Working Group
		> of the IETF.
		> 
		> 
		>     Title           : GIST: General Internet Signalling
Transport
		>     Author(s)       : H. Schulzrinne, M. Stiemerling
		>     Filename        : draft-ietf-nsis-ntlp-20.txt
		>     Pages           : 156
		>     Date            : 2009-06-03
		> 
		> This document specifies protocol stacks for the routing
and transport
		> of per-flow signalling messages along the path taken by
that flow
		> through the network.  The design uses existing transport
and security
		> protocols under a common messaging layer, the General
Internet
		> Signalling Transport (GIST), which provides a common
service for
		> diverse signalling applications.  GIST does not handle
signalling
		> application state itself, but manages its own internal
state and the
		> configuration of the underlying transport and security
protocols to
		> enable the transfer of messages in both directions along
the flow
		> path.  The combination of GIST and the lower layer
transport and
		> security protocols provides a solution for the base
protocol
		> component of the "Next Steps in Signalling" framework.
		> 
		> A URL for this Internet-Draft is:
		>
http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt
		> 
		> Internet-Drafts are also available by anonymous FTP at:
		> ftp://ftp.ietf.org/internet-drafts/
		> 
		> Below is the data which will enable a MIME compliant mail
reader
		> implementation to automatically retrieve the ASCII version
of the
		> Internet-Draft.

		
		-----Inline Attachment Follows-----

		_______________________________________________
		nsis mailing list
		nsis at ietf.org
<http://us.mc636.mail.yahoo.com/mc/compose?to=nsis at ietf.org> 
		https://www.ietf.org/mailman/listinfo/nsis