From root@core3.amsl.com Wed Jun 3 05:30:02 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 35E0928C127; Wed, 3 Jun 2009 05:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090603123002.35E0928C127@core3.amsl.com> Date: Wed, 3 Jun 2009 05:30:02 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 12:30:02 -0000 --NextPart 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. --NextPart Content-Type: Message/External-body; name="draft-ietf-nsis-ntlp-20.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-03051807.I-D@ietf.org> --NextPart-- From Stiemerling@nw.neclab.eu Wed Jun 3 06:07:12 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CFC23A6AC3 for ; Wed, 3 Jun 2009 06:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd0-vIAXikjj for ; Wed, 3 Jun 2009 06:07:11 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 03E303A6929 for ; Wed, 3 Jun 2009 06:07:11 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 4BD852C01D46B for ; Wed, 3 Jun 2009 15:07:12 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP9-mCrwarkV for ; Wed, 3 Jun 2009 15:07:12 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 133E42C0012C1 for ; Wed, 3 Jun 2009 15:07:07 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9E44C.32786361" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 3 Jun 2009 15:07:04 +0200 Message-ID: <547F018265F92642B577B986577D671C97350B@VENUS.office> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-ietf-nsis-ntlp-20.txt Thread-Index: AcnkRz3uihSBRn9jTBmhPel5lzqZ6AABMVDw From: "Martin Stiemerling" To: "NSIS" Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 13:07:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E44C.32786361 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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.=20 The draft is now categorized as experimental and will go again to the = IESG. Martin > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 03, 2009 2:30 PM > To: i-d-announce@ietf.org > Cc: nsis@ietf.org > Subject: I-D Action:draft-ietf-nsis-ntlp-20.txt >=20 > 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. >=20 >=20 > 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 >=20 > 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------_=_NextPart_001_01C9E44C.32786361 Content-Type: application/octet-stream; name="draft-ietf-nsis-ntlp-20.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-nsis-ntlp-20.URL Content-Disposition: attachment; filename="draft-ietf-nsis-ntlp-20.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLW5zaXMtbnRscC0yMC50eHQNCg== ------_=_NextPart_001_01C9E44C.32786361 Content-Type: text/plain; name="ATT3127791.txt" Content-Transfer-Encoding: base64 Content-Description: ATT3127791.txt Content-Disposition: attachment; filename="ATT3127791.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C9E44C.32786361-- From gash5107@yahoo.com Tue Jun 9 10:25:50 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E82F3A6C9B for ; Tue, 9 Jun 2009 10:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcOHBg8oVwzX for ; Tue, 9 Jun 2009 10:25:50 -0700 (PDT) Received: from web63605.mail.re1.yahoo.com (web63605.mail.re1.yahoo.com [69.147.97.75]) by core3.amsl.com (Postfix) with SMTP id 37A663A6C8A for ; Tue, 9 Jun 2009 10:25:50 -0700 (PDT) Received: (qmail 14467 invoked by uid 60001); 9 Jun 2009 17:19:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1244567956; bh=1SNeuKeU//QCf82AV7TlagTnWqR6eUhg89lqaybCokY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=LRJVP7mpm8xol3GEQa15wCHz/09tXdxKbLJ9hRzYIhxSNc+rsR83wA95Dl/DKKoWLlBxYCvFKyeOiAbBaOHTv7xyVzZVVNa6e0tQP7gPq0664ZykTSl6ZJTtKf2MYxcGUL9/pWtf0BhwZMRBHKCB4EMvG0PHs3ly1kWPgOTMZM0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=bfgRodC0x+3HndiufLqXtHjuUNzbGbj1EiJ1p/Z1HQtm3hSdgEHinkRPDPrjeGgfZ77qVREBPQutlhRJRKMJyPFweYbeZ6c1NR7TzgBJiQy1mRkzkfAS4GCJyP6ELJlmFqRFjyoXu0R5DNVIovtDQIvDz5HwY/nARxvv+nTgyQA=; Message-ID: <715993.13688.qm@web63605.mail.re1.yahoo.com> X-YMail-OSG: NnSEfMUVM1lH0QQt77GuZ1zIXt.qQVp_x3hFtaE2HNlsX0mwMcRCRfjV.k7OEePr1.LRBH0RG.GHZEEWFrP8rksFv7_0TjgOXG0eZEqGUBeym0a4IjLp1Xg9JkoxXoWwgZDSxNYOi4Q.qmViZPOwBhuBWTk2Mhn1mfw76nh9Pc0QqwUX8RJv3MM5Vz9xNHkZdHApgteVyA5qt1bpUCn1fbV4P2mu4XXaWEo_vxzQKussTnp90QPQf3OKXkzPftRMI2GcsQ99m_gAze4Sa8FJ.5KtGP_HYxdPbCp1xwm3SGkxSrfiU5LI1Q-- Received: from [24.91.148.40] by web63605.mail.re1.yahoo.com via HTTP; Tue, 09 Jun 2009 10:19:16 PDT X-Mailer: YahooMailClassic/5.3.9 YahooMailWebService/0.7.289.15 Date: Tue, 9 Jun 2009 10:19:16 -0700 (PDT) From: Gerald Ash To: iesg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1507405485-1244567956=:13688" Cc: NSIS Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:25:50 -0000 --0-1507405485-1244567956=:13688 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > There is an updated GIST draft that again contains RAO=20 > as interception mechanism=20 =A0 1. Can someone from the IESG please explain how GIST can (eventually) progr= ess from Experimental to PS given that it=A0again uses RAO as the intercept= ion mechanism?=A0 The reversion back to RAO seems ludicrous given that this= was=A0the basis for GIST getting=A0hung up in the IESG to begin with.=A0 F= or GIST to emerge from Experimental to PS, the IESG will have to then accep= t RAO for PS, which it could not do after all this time.=A0 This is a Catch= 22: It=A0will therefore be impossible for GIST to advance beyond Experimen= tal to PS. =A0 2. We're still=A0waiting for the=A0IESG "majority opinion" to be posted, wh= ich supports=A0the overall=A0technical justification for the downgrade, as= =A0request back in April. =A0 Jerry --- On Wed, 6/3/09, Martin Stiemerling wrote: From: Martin Stiemerling Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt To: "NSIS" Date: Wednesday, June 3, 2009, 9:07 AM Hi all, There is an updated GIST draft that again contains RAO as interception mech= anism and addresses an issue with the ABNF of the stack-profile.=20 The draft is now categorized as experimental and will go again to the IESG. =A0 Martin > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 03, 2009 2:30 PM > To: i-d-announce@ietf.org > Cc: nsis@ietf.org > Subject: I-D Action:draft-ietf-nsis-ntlp-20.txt >=20 > 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. >=20 >=20 > =A0=A0=A0 Title=A0 =A0 =A0 =A0 =A0=A0=A0: GIST: General Internet Signalli= ng Transport > =A0=A0=A0 Author(s)=A0 =A0 =A0=A0=A0: H. Schulzrinne, M. Stiemerling > =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-nsis-ntlp-20.txt > =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0=A0=A0: 156 > =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2009-06-03 >=20 > 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.=A0 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.=A0 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.=A0 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > 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@ietf.org https://www.ietf.org/mailman/listinfo/nsis =0A=0A=0A --0-1507405485-1244567956=:13688 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
=0A=0A --0-1507405485-1244567956=:13688-- From rcallon@juniper.net Thu Jun 11 20:21:30 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944DB3A6A00; Thu, 11 Jun 2009 20:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugoef3wxvcyK; Thu, 11 Jun 2009 20:21:20 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id 182983A6A87; Thu, 11 Jun 2009 20:21:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKSjHJsftkIjIs9hgqEpNJEcE19mmCbWFS@postini.com; Thu, 11 Jun 2009 20:21:28 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 11 Jun 2009 20:17:49 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 11 Jun 2009 23:17:49 -0400 From: Ross Callon To: Gerald Ash , "iesg@ietf.org" Date: Thu, 11 Jun 2009 23:17:47 -0400 Thread-Topic: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt Thread-Index: AcnpJm7/ugt7WV/QQzGf/Ng7xLe8MgB5IW2g Message-ID: References: <715993.13688.qm@web63605.mail.re1.yahoo.com> In-Reply-To: <715993.13688.qm@web63605.mail.re1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_DF7F294AF4153D498141CBEFADB1770498237AE024EMBX01WFjnprn_" MIME-Version: 1.0 Cc: NSIS Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 03:21:30 -0000 --_000_DF7F294AF4153D498141CBEFADB1770498237AE024EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 cont= rol 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 o= ccur, 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, f= or example by discarding these at the CE/PE boundary. Unfortunately the fact that such DDOS attacks are facilitated is not depend= ent upon the method that the router uses to recognize the packets as signal= ing packets. So long as a host has the ability to send traffic to the contr= ol plane of routers, then attackers will be able to harness the power of th= ousands of compromised hosts to attack routers. Of course the same issue could come up with RSVP. It became a standards tra= ck 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 p= rovider. The same issue comes up in terms of DDOS attacks against application server= s. Here one issue is that we don't have an alternative: hosts have to be ab= le to send traffic to servers. Also, in general at least the largest DDOS a= ttacks 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 th= at 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 cont= rol traffic would need to be understood. If the attack came from a very lar= ge 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 pr= otocol is being proposed. It is also possible that a signaling protocol could be used in a sort of "w= alled garden" scenario, where the hosts that are permitted to initiate cont= rol 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 m= ore 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 m= embers) ________________________________ From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Ger= ald Ash Sent: 09 June 2009 13:19 To: iesg@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) progr= ess from Experimental to PS given that it again uses RAO as the interceptio= n 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 wrote: From: Martin Stiemerling Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt To: "NSIS" Date: Wednesday, June 3, 2009, 9:07 AM Hi all, There is an updated GIST draft that again contains RAO as interception mech= anism 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@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 03, 2009 2:30 PM > To: i-d-announce@ietf.org > Cc: nsis@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@ietf.org https://www.ietf.org/mailman/listinfo/nsis --_000_DF7F294AF4153D498141CBEFADB1770498237AE024EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The fundamental problem with GIST is that is allows norm= al 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 atta= cks against the control plane of the routers. Note that such DDOS attacks are n= ot just theory -- in fact multi-gigabit DDOS attacks against routers have occu= rred and do occur, and thus protecting against these is critical. It is therefor= e normal for service providers to prohibit "host to router" signali= ng packets (such as RSVP packets) from entering their network from the custome= r 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 recogn= ize 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 har= ness the power of thousands of compromised hosts to attack routers. <= /span>

 

