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

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

Thanks Ross.
 
I understand the point regarding DDOS vulnerability of the control plane and the difficulty (unlikelihood due to cost/complexity) of protecting against that.  
 
However, it seems that this is a generic comment about any signaling protocol, not just GIST.  If so, it would seem impossible to ever satisfy the NSIS charter.  Is that right, there is no acceptable GIST solution (RAO, 5-tuple/magic, ...) that would fulfill the NSIS charter?  And if that's the case, then it would have been better to have these comments 8 years ago and save all the work on NSIS.
 
It sounds like an NSIS "experiment" in "walled gardens" is the only alternative to progress to PS (after which the restriction of deploying NSIS only in "walled gardens" is still in effect)?  Why is an experiment necessary if NSIS must always be restricted to "walled gardens".  Why not go directly to PS with a "walled garden" restriction (I think as Adrian suggested in his DISCUSS comments)?  
 
Jerry

--- On Thu, 6/11/09, Ross Callon <[email-masked]> wrote:

From: Ross Callon <[email-masked]>
Subject: RE: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
To: "Gerald Ash" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "Martin Stiemerling" <[email-masked]>, "NSIS" <[email-masked]>
Date: Thursday, June 11, 2009, 11:17 PM

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

> 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: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Jun 2009 16:58:58 +0200

Hi Jerry,

I am back from my a short parental leave and would like to provide my view.

Gerald Ash skrev:
> Thanks Ross.
>  
> I understand the point regarding DDOS vulnerability of the control
> plane and the difficulty (unlikelihood due to cost/complexity) of
> protecting against that. 

Well, I do hope that better control plane protection can be implemented
in the future.

>  
> However, it seems that this is a generic comment about any signaling
> protocol, not just GIST.  If so, it would seem impossible to ever
> satisfy the NSIS charter.  Is that right, there is no acceptable GIST
> solution (RAO, 5-tuple/magic, ...) that would fulfill the NSIS charter? 
> And if that's the case, then it would have been better to have these
> comments 8 years ago and save all the work on NSIS.

Yes, I can only concur that it would have been better if this comment
had been raised back then. Now, it wasn't and we have spent 3 years
debating this.

>  
> It sounds like an NSIS "experiment" in "walled gardens" is the only
> alternative to progress to PS (after which the restriction of deploying
> NSIS only in "walled gardens" is still in effect)?  Why is an experiment
> necessary if NSIS must always be restricted to "walled gardens".  Why
> not go directly to PS with a "walled garden" restriction (I think as
> Adrian suggested in his DISCUSS comments)?  

We tried but there was a number of ADs that thought that proposed
standard was not acceptable and forced me to take the decision to
downgrade it to experimental. I don't see delaying publication any
longer bickering around this is any better.

I can see it going to PS with a limited applicability statement as soon
as one have some new deployment data in a walled garden showing that it
works in that environment.

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------