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

From: Gerald Ash <[email-masked]>
Date: Tue, 9 Jun 2009 10:19:16 -0700 (PDT)

> 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 <[email-masked]> wrote:

From: Martin Stiemerling <[email-masked]>
Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
To: "NSIS" <[email-masked]>
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: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, June 03, 2009 2:30 PM
> To: [email-masked]
> Cc: [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/nsis

---

From: Ross Callon <[email-masked]>
Date: Thu, 11 Jun 2009 23:17:47 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of Gerald Ash
Sent: 09 June 2009 13:19
To: [email-masked]
Cc: Martin Stiemerling; Jerry Ash; NSIS
Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt

Jerry

  Martin

> From: [email-masked]<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> [mailto:i-d-announce-
> [email-masked]<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>] On Behalf Of [email-masked]<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
> To: [email-masked]<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
> Cc: [email-masked]<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>

-----Inline Attachment Follows-----
_______________________________________________
nsis mailing list
[email-masked]<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
https://www.ietf.org/mailman/listinfo/nsis

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 12 Jun 2009 08:52:22 +0300

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ross Callon
	Sent: 12 June, 2009 06:18
	To: Gerald Ash; [email-masked]
	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: [email-masked] [mailto:[email-masked]]
On Behalf Of Gerald Ash
	Sent: 09 June 2009 13:19
	To: [email-masked]
	Cc: Martin Stiemerling; Jerry Ash; NSIS
	Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt

	> 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 <[email-masked]>
wrote:

		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
		
		> From: [email-masked]
<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]>
[mailto:i-d-announce-
		> [email-masked]
<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> ] On Behalf
Of [email-masked]
<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> 
		> To: [email-masked]
<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> 
		> Cc: [email-masked]
<http://us.mc636.mail.yahoo.com/mc/compose?to=[email-masked]> 

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

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