Of course the same issue could come up with RSVP. It bec= ame a standards track protocol a very long time ago, and would probably face th= e 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 with= in 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: h= osts 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 atta= ck).

 

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 suffici= ent protection to allow hosts in general to signal to the router's control plan= e while still protecting against such attacks. For example control traffic wo= uld 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 legitim= ate 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 l= ow, 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 thi= s would need to be documented. However, the amount of difficulty that would b= e encountered in deploying such a system suggests that this is not an appropr= iate 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 u= sed 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 b= e thought of as one example of such a "walled garden". If deploymen= t experience of NSIS is collected from the experiment and presented with a cl= ear 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 tha= t garden).

 

Ross (speaking for myself, but having discussed the issu= e with other IESG members)

 

From: iesg-bou= nces@ietf.org [mailto:iesg-bounces@ietf.org] On Behal= f Of Gerald Ash
Sent: 09 June 2009 13:19
To: iesg@ietf.org
Cc: Martin Stiemerling; Jerr= y 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 i= nterception mechanism?  The reversion back to RAO seems ludicrous give= n 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 wil= l 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 Exper= imental to PS.
 
2. We're still waiting for the IESG "majority opinion" to be= posted, which supports the overall technical justification for t= he downgrade, as request back in April.
 
Jerry

--- On Wed, 6/3/09, Martin Stiemerling <Stiemerl= ing@nw.neclab.eu> wrote:

From: Martin Stiemerling <Stiemerling@nw.necla= b.eu>
Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
T= o: "NSIS" <nsis@ietf.org>
Date: Wednesday, June 3, 2009, 9:07 AM
Hi all,

There is an updated GIST draft that a= gain contains RAO as interception mechanism and addresses an issue with the= ABNF of the stack-profile.

The draft is now categorized as experim= ental and will go again to the IESG.

  Martin

> -----= Original Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-annou= nce-
> bounces@ietf.org] On = Behalf Of Internet-Dra= fts@ietf.org
> Sent: Wednesday, June 03, 2009 2:30 PM
> To:= i-d-announce@ietf.org
>= Cc: nsis@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.
> Th= is draft is a work item of the Next Steps in Signaling Working Group
>= ; of the IETF.
>
>
>     Title  &nb= sp;        : GIST: General Internet Signalling Tra= nsport
>     Author(s)       = : H. Schulzrinne, M. Stiemerling
>     Filename  =       : draft-ietf-nsis-ntlp-20.txt
>   &nbs= p; Pages           : 156
>  &= nbsp;  Date            : 2009-06-03
>
> This document specifies protocol stacks for th= e routing and transport
> of per-flow signalling messages along the p= ath taken by that flow
> through the network.  The design uses e= xisting transport and security
> protocols under a common messaging l= ayer, the General Internet
> Signalling Transport (GIST), which provi= des a common service for
> diverse signalling applications.  GIS= T does not handle signalling
> application state itself, but manages = its own internal state and the
> configuration of the underlying tran= sport 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 sol= ution for the base protocol
> component of the "Next Steps in Signall= ing" framework.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iet= f-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
> im= plementation to automatically retrieve the ASCII version of the
> Int= ernet-Draft.

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

_______________________________________________
n= sis mailing list
nsis@ietf.org
https:/= /www.ietf.org/mailman/listinfo/nsis

> There is an updated GIST draft that again contains RAO

> as interception mechanism

 

1. Can someone from the IESG please explain ho= w GIST can (eventually) progress from Experimental to PS given that it agai= n uses RAO as the interception mechanism?  The reversion back to RAO s= eems ludicrous given that this was the basis for GIST getting hung u= p 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 advanc= e 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 b= ack in April.

 

Jerry

--- On Wed, 6/3/09, Martin Stiemerlin= g <Stiemerling@nw.neclab.eu> wrote:


From: Martin Stiemerling <Stiemerling@nw.neclab.eu>
Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
To: "NSIS" <nsis@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 IES= G.

  Martin

> -----Original Message-----
> From: i-d-announce-bounces@iet= f.org [mailto:i-d-announce-
> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org<= br> > Sent: Wednesday, June 03, 2009 2:30 PM
> To: i-d-announce@ietf.org
> Cc: nsis@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 Gro= up
> of the IETF.
>
>
>     Title          &nbs= p;: GIST: General Internet Signalling Transport
>     Author(s)       : H. Schulzrinne, M. Stiemerling
>     Filename        : draft-ietf-nsis-ntlp-20.txt
>     Pages          &nbs= p;: 156
>     Date            : 2009-06-03
>
> This document specifies protocol stacks for the routing and transpor= t
> 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 signalli= ng
> application state itself, but manages its own internal state and the=
> configuration of the underlying transport and security protocols to<= br> > enable the transfer of messages in both directions along the flow > path.  The combination of GIST and the lower layer transport an= d
> 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-ntl= p-20.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ft= p://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@ietf.org
= https://www.ietf.org/mailman/listinfo/nsis

 

--_000_DF7F294AF4153D498141CBEFADB1770498237AE024EMBX01WFjnprn_-- From Hannes.Tschofenig@gmx.net Thu Jun 11 22:50:24 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AA53A688F for ; Thu, 11 Jun 2009 22:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD4FdD+JDH0L for ; Thu, 11 Jun 2009 22:50:19 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E3A2F3A63CB for ; Thu, 11 Jun 2009 22:50:18 -0700 (PDT) Received: (qmail invoked by alias); 12 Jun 2009 05:50:25 -0000 Received: from unknown (EHLO 4FIL42860) [192.100.123.77] by mail.gmx.net (mp038) with SMTP; 12 Jun 2009 07:50:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+zQAoutLGz0Ek0Ta1yv8XRqowKT0BPdZixMR4is3 eMbe36WzEMmD/W From: "Hannes Tschofenig" To: "'Ross Callon'" , "'Gerald Ash'" , References: <715993.13688.qm@web63605.mail.re1.yahoo.com> Date: Fri, 12 Jun 2009 08:52:22 +0300 Message-ID: <051f01c9eb21$f57b33b0$035aa20a@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnpJm7/ugt7WV/QQzGf/Ng7xLe8MgB5IW2gAAU70OA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6899999999999999 Cc: 'NSIS' Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 05:50:24 -0000 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@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Ross Callon Sent: 12 June, 2009 06:18 To: Gerald Ash; iesg@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@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Gerald Ash Sent: 09 June 2009 13:19 To: iesg@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 wrote: From: Martin Stiemerling Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt To: "NSIS" 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@ietf.org [mailto:i-d-announce- > bounces@ietf.org ] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 03, 2009 2:30 PM > To: i-d-announce@ietf.org > Cc: nsis@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@ietf.org https://www.ietf.org/mailman/listinfo/nsis From gash5107@yahoo.com Tue Jun 16 08:20:05 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E656628C17B for ; Tue, 16 Jun 2009 08:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXYP3Zs8+99Q for ; Tue, 16 Jun 2009 08:20:05 -0700 (PDT) Received: from web63604.mail.re1.yahoo.com (web63604.mail.re1.yahoo.com [69.147.97.74]) by core3.amsl.com (Postfix) with SMTP id 6CB763A695F for ; Tue, 16 Jun 2009 08:20:05 -0700 (PDT) Received: (qmail 43500 invoked by uid 60001); 16 Jun 2009 15:16:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1245165368; bh=Mb3taCAdyuG9nyqwAAyZrt5sB9e9puCv+PNMRIhZj0c=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=MF7SJZnGEGzCpRNT7UzEnfcCCAqukAJBKLkfR9zGrGrLbG6WbrofmbijBueVLJ2YOVi9HcPUG1G+im3xHcgca2ro9/MXmR6s0sEZP6rP7/9ly0QTygGxJD9F/SzHbfYt4HJxdk45frLDXKWVGjIxoU39zwJRWhzEx441M3v/yS4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=dBVphBN7ljmiPmFwVlN1Voh/JTIa1CSTdYY2lQor2GZvdzo2D+nngh7VAu0A4KY8gn2y1Al3eZ9n7qWFhwXhn4WHdh11lCCo/9kJs08uZpg5Tml355to/FPKM8XFpbWteQLpb2rboRXSQcxvugK7ssCMIMwKANuTXUf/nqdPTpw=; Message-ID: <729855.43489.qm@web63604.mail.re1.yahoo.com> X-YMail-OSG: SL7KSkgVM1k0mye_ccj3LxPYlz2npheuLbtqR11RtKIa3QEcKRuYlog1J_Lil6ZrjxoSgfCeT7D3Ubyla7rj6KkCSLZTZ4KZ33qyb13wrZumSaEIyTpXSCaXXmQsXOm91TNrMc7HRjoG0Cj61soMIMGV9UecvAWl3qMo_LDkMCUOk6UTfmMAaKU_CNUiwidzh_lQMYUIB_eOFk8WK_laRB1gCwzBsZN.flFiE0cnJiyhQEgrUzsWg2HnBp6s.Lxf651vrDsSNUQ44unjQpp7BhaiHtyAZ7VzXTji_C7zCk0mMxijUvxJgPnVjjK5SWxtT_XjCZLHS2fr50HzHA-- Received: from [24.91.148.40] by web63604.mail.re1.yahoo.com via HTTP; Tue, 16 Jun 2009 08:16:08 PDT X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15 Date: Tue, 16 Jun 2009 08:16:08 -0700 (PDT) From: Gerald Ash To: "iesg@ietf.org" , Ross Callon MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-578401930-1245165368=:43489" Cc: NSIS Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:20:06 -0000 --0-578401930-1245165368=:43489 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Ross. =C2=A0 I understand the point regarding DDOS vulnerability of the control plane=C2= =A0and the difficulty (unlikelihood due to cost/complexity)=C2=A0of protect= ing against that.=C2=A0=20 =C2=A0 However, it seems that this is a generic comment about any signaling protoc= ol, not just GIST.=C2=A0 If so, it would seem impossible to ever satisfy th= e NSIS charter.=C2=A0 Is that right, there is no acceptable GIST solution (= RAO, 5-tuple/magic, ...) that would fulfill the NSIS charter?=C2=A0 And if = that's the case, then it would have been better to have these comments 8 ye= ars ago and save all the work on NSIS. =C2=A0 It=C2=A0sounds like=C2=A0an NSIS=C2=A0"experiment" in "walled gardens"=C2= =A0is the only alternative to progress to PS (after which the restriction= =C2=A0of deploying NSIS only in=C2=A0"walled gardens" is still in effect)?= =C2=A0 Why is an experiment necessary=C2=A0if=C2=A0NSIS=C2=A0must always be= =C2=A0restricted to "walled gardens".=C2=A0 Why not go=C2=A0directly to PS = with a "walled garden" restriction (I think as Adrian suggested in his DISC= USS comments)?=C2=A0=C2=A0 =C2=A0 Jerry --- On Thu, 6/11/09, Ross Callon wrote: From: Ross Callon Subject: RE: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt To: "Gerald Ash" , "iesg@ietf.org" Cc: "Martin Stiemerling" , "NSIS" Date: Thursday, June 11, 2009, 11:17 PM The fundamental problem with GIST is that is allows normal hosts (laptops, = desktops, =E2=80=A6) 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 th= e control plane of the routers. Note that such DDOS attacks are not just th= eory -- in fact multi-gigabit DDOS attacks against routers have occurred an= d 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 netwo= rks, for example by discarding these at the CE/PE boundary. =C2=A0 Unfortunately the fact that such DDOS attacks are facilitated is not depend= ent upon the method that the router uses to recognize the packets as signal= ing packets. So long as a host has the ability to send traffic to the contr= ol plane of routers, then attackers will be able to harness the power of th= ousands of compromised hosts to attack routers.=20 =C2=A0 Of course the same issue could come up with RSVP. It became a standards tra= ck 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 p= rovider.=20 =C2=A0 The same issue comes up in terms of DDOS attacks against application server= s. Here one issue is that we don't have an alternative: hosts have to be ab= le to send traffic to servers. Also, in general at least the largest DDOS a= ttacks 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).=20 =C2=A0 In terms of the right want to deal with such DOS attacks: The reality is th= at 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 cont= rol traffic would need to be understood. If the attack came from a very lar= ge 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 signa= ling protocol is being proposed.=20 =C2=A0 It is also possible that a signaling protocol could be used in a sort of "w= alled garden" scenario, where the hosts that are permitted to initiate cont= rol 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 m= ore likely to be progressed to standards track (with the description of how= and why the deployment is limited to that garden). =C2=A0 Ross (speaking for myself, but having discussed the issue with other IESG m= embers) =C2=A0 From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Ger= ald Ash Sent: 09 June 2009 13:19 To: iesg@ietf.org Cc: Martin Stiemerling; Jerry Ash; NSIS Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt =C2=A0 > There is an updated GIST draft that again contains RAO=20 > as interception mechanism=20 =C2=A0 1. Can someone from the IESG please explain how GIST can (eventually) progr= ess from Experimental to PS given that it=C2=A0again uses RAO as the interc= eption mechanism?=C2=A0 The reversion back to RAO seems ludicrous given tha= t this was=C2=A0the basis for GIST getting=C2=A0hung up in the IESG to begi= n with.=C2=A0 For GIST to emerge from Experimental to PS, the IESG will hav= e to then accept RAO for PS, which it could not do after all this time.=C2= =A0 This is a Catch 22: It=C2=A0will therefore be impossible for GIST to ad= vance beyond Experimental to PS. =C2=A0 2. We're still=C2=A0waiting for the=C2=A0IESG "majority opinion" to be post= ed, which supports=C2=A0the overall=C2=A0technical justification for the do= wngrade, as=C2=A0request back in April. =C2=A0 Jerry --- On Wed, 6/3/09, Martin Stiemerling wrote: From: Martin Stiemerling Subject: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt To: "NSIS" Date: Wednesday, June 3, 2009, 9:07 AM Hi all, There is an updated GIST draft that again contains RAO as interception mech= anism and addresses an issue with the ABNF of the stack-profile.=20 The draft is now categorized as experimental and will go again to the IESG. =C2=A0 Martin > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Wednesday, June 03, 2009 2:30 PM > To: i-d-announce@ietf.org > Cc: nsis@ietf.org > Subject: I-D Action:draft-ietf-nsis-ntlp-20.txt >=20 > 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. >=20 >=20 > =C2=A0=C2=A0=C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0: G= IST: General Internet Signalling Transport > =C2=A0=C2=A0=C2=A0 Author(s)=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0: H. Schulzri= nne, M. Stiemerling > =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-nsis-= ntlp-20.txt > =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0: 1= 56 > =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2009-0= 6-03 >=20 > 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.=C2=A0 The design uses existing transport and securit= y > protocols under a common messaging layer, the General Internet > Signalling Transport (GIST), which provides a common service for > diverse signalling applications.=C2=A0 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.=C2=A0 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nsis-ntlp-20.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > 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@ietf.org https://www.ietf.org/mailman/listinfo/nsis =C2=A0=0A=0A=0A --0-578401930-1245165368=:43489 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= /tr>
Thanks Ross.
 
I understand the point regarding DDOS vulnerability of the control pla= ne and the difficulty (unlikelihood due to cost/complexity) of pr= otecting against that. 
 
However, it seems that this is a generic comment about any signaling p= rotocol, not just GIST= .  If so, it would seem impossible to ever satisfy the NSIS charter.&n= bsp; Is that right, there is no acceptable GIST solution (RAO, 5-tuple/magi= c, ...) 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 restrictio= n 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 DISC= USS comments)?  
 
Jerry

--- On Thu, 6/11/09, Ross Callon <r= callon@juniper.net> wrote:

From: Ross Callon <rcallon@juniper.net>
= Subject: RE: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt
To: "Gera= ld Ash" <gash5107@yahoo.com>, "iesg@ietf.org" <iesg@ietf.org>Cc: "Martin Stiemerling" <Stiemerling@nw.neclab.eu>, "NSIS" <nsi= s@ietf.org>
Date: Thursday, June 11, 2009, 11:17 PM

The fundamental problem with GIST is that is allo= ws normal hosts (laptops, desktops, =E2=80=A6) to send traffic to the contr= ol 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 DD= OS attacks are not just theory -- in fact multi-gigabit DDOS attacks agains= t 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 netwo= rk 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 recog= nize 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. <= /SPAN>

 

Of course the same issue could come up with RSVP.= It became a standards track protocol a very long time ago, and would proba= bly 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 altern= ative: hosts have to be able to send traffic to servers. Also, in general a= t least the largest DDOS attacks against servers need to be dealt with by p= utting appropriate packet filters / rate limits in place in routers (assumi= ng that the router network is operating, and wasn't taken down by a differe= nt 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 deplo= y sufficient protection to allow hosts in general to signal to the router's= control plane while still protecting against such attacks. For example con= trol traffic would need to be rate limited at pretty much every entry to ev= ery major service provider network, and the effect that any DDOS attack wou= ld have on legitimate control traffic would need to be understood. If the a= ttack 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 li= mits would need to also be very low, or they would need to be adjusted in r= esponse 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 standa= rds track unless and until there is clear and well documented motivation fo= r whatever new signaling protocol is being proposed.

 

It is also possible that a signaling protocol cou= ld 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 comp= romise. The current use of RSVP within some enterprise networks could be th= ought of as one example of such a "walled garden". If deployment experience= of NSIS is collected from the experiment and presented with a clear defini= tion 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 (w= ith the description of how and why the deployment is limited to that garden= ).

 

Ross (speaking for myself, but having discussed t= he issue with other IESG members)

 

From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of Gerald Ash
Sent: 09 June 2009 13:19
To: iesg@ietf.org
Cc: Martin Stiemerling; Jerry Ash; NSIS
= Subject: Re: [NSIS] FW: I-D Ac= tion:draft-ietf-nsis-ntlp-20.txt

 

> There is an updated GIST draft that again contains R= AO

> 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 l= udicrous given that this was the basis for GIST getting hung up i= n 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 GI= ST to advance beyond Experimental to PS.

 

2. We're still waiting for the IESG "majority o= pinion" to be posted, which supports the overall technical justif= ication for the downgrade, as request back in April.

 

Jerry

--- On = Wed, 6/3/09, Martin Stiemerling <S= tiemerling@nw.neclab.eu> wrote:


From: Martin Stiemerlin= g <Stiemerling@nw.neclab.eu>
Subject: [NSIS] FW: I-D Action:draft-= ietf-nsis-ntlp-20.txt
To: "NSIS" <nsis@ietf.org>
Date: Wednesda= y, 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

> -----Origi= nal Message-----
> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-
> bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
> Sent: Wednesday,= June 03, 2009 2:30 PM
> To: i-d-announce@ietf.org
> Cc: nsis@ietf.org
> Subject: I-D Action:d= raft-ietf-nsis-ntlp-20.txt
>
> A New Internet-Draft is availab= le 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    &nbs= p;      : GIST: General Internet Signalling Transport>     Author(s)       : H. Sch= ulzrinne, M. Stiemerling
>     Filename    &= nbsp;   : draft-ietf-nsis-ntlp-20.txt
>     Pages=            : 156
>   &nb= sp; 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
&= gt; through the network.  The design uses existing transport and secur= ity
> protocols under a common messaging layer, the General Internet<= BR>> Signalling Transport (GIST), which provides a common service for> diverse signalling applications.  GIST does not handle signallin= g
> application state itself, but manages its own internal state and = the
> configuration of the underlying transport and security protocol= s to
> enable the transfer of messages in both directions along the f= low
> path.  The combination of GIST and the lower layer transpo= rt 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/
&= gt;
> Below is the data which will enable a MIME compliant mail read= er
> implementation to automatically retrieve the ASCII version of th= e
> Internet-Draft.


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

_______________________________________________
nsis m= ailing list
nsis@ietf.org
https://www.ietf.org/mailman/listinfo/nsis

 


=0A=0A --0-578401930-1245165368=:43489-- From root@core3.amsl.com Tue Jun 23 22:00:02 2009 Return-Path: X-Original-To: nsis@ietf.org Delivered-To: nsis@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D33A13A6869; Tue, 23 Jun 2009 22:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090624050002.D33A13A6869@core3.amsl.com> Date: Tue, 23 Jun 2009 22:00:02 -0700 (PDT) Cc: nsis@ietf.org Subject: [NSIS] I-D Action:draft-ietf-nsis-tunnel-06.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 05:00:02 -0000 --NextPart 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 : NSIS Operation Over IP Tunnels Author(s) : C. Shen, et al. Filename : draft-ietf-nsis-tunnel-06.txt Pages : 22 Date : 2009-06-23 This draft presents an NSIS operation over IP tunnel scheme using QoS NSLP as the NSIS signaling application. Both sender-initiated and receiver-initiated NSIS signaling modes are discussed. The scheme creates individual or aggregate tunnel sessions for end-to-end sessions traversing the tunnel. Packets belonging to qualified end- to-end sessions are mapped to corresponding tunnel sessions and assigned special flow IDs to be distinguished from the rest of the tunnel traffic. Tunnel endpoints keep the association of the end-to- end and tunnel session mapping, so that adjustment in one session can be reflected in the other. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-tunnel-06.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. --NextPart Content-Type: Message/External-body; name="draft-ietf-nsis-tunnel-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-23214647.I-D@ietf.org> --NextPart-- From jmanner@cs.Helsinki.FI Thu Jun 25 22:52:20 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFDE13A6910 for ; Thu, 25 Jun 2009 22:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXq4ga72aOfZ for ; Thu, 25 Jun 2009 22:52:19 -0700 (PDT) Received: from mail.cs.helsinki.fi (courier.cs.helsinki.fi [128.214.9.1]) by core3.amsl.com (Postfix) with ESMTP id B9CF53A67DF for ; Thu, 25 Jun 2009 22:52:19 -0700 (PDT) Received: from melkki.cs.helsinki.fi (melkki.cs.helsinki.fi [128.214.9.98]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Fri, 26 Jun 2009 08:52:08 +0300 id 00063DD0.4A446208.00003C1B Date: Fri, 26 Jun 2009 08:52:08 +0300 (EEST) From: Jukka MJ Manner To: NSIS Working Group Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [NSIS] Working Group Last Call for NTLP State Machine X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 05:52:20 -0000 Dear all, I don't seem to find a WGLC on the State machine, thus I'll issue a two-week WGLC starting today and ends on Friday July 10th. There are at least a few ID nits to be handled - consider this as my own WGLC review. http://tools.ietf.org/wg/nsis/draft-ietf-nsis-ntlp-statemachine/ Regards, Jukka From magnus.westerlund@ericsson.com Fri Jun 26 07:59:38 2009 Return-Path: X-Original-To: nsis@core3.amsl.com Delivered-To: nsis@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C793A67DF; Fri, 26 Jun 2009 07:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdra4-VfgIIP; Fri, 26 Jun 2009 07:59:38 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5D9A33A677D; Fri, 26 Jun 2009 07:59:37 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-7a-4a44e238190a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 08.35.21241.832E44A4; Fri, 26 Jun 2009 16:59:04 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 16:59:03 +0200 Received: from [153.88.49.16] ([153.88.49.16]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 16:59:02 +0200 Message-ID: <4A44E232.3050201@ericsson.com> Date: Fri, 26 Jun 2009 16:58:58 +0200 From: Magnus Westerlund User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Gerald Ash References: <729855.43489.qm@web63604.mail.re1.yahoo.com> In-Reply-To: <729855.43489.qm@web63604.mail.re1.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Jun 2009 14:59:02.0393 (UTC) FILETIME=[A4873690:01C9F66E] X-Brightmail-Tracker: AAAAAA== Cc: Ross Callon , "iesg@ietf.org" , NSIS Subject: Re: [NSIS] FW: I-D Action:draft-ietf-nsis-ntlp-20.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:59:38 -0000 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: magnus.westerlund@ericsson.com ----------------------------------------------------------------------