From nsis-bounces@ietf.org Mon May 01 11:05:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaZxa-0007gl-V7; Mon, 01 May 2006 11:05:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaZxZ-0007gg-PC for nsis@ietf.org; Mon, 01 May 2006 11:05:13 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaZxY-0006Yq-AV for nsis@ietf.org; Mon, 01 May 2006 11:05:13 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Mon, 01 May 2006 18:05:08 +0300 id 000700CA.445623A4.00004D61 Date: Mon, 1 May 2006 18:05:08 +0300 (EEST) From: Jukka MJ Manner To: Hannes Tschofenig Subject: Re: [NSIS] Some questions about the NAT/FW NSLP In-Reply-To: <44550491.3040004@gmx.net> Message-ID: References: <44550491.3040004@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, see below On Sun, 30 Apr 2006, Hannes Tschofenig wrote: > Hi Jukka, > > a short feedback: > > Jukka MJ Manner wrote: > > Hi, > > > > while reviewing the NAT NSLP, several questions emerged: > > > > A. Does proxy mode for DS (3.8.7.1) work if you have more than one inbound > > route? A multihomed NF. > > Yes, It works if the edge device is a NAT. With a firewall there might be a > problem if the DS does not send an NSIS message. The edge-firewalls would have > to use a firewall synchronization protocol. We noted this issue in the > appendix of the draft. [JM]: Which NAT or FW do you send the messages? If you have several routes, and each route has its own NAT and/or FW, then how can you signal the right one? E.g. get a NAT binding for the NAT that actually will be receiving your inbound traffic. > > > > > B. Should the TOS byte be also available as a field for matching traffic? > > I still remember your old issue > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46. > > I personally would like to see it as an extension because I want to finish the > document and it is, in some sense, an extension to the base protocol from a > functionality point of view. [JM]: I see this as network resource protection: you want to be sure no one is trying to get an unfair treatment for his traffic. > > > > > C. Should there be a rule for modifying a packet? Now we "allow" or > > "deny", but about also "modify"? > > What is the scenario? I guess you are talking about a "rewrite" DSCP value or > something along these lines. [JM]: Yes, rewrite of the DSCP value. Still, you can also do it for the TTL. > > > > > D. Should there be a "log" action to store information about certain > > packet flows? > Not in the base protocol. There are several problems with it and it some sense > that's what the Meeting NSLP does. If you read the M-NSLP draft then you will > notice the types of problems you suddenly have to deal with. [JM]: Haven't read it for a while, I'll check that when I get the spare time. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 01 16:31:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faf3F-0003e3-OP; Mon, 01 May 2006 16:31:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faf3E-0003dy-Qt for nsis@ietf.org; Mon, 01 May 2006 16:31:24 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Faf3D-00040R-CN for nsis@ietf.org; Mon, 01 May 2006 16:31:24 -0400 Received: (qmail invoked by alias); 01 May 2006 20:31:21 -0000 Received: from p54987F77.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.127.119] by mail.gmx.net (mp042) with SMTP; 01 May 2006 22:31:21 +0200 X-Authenticated: #29516787 Message-ID: <44567016.9040408@gmx.net> Date: Mon, 01 May 2006 16:31:18 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jukka MJ Manner Subject: Re: [NSIS] Some questions about the NAT/FW NSLP References: <44550491.3040004@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka, please find my response below: Jukka MJ Manner wrote: > Hi Hannes, > see below > > On Sun, 30 Apr 2006, Hannes Tschofenig wrote: > > >>Hi Jukka, >> >>a short feedback: >> >>Jukka MJ Manner wrote: >> >>>Hi, >>> >>>while reviewing the NAT NSLP, several questions emerged: >>> >>>A. Does proxy mode for DS (3.8.7.1) work if you have more than one inbound >>> route? A multihomed NF. >> >>Yes, It works if the edge device is a NAT. With a firewall there might be a >>problem if the DS does not send an NSIS message. The edge-firewalls would have >>to use a firewall synchronization protocol. We noted this issue in the >>appendix of the draft. > > > > [JM]: Which NAT or FW do you send the messages? If you have several > routes, and each route has its own NAT and/or FW, then how can you signal > the right one? E.g. get a NAT binding for the NAT that actually will be > receiving your inbound traffic. The message is sent towards an "opportunistic address". The message just needs to reach the edge-NAT/edge-Firewall and there it is not forwarded further. It is necessary to differentiate between REA and REA-Proxy. REA just enables NSIS signaling messages to traverse the edge device and to give the end host a contact information (i.e., a publically reachable IP address) -- in case of a NAT. REA-Proxy does more since it also initiates a CREATE message exchange downstream if the DS does not support NSIS (or might not support NSIS). If there are multiple firewalls between the edge device and the DR then either the CREATE message triggered by the DS or the CREATE message triggered by the edge-NAT/edge-Firewall will establish the packet filter rules. Does this help? > > >>>B. Should the TOS byte be also available as a field for matching traffic? >> >>I still remember your old issue >>https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46. >> >>I personally would like to see it as an extension because I want to finish the >>document and it is, in some sense, an extension to the base protocol from a >>functionality point of view. > > > [JM]: I see this as network resource protection: you want to be sure no > one is trying to get an unfair treatment for his traffic. > I also see it as a useful feature but we shouldn't dump everything in the base protocol. > > >>>C. Should there be a rule for modifying a packet? Now we "allow" or >>> "deny", but about also "modify"? >> >>What is the scenario? I guess you are talking about a "rewrite" DSCP value or >>something along these lines. > > > [JM]: Yes, rewrite of the DSCP value. Still, you can also do it for the > TTL. Could you elaborate your TTL rewrite scenario a little bit further? > > >>>D. Should there be a "log" action to store information about certain >>>packet flows? >> >>Not in the base protocol. There are several problems with it and it some sense >>that's what the Meeting NSLP does. If you read the M-NSLP draft then you will >>notice the types of problems you suddenly have to deal with. > > > [JM]: Haven't read it for a while, I'll check that when I get the spare > time. > > > Jukka Ciao Hannes > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 01 22:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fal4E-0000lI-1D; Mon, 01 May 2006 22:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fal4D-0000lA-Kl; Mon, 01 May 2006 22:56:49 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fal4C-0002w7-6L; Mon, 01 May 2006 22:56:49 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k422uk2j029742; Tue, 2 May 2006 05:56:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 05:56:46 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 05:56:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 05:56:45 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB40766C@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Meeting Survey Thread-Index: AcZtM1sYPortiF/kR6uLPlMsAqmacgAYIF1w From: To: , , X-OriginalArrivalTime: 02 May 2006 02:56:45.0586 (UTC) FILETIME=[0C50FF20:01C66D94] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [NSIS] FW: IETF Meeting Survey X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Please take the time and fill out the survey below. This will help us run the IETF meetings more effectively, and ensure that your requirements are heard. thanks, John >-----Original Message----- >From: ext Ray Pelletier [mailto:rpelletier@isoc.org]=20 >Sent: 01 May, 2006 18:25 >To: wgchairs@ietf.org >Subject: IETF Meeting Survey > >All; >It has been suggested that if I really wanted to get feedback=20 >on the Meeting Survey (and I do) I should have it forwarded=20 >by the WG Chairs to the working groups - so this is a request=20 >that you ask members of the working groups to complete a short=20 >survey that focuses primarily, but not exclusively, on their=20 >meeting experience in Dallas.=20 > >I truly want the info to make the changes members of the=20 >community want, if possible and greatly appreciate your=20 >assistance in this regard. > >Those interested in taking the survey can find it at: >http://www.surveymonkey.com/s.asp?u=3D649182049947 > >Thanks >Ray Pelletier >IETF Admininstrative Director > > > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 02:59:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faoqu-0006Om-0w; Tue, 02 May 2006 02:59:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faoqs-0006Og-82 for nsis@ietf.org; Tue, 02 May 2006 02:59:18 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faoqq-0003Ew-Ka for nsis@ietf.org; Tue, 02 May 2006 02:59:18 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 2 May 2006 08:59:11 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 2 May 2006 08:59:11 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20E6312@S4DE8PSAAFQ.mitte.t-com.de> From: "Geib, Ruediger" To: jmanner@cs.Helsinki.FI Subject: RE: [NSIS] Proxy mode for QoS NSLP? Date: Tue, 2 May 2006 08:59:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hello Jukka, I support your proposal to allow for a QoS NSLP proxy mode. Regards, Rudiger |Since the NAT/FW NSLP provides a so-called "proxy mode" for supporting |non-NSIS correspondent nodes, should the QoS NSLP also have |this feature? | |In the NF work, the local edge NAT/FW may be the "problem", |and if the CN does not "talk NSIS", we still need to |get e.g. holes open on the edge firewall. Similarly, for |QoS the local network may be the bottleneck, and without |support from the CN, we would still like to have QoS at |least locally. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 04:10:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FapxR-0001TT-83; Tue, 02 May 2006 04:10:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FapxP-0001TO-HT for nsis@ietf.org; Tue, 02 May 2006 04:10:07 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FapxO-0005dP-0o for nsis@ietf.org; Tue, 02 May 2006 04:10:07 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 02 May 2006 11:10:04 +0300 id 0007014B.445713DC.00005E7E Date: Tue, 2 May 2006 11:10:00 +0300 (EEST) From: Jukka MJ Manner To: Hannes Tschofenig Subject: Re: [NSIS] Some questions about the NAT/FW NSLP In-Reply-To: <44567016.9040408@gmx.net> Message-ID: References: <44550491.3040004@gmx.net> <44567016.9040408@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Two comments below: On Mon, 1 May 2006, Hannes Tschofenig wrote: > Hi Jukka, > > please find my response below: > > Jukka MJ Manner wrote: > > Hi Hannes, see below > > > > On Sun, 30 Apr 2006, Hannes Tschofenig wrote: > > > > > > > Hi Jukka, > > > > > > a short feedback: > > > > > > Jukka MJ Manner wrote: > > > > > > > Hi, > > > > > > > > while reviewing the NAT NSLP, several questions emerged: > > > > > > > > A. Does proxy mode for DS (3.8.7.1) work if you have more than one > > > > inbound > > > > route? A multihomed NF. > > > > > > Yes, It works if the edge device is a NAT. With a firewall there might be > > > a > > > problem if the DS does not send an NSIS message. The edge-firewalls would > > > have > > > to use a firewall synchronization protocol. We noted this issue in the > > > appendix of the draft. > > > > > > > > [JM]: Which NAT or FW do you send the messages? If you have several routes, > > and each route has its own NAT and/or FW, then how can you signal the right > > one? E.g. get a NAT binding for the NAT that actually will be receiving your > > inbound traffic. > > The message is sent towards an "opportunistic address". The message just needs > to reach the edge-NAT/edge-Firewall and there it is not forwarded further. > > It is necessary to differentiate between REA and REA-Proxy. REA just enables > NSIS signaling messages to traverse the edge device and to give the end host a > contact information (i.e., a publically reachable IP address) -- in case of a > NAT. > > REA-Proxy does more since it also initiates a CREATE message exchange > downstream if the DS does not support NSIS (or might not support NSIS). > > If there are multiple firewalls between the edge device and the DR then either > the CREATE message triggered by the DS or the CREATE message triggered by the > edge-NAT/edge-Firewall will establish the packet filter rules. > > Does this help? [JM]: My point is, what is this "opportunistic address"? How do you know where is/are your NAT/FW device(s)? If you have several NAT/FWs, does GIST provide a way to send to multiple destinations? > > > > > > > > B. Should the TOS byte be also available as a field for matching > > > > traffic? > > > > > > I still remember your old issue > > > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46. > > > > > > I personally would like to see it as an extension because I want to finish > > > the > > > document and it is, in some sense, an extension to the base protocol from > > > a > > > functionality point of view. > > > > > > [JM]: I see this as network resource protection: you want to be sure no one > > is trying to get an unfair treatment for his traffic. > > > > I also see it as a useful feature but we shouldn't dump everything in the base > protocol. > > > > > > > > > C. Should there be a rule for modifying a packet? Now we "allow" or > > > > "deny", but about also "modify"? > > > > > > What is the scenario? I guess you are talking about a "rewrite" DSCP value > > > or > > > something along these lines. > > > > > > [JM]: Yes, rewrite of the DSCP value. Still, you can also do it for the TTL. > > Could you elaborate your TTL rewrite scenario a little bit further? [JM]: Well, you can modify the TTL value in order to prohibit, e.g., traceroute-type of behavior on both directions. Of course this could be a default behavior, which could be hard coded, too. > > > > > > > > > D. Should there be a "log" action to store information about certain > > > > packet flows? > > > > > > Not in the base protocol. There are several problems with it and it some > > > sense > > > that's what the Meeting NSLP does. If you read the M-NSLP draft then you > > > will > > > notice the types of problems you suddenly have to deal with. > > > > > > [JM]: Haven't read it for a while, I'll check that when I get the spare > > time. Jukka _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 07:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fasvj-0001j6-Eo; Tue, 02 May 2006 07:20:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fasvh-0001iy-HQ; Tue, 02 May 2006 07:20:33 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fasvg-0005z9-32; Tue, 02 May 2006 07:20:33 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k42BKTnc030806; Tue, 2 May 2006 14:20:31 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 14:20:11 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 14:20:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 14:20:11 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB407688@esebe100.NOE.Nokia.com> In-Reply-To: <44567016.9040408@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for a review of the "NAT/Firewall NSIS Signaling Layer Protocol (NSLP) " Thread-Index: AcZtXpAo4ZqImHbcQjOAYQJ4vNANNQAeuKiw From: To: , X-OriginalArrivalTime: 02 May 2006 11:20:11.0209 (UTC) FILETIME=[60454B90:01C66DDA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nsis@ietf.org Subject: [NSIS] Request for a review of the "NAT/Firewall NSIS Signaling Layer Protocol (NSLP) " X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, Currently, the NSIS working group is finalizing the "NAT/Firewall NSIS Signaling=20 Layer Protocol (NSLP)" for signaling middleboxes. The current document can be found here: http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt NSIS is working on a path-coupled signaling protocol, to signal nodes along the data patch. As both NAT and Firewalls are along the data path, NSIS signaling is developing a protocol for allow end nodes to signal these boxes. As both BEHAVE and MIDCOM have been working on related issues, I'd like to encourage people to read the document and send comments and questions to the mailing list - nsis@ietf.org. As long as your subject lines are clearly marked, I'll enable posting rights so that you don't have to join the NSIS mailing list. Additionally, please try not to cross-post discussion on the other mailing lists; unless the BEHAVE & MIDCOM chairs feel that cross-posting would be beneficial. thanks, John=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 07:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fat7S-0001T7-SD; Tue, 02 May 2006 07:32:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fat7R-0001OW-Fm for nsis@ietf.org; Tue, 02 May 2006 07:32:41 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fat7P-0006gU-Rx for nsis@ietf.org; Tue, 02 May 2006 07:32:41 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k42BWNlS015006; Tue, 2 May 2006 13:32:23 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k42BWNZM027352; Tue, 2 May 2006 13:32:23 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 13:32:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Some questions about the NAT/FW NSLP Date: Tue, 2 May 2006 13:29:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Some questions about the NAT/FW NSLP Thread-Index: AcZtwBWChzy+elJVThS1DZ/fBZc3fQAGIBIw From: "Tschofenig, Hannes" To: "Jukka MJ Manner" , "Hannes Tschofenig" X-OriginalArrivalTime: 02 May 2006 11:32:22.0845 (UTC) FILETIME=[145C16D0:01C66DDC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jukka,=20 please find some comments below:=20 > Hi, >=20 > Two comments below: >=20 > On Mon, 1 May 2006, Hannes Tschofenig wrote: >=20 > > Hi Jukka, > >=20 > > please find my response below: > >=20 > > Jukka MJ Manner wrote: > > > Hi Hannes, see below > > >=20 > > > On Sun, 30 Apr 2006, Hannes Tschofenig wrote: > > >=20 > > >=20 > > > > Hi Jukka, > > > >=20 > > > > a short feedback: > > > >=20 > > > > Jukka MJ Manner wrote: > > > >=20 > > > > > Hi, > > > > >=20 > > > > > while reviewing the NAT NSLP, several questions emerged: > > > > >=20 > > > > > A. Does proxy mode for DS (3.8.7.1) work if you have=20 > more than one > > > > > inbound > > > > > route? A multihomed NF. > > > >=20 > > > > Yes, It works if the edge device is a NAT. With a=20 > firewall there might be > > > > a > > > > problem if the DS does not send an NSIS message. The=20 > edge-firewalls would > > > > have > > > > to use a firewall synchronization protocol. We noted=20 > this issue in the > > > > appendix of the draft. > > >=20 > > >=20 > > >=20 > > > [JM]: Which NAT or FW do you send the messages? If you=20 > have several routes, > > > and each route has its own NAT and/or FW, then how can=20 > you signal the right > > > one? E.g. get a NAT binding for the NAT that actually=20 > will be receiving your > > > inbound traffic. > >=20 > > The message is sent towards an "opportunistic address". The=20 > message just needs > > to reach the edge-NAT/edge-Firewall and there it is not=20 > forwarded further. > >=20 > > It is necessary to differentiate between REA and REA-Proxy.=20 > REA just enables > > NSIS signaling messages to traverse the edge device and to=20 > give the end host a > > contact information (i.e., a publically reachable IP=20 > address) -- in case of a > > NAT. > >=20 > > REA-Proxy does more since it also initiates a CREATE=20 > message exchange > > downstream if the DS does not support NSIS (or might not=20 > support NSIS). > >=20 > > If there are multiple firewalls between the edge device and=20 > the DR then either > > the CREATE message triggered by the DS or the CREATE=20 > message triggered by the > > edge-NAT/edge-Firewall will establish the packet filter rules. > >=20 > > Does this help? >=20 > [JM]: My point is, what is this "opportunistic address"? How=20 > do you know > where is/are your NAT/FW device(s)? If you have several=20 > NAT/FWs, does GIST > provide a way to send to multiple destinations? Ok. Let me provide a longer answer to your question.=20 The main problem we want to address is end-to-end connectivity. This is something all future Internet architecture proposals worry about in some way or the other and they provide different solutions as well. Let us pick more solid and more traditional proposals: * STUN/TURN These proposals assume that the STUN / TURN server is in the public address space.=20 * Hi3 A DHT is located in the public address space and end hosts need to register their triggers (sort of contact information) into these Hi3 nodes.=20 * Mobile IP The Home Agent is in the public address space with the home address as the globally reachable IP address. * HIP RVS The address of the rendezvous server (RVS) is stored in the DNS server and is publically reachable. The end host registers its host identity in the RVS.=20 We make the assumption that the opportunistic address is an publically reachable IP address but do not specify further where this address comes from since the message should, in the normal case, never reach the interface behind this address. As such, we are not that far away from other protocol proposals.=20 When this REA message (that is sent to such an opportunistic address) reaches the edge-NAT then a NAT binding is created the contact address is returned to the end host. As such, inbound traffic WILL hit this NAT since that's the address that will be advertised with an application layer protocol. With a firewall the situation is different since there will be no guarantee that the traffic will actually traverse the firewall, if the network is multi-homed and state synchronization is not used. In this case the problem is only problematic if the DS does not initiate a CREATE message towards the DR. > > >=20 > > >=20 > > > > > B. Should the TOS byte be also available as a field=20 > for matching > > > > > traffic? > > > >=20 > > > > I still remember your old issue > > > > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46. > > > >=20 > > > > I personally would like to see it as an extension=20 > because I want to finish > > > > the > > > > document and it is, in some sense, an extension to the=20 > base protocol from > > > > a > > > > functionality point of view. > > >=20 > > >=20 > > > [JM]: I see this as network resource protection: you want=20 > to be sure no one > > > is trying to get an unfair treatment for his traffic. > > >=20 > >=20 > > I also see it as a useful feature but we shouldn't dump=20 > everything in the base > > protocol. > >=20 > > >=20 > > >=20 > > > > > C. Should there be a rule for modifying a packet? Now=20 > we "allow" or > > > > > "deny", but about also "modify"? > > > >=20 > > > > What is the scenario? I guess you are talking about a=20 > "rewrite" DSCP value > > > > or > > > > something along these lines. > > >=20 > > >=20 > > > [JM]: Yes, rewrite of the DSCP value. Still, you can also=20 > do it for the TTL. > >=20 > > Could you elaborate your TTL rewrite scenario a little bit further? >=20 > [JM]: Well, you can modify the TTL value in order to prohibit, e.g.,=20 > traceroute-type of behavior on both directions. Of course=20 > this could be a=20 > default behavior, which could be hard coded, too. We provide this functionality with the combination of "ICMP Types Object" and the "Extended Flow Information Object".=20 Nothing else is needed from this point of view.=20 > >=20 > > >=20 > > >=20 > > > > > D. Should there be a "log" action to store=20 > information about certain > > > > > packet flows? > > > >=20 > > > > Not in the base protocol. There are several problems=20 > with it and it some > > > > sense > > > > that's what the Meeting NSLP does. If you read the=20 > M-NSLP draft then you > > > > will > > > > notice the types of problems you suddenly have to deal with. > > >=20 > > >=20 > > > [JM]: Haven't read it for a while, I'll check that when I=20 > get the spare > > > time. >=20 >=20 > Jukka Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 08:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fatmg-0004Fz-4O; Tue, 02 May 2006 08:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fatmf-0004Ft-4B for nsis@ietf.org; Tue, 02 May 2006 08:15:17 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fatmd-0008Ka-LS for nsis@ietf.org; Tue, 02 May 2006 08:15:17 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k42CERZX023599; Tue, 2 May 2006 13:14:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Proxy mode for QoS NSLP? Date: Tue, 2 May 2006 13:14:15 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Proxy mode for QoS NSLP? Thread-Index: AcZq8Q09+P+SFg8bRWWSOrwOXzmlMgC8MUHw From: "Hancock, Robert" To: "Jukka MJ Manner" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org i certainly think this would be useful and not a great deal of work for the qos-nslp specification itself. see also the first comment in http://www1.ietf.org/mail-archive/web/nsis/current/msg06095.html cheers, r. > -----Original Message----- > From: Jukka MJ Manner [mailto:jmanner@cs.Helsinki.FI]=20 > Sent: 28 April 2006 19:25 > To: nsis@ietf.org > Subject: [NSIS] Proxy mode for QoS NSLP? >=20 >=20 >=20 > Hi, >=20 > Since the NAT/FW NSLP provides a so-called "proxy mode" for=20 > supporting=20 > non-NSIS correspondent nodes, should the QoS NSLP also have=20 > this feature?=20 >=20 > In the NF work, the local edge NAT/FW may be the "problem",=20 > and if the CN > does not "talk NSIS", we still need to get e.g. holes open on the edge > firewall. Similarly, for QoS the local network may be the=20 > bottleneck, and > without support from the CN, we would still like to have QoS at least=20 > locally. >=20 > Jukka >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 09:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faur5-0004DT-8G; Tue, 02 May 2006 09:23:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Faur3-0004DO-FT for nsis@ietf.org; Tue, 02 May 2006 09:23:53 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Faur2-00038c-MY for nsis@ietf.org; Tue, 02 May 2006 09:23:53 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k42DNe02002111 for ; Tue, 2 May 2006 14:23:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 14:23:31 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NATFW protocol/specification structure issues Thread-Index: AcZt66LL2X0uCChRRtKJrWdF2v1dRw== From: "Hancock, Robert" To: X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Subject: [NSIS] NATFW protocol/specification structure issues X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all, while reading the NATFW spec, i was continually tripped over by a number of partly editorial/partly structural issues, which made it quite hard for me to get to grips with the protocol in a concrete way. basically it seems to me that there is a good *) high level description of what problem space the protocol attempts to address and the design approach which has been taken *) low level description of how individual messages are processed at particular nodes but it's hard to understand the protocol structure at an intermediate level - in particular, how different messages depend on each other or have to be processed consistently, or under what circumstances messages can be processed totally independently. (i think this becomes most visible in the discussion of REA-like messages that might create firewall state, which everyone seems to find a bit confusing. it also shows up in other ways - for example, which messages control which state, how SIDs are=20 allocated, and so on.) the very start of the spec talks about there being two 'modes' but it doesn't really say what is the significance of a particular mode being used (i.e. what the 'mode' concept really means). the document also talks about 'signalling exchanges' at several points but doesn't really talk about what the boundaries of such exchanges are. [you can think of this as a comment on section 3.2. 3.2.3 describes session lifecycles quite nicely, but the definition of a session itself is not given there. in other places, the session definition seems to be tied to the concept of application sessions, but I'm sure this isn't valid in reality. For example, using a REA session as part of speculatively registering an external address might not correspond to any specific application session, whereas another call flow might use both a REA messaging and CREATE messaging - is this actually one session or two?] i also find the NI/NI+/NR/NR+/DR/DS terminology confusing. (for example, sometimes the term 'NSIS initiator' refers to the NI+ (see for example the top of p41.) i also find the CREATE/REA terminology confusing as mentioned by others, especially since the spec refers to 'request'=20 messages without saying explicitly what they are (so far as I could see). the following is my attempt to impose such an intermediate level=20 structure on the protocol. it would be interesting to know if it was correct: *) the NATFW NSLP uses signalling sessions to manage state at middleboxes=20 *) all the messages for a given session have the same SID and MRM/MRI [modulo upstream/downstream setting]. the SIDs for different sessions are un-related. *) a session has a specific lifetime, which is negotiated by all the nodes taking part in the session at session creation, and can be updated during session refresh *) a session is iniated with a 'request' message (there are two types). The node at one end of the path which sends the first request is called the NSIS initiator (NI). *) a node at the other end of the path terminates the signalling and replies to the request with a RESPONSE message. It is called the NSIS responder (NR). *) all the other nodes are called forwarders (NFs). *) for the first type of session, the request is called CREATE and the PC-MRM is used *) for the second type of session, the request is called REA and the LE-MRM is used. [I know this isn't consistent with 3.8.2; however, there are bits of 3.8.2 which I don't see how they could work in the first place.] *) the NSLP state data is independent between different sessions. [Actually I am fairly sure this is wrong. However, I cannot work out what the dependencies are!] Clearly this doesn't capture all the details. What I'm not sure about is whether it is consistent with all the details for proxy mode etc. (However, if I find inconsistencies, at least it pins down which of the details I don't understand properly yet.)=20 In particular, it doesn't mention DS/DR issues directly. As I see it, DS/DR show up because either - it's easy to have the first session type where NI=3DDS (but this is an artifact of GIST behaviour, not fundamental to the NSLP design), but you can try NI=3DDR - you have have NI=3DDR for the second session type, because the case NI=3DDS is pointless. And so on... I'll try to write up my more specific points in the near future. If any of them don't make sense, at least what's written above may clarify where my fundamental misunderstandings are. cheers, r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 02 11:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FawkD-0005tY-PA; Tue, 02 May 2006 11:24:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FawkC-0005tT-IA for nsis@ietf.org; Tue, 02 May 2006 11:24:56 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FawkB-00007K-01 for nsis@ietf.org; Tue, 02 May 2006 11:24:56 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k42FOjM5023754 for ; Tue, 2 May 2006 16:24:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 16:24:44 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on the handling of RESPONSE/TRACE/NOTIFY messages Thread-Index: AcZt/IsemmnrQTMuTeuS5ibSDC9aBQ== From: "Hancock, Robert" To: X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [NSIS] comments on the handling of RESPONSE/TRACE/NOTIFY messages X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, these comments are most inspired by a reading of sections 4.3.3/4/5 (additional cross references added where appropriate): i think all of these messages need slightly clearer specification about what MRM is used and what direction they can be sent in. i assume that in reality all of these messages have to be sent using the same MRM as the session was created with (by CREATE or REA message). otherwise there is no guarantee that the routing state to forward them exists. (note that the routing state is keyed by MRM, so you cannot leave it unspecified.) [this affects at least 4.3.5. I assume here that the TRACE does not create a new session but traces an existing one.] also, I don't think the terminology 'upstream/downstream' is useful here, since flows may not even exist yet (what do these terms mean if you are sending a NOTIFY about a REA?) should the direction=20 just be described as 'towards NI' rather than 'upstream'? But in fact - is it clear that you can only NOTIFY in one direction? - why are you only allowed to TRACE from the session owner? I note (4.2.8) that the TRACE object can only hold one type of IP address. How would this function in a mixed v4/6 environment using NAT-PT? (is this an error condition?) Also, which IP address is actually inserted - outgoing interface or incoming interface of the message? There are some oddities in the processing of RESPONSE messages. In 3.2.2 ("Classification of RESPONSE Messages") it says that 'Informational' is normally only used with NOTIFY messages. Does this mean that a RESPONSE can be sent in response to a NOTIFY? The scenario at the end of page 29 implies that a RESPONSE can be generated as a result of a RESPONSE, but doesn't say which direction this second RESPONSE is sent in; 3.2.1 says that RESPONSE messages are only caused by CREATE/REA/NOTIFY. r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 03 04:48:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbD1r-0002To-4P; Wed, 03 May 2006 04:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbD1o-0002Tj-V1 for nsis@ietf.org; Wed, 03 May 2006 04:48:12 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbD1n-0004Ao-Fq for nsis@ietf.org; Wed, 03 May 2006 04:48:12 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k438ltC3010612; Wed, 3 May 2006 09:48:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] Scoping Date: Wed, 3 May 2006 09:47:11 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Scoping Thread-Index: AcZshbL9+AXKZCuMTBCNiX+TfhKgugCCCkXg From: "Hancock, Robert" To: "Hannes Tschofenig" , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi i certainly got confused about the 'NSLP common header' text. i don't think there's anything common about the headers of NSLP messages. (the object registry is the shared part, so there are some aspects of the message format that are common.) i have no views on the scoping questions :-) r. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 30 April 2006 19:41 > To: nsis@ietf.org > Subject: [NSIS] Scoping >=20 >=20 > Hi all, >=20 > here is a comment regarding the CREATE message scoping > (relevant for the QoS NSLP and the NATFW NSLP). >=20 > Section 5.1.1. of=20 > http://www.ietf.org/internet-drafts/draft-ietf-nsis-qos-nslp-10.txt=20 > defines the 'Common header' and defines a 16-bit generic flags field.=20 > The 'S' flag is one of the defined flags: > " > SCOPING (S) - when set, indicates that the message is=20 > scoped and > should not travel down the entire path but only as far=20 > as the next > QNE (scope=3D"next hop"). By default, this flag is not=20 > set (default > scope=3D"whole path"). > " >=20 > Interestingly, the QoS NSLP folks haven't defined anything=20 > that would be=20 > similar to the scoping we do. I wonder what the reason is. At=20 > the moment=20 > I don't see how the two approaches could be harmonized -- this might=20 > turn out to be a problem later when we decide to run the QoS NSLP and=20 > the NATFW NSLP together (one might, for example, remember the=20 > discussion=20 > we had with Jukka about DSCP rewriting: see > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue46) >=20 > A comment regarding the 'P' flag in the Common NSLP header=20 > that refers=20 > to the proxy support for the REATE-PROXY and REA-PROXY=20 > message. Section=20 > 3.8.7 defines it. >=20 > The flag is introduced into the Common NSLP header, which is, as its=20 > name indicates, common to all NSLPs. I think that this name=20 > is, however,=20 > wrong (or the description) since it is only common for all NATFW NSLP=20 > messages. >=20 > I therefore suggest to change the text from: >=20 > " > 4.1 NSLP Header >=20 > The NSLP header is common to all NSLPs and is the first=20 > part of all > NSLP messages. > " >=20 > to: >=20 > " > 4.1 NSLP Header >=20 > All GIST NSLP-Data objects for the NATFW NSLP MUST contain this Common > Header as the first 32 bits of the object (this is not the same as > the GIST Common Header). > " >=20 > Is my observation correct or do I miss something here? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 03 05:00:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDDd-0005CY-On; Wed, 03 May 2006 05:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbDDc-0005CT-7f for nsis@ietf.org; Wed, 03 May 2006 05:00:24 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbDDb-0004gN-Pm for nsis@ietf.org; Wed, 03 May 2006 05:00:24 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k43906Ab012093; Wed, 3 May 2006 10:00:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs Date: Wed, 3 May 2006 09:59:40 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP; attack in Section 5.10.1 is not specific to NATs Thread-Index: AcZshkEtNIygHnaQRSGJqtOwz7GbNACB/Jrg From: "Hancock, Robert" To: "Hannes Tschofenig" , "Ali Fessi" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: 30 April 2006 19:45 > To: Ali Fessi > Cc: Hancock, Robert; nsis > Subject: Re: [NSIS] NATFW NSLP; attack in Section 5.10.1 is=20 > not specific to NATs >=20 >=20 > Hi Ali, >=20 > there is no big motivation behind the mentioned scenario. It=20 > is just an=20 > end host behind a NAT that moves around and uses the NATFW=20 > NSLP protocol=20 > for NAT and Firewall signaling. This end host needs to update its NAT=20 > binding to continue to receive the data traffic at the new=20 > care-of-address. >=20 > For some reason you got jumped to mobility protocols. possibly the use of terms like 'care-of-address' (and the section=20 title "Misuse of mobility in NAT handling) provided that hint :-) there are two issues: - the description of the scenario in terms of an address change behind the NAT is confusing - but in any case, the fact that the address is changing looks like it is irrelevant. all we care about is that one node should not be able to signal on behalf of another under these circumstances. r. >=20 > We, however, need to ensure that the text does not give you a wrong=20 > impression. >=20 > Ciao > Hannes >=20 >=20 > Ali Fessi wrote: > > Hi again, > >=20 > > Ali Fessi wrote: > >=20 > >> Hi Robert, > >> > >> Hancock, Robert wrote: > >> > >>> hi, > >>> > >>> [this is not really a follow up to Ali's question but another > >>> issue on 5.10:] > >>> > >>> I found at least the introduction of the scenario in 5.10=20 > a little=20 > >>> difficult to follow from a motivational point of view. > >>> How common is it for IP layer mobility to be used purely on the=20 > >>> private side of a NAT? (I'm not saying that it's impossible, > >>> just that I tend to think of NATs as reducing the need for > >>> renumbering in small networks, where you wouldn't use IP > >>> mobility in the first place.) > >> > >> > >> > >> i'm not an expert in mobility; but i think, if Hierarchical MIP is=20 > >> used, then the HMIP anchor point would basically behaves=20 > as a NAT. So=20 > >> the scenario described in this section would fit well to HMIP. > >> > >> Maybe someone else can provide a better explanation?! > >=20 > >=20 > > i've just thought about it a bit more. > >=20 > > the setup with HMIP is similar; but with HMIP there is no=20 > need for NSIS=20 > > NATFW NSLP. Instead, Mobile Nodes send their Mobile IP=20 > "Binding Updates"=20 > > straightforward to the HMIP anchor point. > >=20 > > So, the motivation for scenario 5.10 is still unclear. > >=20 > > Cheers, > > Ali > >=20 > >=20 > >=20 > -------------------------------------------------------------- > ---------- > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis >=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 03 08:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGYc-0003Vs-Tp; Wed, 03 May 2006 08:34:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGYb-0003Vn-M1 for nsis@ietf.org; Wed, 03 May 2006 08:34:17 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbGYZ-00060U-8E for nsis@ietf.org; Wed, 03 May 2006 08:34:17 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k43CY5xH014436 for ; Wed, 3 May 2006 13:34:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 May 2006 13:34:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: some comments on SDA selection in the NATFW NSLP Thread-Index: AcZurd2DP10NrqzBRam5sDxi6y4P5g== From: "Hancock, Robert" To: "nsis" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [NSIS] some comments on SDA selection in the NATFW NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, these comments are mainly inspired by appendix A and the other sections on SDA use. to me, App A seems to make the whole problem seem much more complicated than it really needs to be. to take the various options there in turn: 1) seems to say 'use the DS address if it is known'. The first problem listed is not actually a problem, just a statement of fact about how this is done if the DS is behind a NAT. The second problem listed I could not be certain that I understood, but I don't really see what problem arises: it is up to the=20 DS to obtain an address which is valid at the NAT it is behind, and if it can't then no-one will ever be able to communicate with it. If the address is valid at the NAT it is behind, then I don't see how routing asymmetry (which is about differences between the routing for forward and reverse traffic between two nodes) causes issues, since the route is pinned at the NAT anyway.=20 In any case, such a discussion is not relevant here; if the DR knows the DS address, it surely just has to believe it for the purpose of choosing an SDA. Discussing how that DS address might not be valid at all doesn't really change that. 2) if the DR already knows its public address, then I don't see why REA signalling is taking place at all. 3) is about using the application server address. The first problem would seem only to arise if the DR was not behind a NAT in the first place (in which case the DR doesn't need the REA signalling to work); the second problem I would say is a minor issue. What i think is missing is a overall perspective on how a NATFW implementation is expected to/able to interact with other application layer protocols. I'm not talking about APIs, but more abstract points like who is expected to provide what information and when. (This question also occurred to me while reading 2.4.) The key point for App A is that the only reason why the DR might be=20 obtaining an external address is in order to communicate it to someone (if DR doesn't communicate the address, why bother to=20 obtain it?); so the address of the person it communicates with is surely a reasonable address to use as the SDA. It doesn't=20 actually matter whether the SDA corresponds to an application=20 server or a host and you could quite easily have multiple ones. Nor does it matter which address realm the SDA is in - the implementor just has to know that the DR will be reachable from the address=20 realm in which the SDA lives, and choose the SDA accordingly. (A problem arises if the DR only knows an SDA for a node in the wrong address realm - for example, it can only talk to a local SIP proxy behind the same NAT as itself. I can't think of a good solution to that problem.) r. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 03 14:02:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLgG-00053v-5p; Wed, 03 May 2006 14:02:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbLgF-00050p-GQ for nsis@ietf.org; Wed, 03 May 2006 14:02:31 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbLgF-00036e-3J for nsis@ietf.org; Wed, 03 May 2006 14:02:31 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1146679313!10765468!10 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 29714 invoked from network); 3 May 2006 18:02:29 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-4.tower-120.messagelabs.com with SMTP; 3 May 2006 18:02:29 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE0015EECD; Wed, 3 May 2006 14:02:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes Date: Wed, 3 May 2006 13:02:25 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC76E6@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC753A@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP INFO_SPEC and error codes Thread-Index: AcZDnkdSQlCrDHd3RMWXekjIkJhyXAD/lNaAAF+LhgAJb4nKQA== From: "Ash, Gerald R \(Jerry\), ALABS" To: "Andrew McDonald" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: "Ash, Gerald R \(Jerry\), ALABS" , attila.bader@ericsson.com, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, We're still awaiting your proposed response/resolution to this issue RE QoS-NSLP error codes. This is one remaining issue needing resolution for the QSPEC I-D to be reissued, as requested by John on 10 April http://www1.ietf.org/mail-archive/web/nsis/current/msg06158.html. =20 See the attached thread, which ended with my post on 16 March, http://www1.ietf.org/mail-archive/web/nsis/current/msg06060.html, where I made some suggestions to resolve the issue. We discussed this suggestion at the NSIS breakfast meeting in Dallas, but I think you wanted to better separate the signaling aspects of the error codes (should be specified in QoS-NSLP) from the QSPEC/RMF aspects (which should be specified in QSPEC). Please let us know what you propose to resolve this issue. Thanks, Regards, Jerry=20 -----Original Message----- From: Ash, Gerald R (Jerry), ALABS=20 Sent: Thursday, March 16, 2006 12:42 PM To: 'Andrew McDonald'; 'nsis@ietf.org' Cc: Ash, Gerald R (Jerry), ALABS; 'cornelia.kappler@siemens.com'; 'attila.bader@ericsson.com' Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes Hi Andrew, All, Please see comments in line: > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Thursday, March 09, 2006 12:23 PM > To: Jukka MJ Manner; Georgios Karagiannis > Cc: nsis@ietf.org > Subject: [NSIS] QoS NSLP INFO_SPEC and error codes >=20 > A few comments in the area of the INFO_SPEC object and error codes. >=20 > Draft -10 doesn't seem to have appeared yet, but these comments apply=20 > equally to -09 and -10. >=20 > Protocol errors include: > * 0x08 - Unknown QSPEC type: the QoS Model ID refers to a > QoS Model which is not known by this QNE. > It's not clear to me that is a protocol error. Firstly, QoS Model ID > is inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly, > my understanding from the QSPEC template is that, in the case of an > unknown QoS Model ID, the RMF should continue to process mandatory=20 > QSPEC parameters. Jerry> Both comments are correct. This error subcode should probably be deleted. Should it be replaced by some other type of error involving QOSM ID (none come to mind for me)? =20 > Transient failure codes include: > * 0x01 - Requested resources not available > * 0x02 - Insufficient bandwidth available > * 0x03 - Delay requirement cannot be met >=20 > Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since > they directly relate to information in the QSPEC rather than the > main QoS NSLP data? Jerry> I agree that 0x02 and 0x03 are specific cases of 0x01, but they are not IMO "QoS model specific" since is a mandatory QSPEC parameter and is an optional QSPEC parameter. Similarly, perhaps "cannot be met" error subcodes should be defined for , , and parameters, which are also optional QSPEC parameters. =20 Perhaps it's better to describe the '4-bit error class', '12-bit error codes', and '8-bit QoS model-specific error subcode' in terms of "QSPEC/RMF-specific" rather than "QoS Model specific". So then the 4-bit error class=20 "0x06 - QoS model-specific Error"=20 becomes=20 "0x06 - QSPEC/RMF-specific Error". And also redefine the=20 "8-bit QoS model-specific error subcode"=20 as "8-bit QSPEC/RMF-specific error subcode". Then within the 4-bit error class "0x06 - QSPEC/RMF-specific Error" the following 12-bit error code is defined (now a 'transient failure code"): 0x01 - Requested resources not available And within that 12-bit error code the following "8-bit QSPEC/RMF-specific error subcodes" are defined: 0x02 - cannot be met 0x03 - cannot be met and perhaps others, e.g., 0xab - cannot be met 0xcd - cannot be met 0xef - cannot be met=20 etc. These error codes pertaining to mandatory/optional QSPEC parameters (defined within the QSPEC I-D) can either be defined in the QoS-NSLP I-D (preferably IMO) or alternatively within the QSPEC I-D. =20 Additional 'QSPEC/RMF-specific Errors' and their '12-bit error code' and '8-bit QSPEC/RMF-specific error subcodes' pertaining to (optional) QSPEC parameters defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, etc.) should also be defined in the QOSM-specific I-Ds. Should any of the above be identified as issues to be discussed at IETF-65? Please let me know what you think. Thanks, Regards, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 03 15:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbMfE-0001XK-FN; Wed, 03 May 2006 15:05:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbMfD-0001XF-FA for nsis@ietf.org; Wed, 03 May 2006 15:05:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbMfB-0005vH-4o for nsis@ietf.org; Wed, 03 May 2006 15:05:31 -0400 Received: (qmail invoked by alias); 03 May 2006 19:05:26 -0000 Received: from p54986B25.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.107.37] by mail.gmx.net (mp007) with SMTP; 03 May 2006 21:05:26 +0200 X-Authenticated: #29516787 Message-ID: <4458FEF0.5010106@gmx.net> Date: Wed, 03 May 2006 21:05:20 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: NSIS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [NSIS] Diameter QoS Discussions X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, we are going to start our Diameter QoS discussions on the Diameter Maintenance and Extentions Working Group (DIME) mailing list. If you are interested in this subject (since it is highly relevant for the QoS NSLP work) you might want to subscribe to the DIME mailing list at: https://www1.ietf.org/mailman/listinfo/dime Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 03 18:52:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQDG-0008LG-13; Wed, 03 May 2006 18:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbQDB-0008GO-OC for nsis@ietf.org; Wed, 03 May 2006 18:52:50 -0400 Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbQDA-0006ox-6V for nsis@ietf.org; Wed, 03 May 2006 18:52:49 -0400 Received: from [10.3.1.136] (din-cisuc136.dei.uc.pt [10.3.1.136]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k43MqjIH024263 for ; Wed, 3 May 2006 23:52:45 +0100 Message-ID: <44593438.50800@student.dei.uc.pt> Date: Wed, 03 May 2006 23:52:40 +0100 From: David Palma User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.399, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [NSIS] Problem in QoS-NSLP draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I'm from the University of Coimbra and I'm currently implementing the QoS-NSLP. In page 61 of the draft (draft-ietf-nsis-qos-nslp-10.txt) about RESERVE message processing, I found: If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state installation action. It does so by sending a RESPONSE with an INFO_SPEC indicating that the reservation is installed at the QNE (code 0x03). And in page 63 about RESPONSE message processing I found: In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE flag is set or when an error occurs while processing a received message. If the received message contains an RII object and the ACKNOWLEDGE flag is set, a QNE generates a RESPONSE without RII if the QNE is not the QNR. In this case a successful RESPONSE carries the INFO_SPEC with success code 0x01 and the received message is forwarded further along the path towards the QNR. What is the value that we are supposed to include in the INFO_SPEC? 0x03 or 0x01? In my opinion regarding this part of the INFO_SPEC description: o Success: * 0x01 - State installation succeeded * 0x02 - Reservation created: reservation installed on complete path (sent by last node). * 0x03 - Reservation accepted: reservation installed at this QNE, but not yet installed on the rest of the path. * 0x04 - Reservation created but modified: reservation installed, but bandwidth reserved was not the maximum requested. 0x03 would be the most accurate value to include. Best Regards, David Palma _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 03:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYb0-0003ia-NO; Thu, 04 May 2006 03:49:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYaz-0003iV-KT for nsis@ietf.org; Thu, 04 May 2006 03:49:57 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbYay-0005F2-6F for nsis@ietf.org; Thu, 04 May 2006 03:49:57 -0400 Received: from [84.163.58.247] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1FbYax0jRf-00073X; Thu, 04 May 2006 09:49:55 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id EA57B1911B2; Thu, 4 May 2006 09:49:38 +0200 (CEST) Date: Thu, 4 May 2006 09:49:38 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060504074938.GA349@mafr.de> Mail-Followup-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [NSIS] NATFW and multihoming X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I've got a question about section 2.8 of the NATFW draft ("Multihomed Network with NAT"). According to the text, "NATFW NSLP must be able to handle this situation properly", however the referenced section 3.8.2 only specifies the REA mechanism. The case where the NAT on the data and signaling path disappears is not covered. The end hosts could still communicate using the other NAT in theory, but of course the IP address changes and the state on the original NAT is lost. I realize that there is no simple solution, it would require creating new state and modifying existing state on the path (which includes creating new bindings on the remaining NAT). The application data flow has to be redirected, too, which isn't trivial. Is this scenario out of scope or are there plans to support it in NATFW? The draft at [1] also lists this as an open question (section 3.2.4(4)). Thanks, Matthias [1] http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-04.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 09:57:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeKH-0002uZ-LD; Thu, 04 May 2006 09:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeKG-0002uU-Qu for nsis@ietf.org; Thu, 04 May 2006 09:57:04 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeKF-0004of-Cf for nsis@ietf.org; Thu, 04 May 2006 09:57:04 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0DB291BAC4D; Thu, 4 May 2006 15:50:50 +0200 (CEST) In-Reply-To: <4443F69F.9000708@uni-tuebingen.de> References: <4443F69F.9000708@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D167603-348A-48BA-AB2E-634153ACF4F6@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP; using REA mode for blocking data flows Date: Thu, 4 May 2006 15:57:01 +0200 To: Ali Fessi X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, I have been away on vacation and now catching up with the emails. The name REA (RESERVE-EXTERNAL-ADDRESS) has its roots in the time of reserving a public reachable IP address at a NAT. The semantics of this REA message has changed over time and does now include firewalls as well. We have had some proposals for a new name of REA, but none of them could ultimately convince. My current reading for REA is, that in any case (NAT or firewall) you do reserve the external reachable IP address. For the NAT case, this is the public reachable IP address; for the firewall case this is the globally routable IP address of the host (or one of these addresses). Both "types" of addresses are external addresses. However, if somebody has a good proposal for another name describing the semantics in a better way -- send it NOW. (yet another naming contest :-) Martin Am 17.04.2006 um 22:12 schrieb Ali Fessi: > Hi all, > > the REA mode (Reserving External Address) was originally called REA > mode because it is used by hosts behind a NAT to reserve a publicly > reachable IP address (and port number). > > Now, the REA mode is also used by hosts behind a firewall to signal > to a firewall for blocking data traffic. > > Although from functionality point of view, it might be fine to use > the same name for these two similar functionalities; but from > terminology point of view, this is rather confusing to signal for > blocking data traffic and call it "REA mode". > > So, why not use a different name that matches more the > functionality, something like "BLOCK mode" for example?! This would > make it easier for the readers to understand. > > Cheers, > Ali > -- > Ali Fessi > University of Tuebingen, Germany > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 10:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeNG-00042G-1P; Thu, 04 May 2006 10:00:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeNE-000426-OZ for nsis@ietf.org; Thu, 04 May 2006 10:00:09 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeNE-0004sy-3d for nsis@ietf.org; Thu, 04 May 2006 10:00:08 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id BBB6F1BAC4D; Thu, 4 May 2006 15:53:54 +0200 (CEST) In-Reply-To: <000001c662d1$c57f77b0$6500000a@comm.ad.roke.co.uk> References: <000001c662d1$c57f77b0$6500000a@comm.ad.roke.co.uk> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3FBE0957-2EA8-4950-B81C-5815DC3005B8@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages Date: Thu, 4 May 2006 16:00:06 +0200 To: Robert Hancock X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: 'nsis' X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert, all, I cannot say much other than reasonable points and we need to nail the facts down in the security considerations section. Just my few cents Martin Am 18.04.2006 um 12:20 schrieb Robert Hancock: > hi all, > > some cents: > > *) GIST carries the SID in routing state setup messages > (including the Query). This is at least partly because > the routing state maintained at the GIST level is SID- > dependent (for security reasons which are discussed in > the spec). It might theoretically be possible to remove > the SID from the initial messages but it would require > quite a bit of careful thought, and would also require > quite a bit of surgery to the message processing rules. > The principle we adopted at an early stage was that > confidentiality of the SID was not a goal. > > *) GIST doesn't say anything about how SIDs should be > allocated. There are asymmetric cryptography techniques > that could use the SID in a particular way which was more > secure. That might be an option for future development of > the NATFW protocol. > > *) I think (with Hannes) that it would be a very bad idea > to mandate the use of confidentiality. (Implementation is > already mandated, since it's an mandatory-to-implement > function within GIST.) Mandating the use would have one > of two effects: > - people who took the requirement seriously would quite > possibly decide never to use the protocol at all, even > in environments where it was legitimate, because of the > burden of credential & key management; > - people who did not take the requirement seriously would > simply ignore it. (How many times have you heard from > the v6 marketing community that it has 'security built in'? > and what effect does it have in practice?) > > *) I think the right way to address these concerns is to > write a thorough security considerations section which > explains (in particular) the consequences of not using > GIST-level confidentiality, both for yourself and for > other nodes along the path. > > r. > >> -----Original Message----- >> From: Ali Fessi [mailto:ali.fessi@uni-tuebingen.de] >> Sent: 17 April 2006 23:32 >> To: Hannes Tschofenig >> Cc: nsis >> Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages >> >> >> Hi Hannes, >> >> Hannes Tschofenig wrote: >>> Hi Ali, >>> >>> Ali Fessi wrote: >>> >>>> Hi Hannes, all, >>>> >>>> as you know, the functionality provided by the NATFW NSLP >> is pretty >>>> complex and very security-sensitive. >>> >>> >>> Where do you see the complexity in the protocol? >> >> The NATFW NSLP involves many entities in the signaling process which >> makes a security analysis difficult. >> >> One of the main problems is that due to the NAT handling, message >> integrity can not be provided end-to-end or end-to-middle. >> >> If the protocol would, for example, deal only with firewalls, >> it would >> be much easier. >> >>> >>>> >>>> Therefore, it will not be easy for someone who wants to >> deploy it to >>>> decide whether confidentiality in his network makes sense >> or not. I >>>> wouldn't leave this decision open because this would just >> introduce >>>> more vulnurabilities in the deployment of the NATFW NSLP. >>> >>> >>> Mandating a particular deployment model would, in my view, >> make it even >>> harder to get things deployed. >>> >>>> >>>> Furthermore, message confidentiality for the NATFW NSLP is >> required >>>> for several reasons: >>>> >>>> - it protects the SID, which is necessary if SID should be >> used as a >>>> proof for session ownership; >>> >>> >>> I need to take a look again at the GIST draft but some time >> back I got >>> the impression that the discovery exchange messages also >> carry the SID. >>> As such, the SID would not be protected. I need to check it again. >> >> >> That would be even one more reason for NOT using the SID for >> the proof >> of session ownership! >> >> >>>> >>>> - it protect authorization tokens if there will be any. Actually , >>>> other protocols carrying an authorization tokens for the >> NATFW NSLP, >>>> e.g. application layer protocols, must be also >> confidentility-protected. >>> >>> Actually they don't. >>> RSVP carries authorization tokens and RSVP signaling >> messages are not >>> confidentiality protected. >> >> do you know whether RSVP authorization tokens are used in some >> environments?! If the NATFW NSLP should be used in an Internet >> environment, then authorization tokens must be protected against >> eavesdropping. >> >>> >>>> Otherwise, we have a problem and authorization tokens >> would be useless. >>> >>> That's not true. It depends on the deployment environment. >> >> agreed. >> >>> >>>> >>>> - it protects the policy rules that need to be installed. >>> >>> They do not need a protection since the data traffic will >> reveal these >>> rules anyway. >>> >>> >>> The draft >>> >>>> currently argues that policy rules do not need to be >> protected from >>>> eavesdropping, since an attacker could also eavesdrop the >> traffic and >>>> find out which policy rules are currently installed. >> However, I think >>>> this argument would be just one more argument for not >> deploying the >>>> NATFW NSLP due to its insecurity >>> >>> >>> I am not sure I can follow your line of argument here. >>> >>> The NATFW NSLP is not IKEv2 and IPsec. >> >> I'm not talking about IKEv2 neither about IPSec. >>> >>>> >>>> Also, if TLS or IPSec is used for providing hop-by-hop >> authentication >>>> between NSIS node, it does not requires an additional effort to >>>> provide message confidentiality. >>>> And as I mentiond before, from cryptographic point of view, >>>> confidentiality is cheap and does not add an addional delay to the >>>> signaling process. >>> >>> >>> >>> That's true. IF you use hop-by-hop authentication then you >> might just >>> want to enable confidentiality protection. >>> >>> Still, I do not want to make deployment restrictions: If >> the 3GPP2 want >>> to use the NATFW NSLP based on a specific set of >> ciphersuites then I am >>> fine with it because they have their security folks that know the >>> environment better than we do. >> >> Ok, I understand your point. But I think it should be clearly >> stated in >> the draft, which vulnerabilities do exist if the NATFW NSLP is used >> without message confidentiality and that it is highly recommended to >> provide message confidentiality either by using IPSec/TLS or a link >> layer specific mechanism (I guess the latter case will apply in 3GPP2 >> environments). >> >> Is that fine with you? >> >> Cheers, >> Ali. >> >>> >>> Ciao >>> Hannes >>> >>>> >>>> What do you think? >>>> >>>> Cheers, >>>> Ali >> >> >> -- >> Ali Fessi >> University of Tuebingen, Germany >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 10:42:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbf24-0005J0-Kz; Thu, 04 May 2006 10:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbf22-0005Iv-Q9 for nsis@ietf.org; Thu, 04 May 2006 10:42:18 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbf22-0006nL-Ay for nsis@ietf.org; Thu, 04 May 2006 10:42:18 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C44391BAC4D; Thu, 4 May 2006 16:36:04 +0200 (CEST) In-Reply-To: <44480714.2000907@uni-tuebingen.de> References: <44480714.2000907@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP; No solution provided for attack described in section 5.5.3 Date: Thu, 4 May 2006 16:42:16 +0200 To: Ali Fessi X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, my reply is two-fold: a) measures already included in the NATFW NSLP to mitigate parts of this attack b) things still not handled For a) The rule for firewalls supporting the NATFW NSLP is to block all inbound NATFW request messages by default. A DR must first tell the upstream firewall(s) its desire to receive NATFW request messages by using REA. Afterwards it can receive these request messages. This means, that the described attack is only possible if the DR has signaled with REA. The threat description describes two cases: i) IP address and/or additional information about the data flow is known in advance, for instance, DS' IP address or transport protocol ii) Nothing is known in advance about the DS, for instance, if DR is a server and waiting for arbitrary clients to connect. For case i), the DR can specify this information in its MRI or the REA message. Case ii) leads over to point b) For b) In this case, there is not much information about DS available. This is typically the case for a server behind a firewall, i.e., all possible attacks on a server apply here as well. One way of mitigate this is the usage of an authorization framework, as you have described it. The current version of the NSLP describes the NATFW_CREDENTIAL object, which can be used in this context. I have to admit, that this new object has not been reflected in the particular section of the security considerations. The description is true for the case in Section 5.5.4 (NAT) as well. The countermeasure, similar to a) in this email, is the usage of the DTINFO_IPV4 object. Martin Am 21.04.2006 um 00:11 schrieb Ali Fessi: > Dear NATFW NSLP authors, > > there is currently no security requirement derived from the threat > described in Section 5.5.3 (Data Receiver (DR) behind a firewall); > > although it is a very realistic attack! > > However, looking at the whole document, a solution for resolving > this attack can be actually provided: > > - either by relying on an authorization framework (authorization > tokens, SAML, etc.) > > - or by relying upon GIST or underlying protocols, for providing > hop-by-hop authentication; > > So the derived security requirements could be updated accordingly > (i could provide a suggestions for some text, if you want) > > Also: the attack described in section 5.5.4 is actually the same > except the middlebox function is a NAT instead of firewall; but > this doesn't make a difference. > > Regards, > Ali > -- > Ali Fessi > University of Tuebingen, Germany > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 11:26:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbfia-0007OD-9a; Thu, 04 May 2006 11:26:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbfiY-0007Ho-RN for nsis@ietf.org; Thu, 04 May 2006 11:26:14 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbfiY-0008Sf-Dh for nsis@ietf.org; Thu, 04 May 2006 11:26:14 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B3BB01BAC4D; Thu, 4 May 2006 17:20:00 +0200 (CEST) In-Reply-To: <20060504074938.GA349@mafr.de> References: <20060504074938.GA349@mafr.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW and multihoming Date: Thu, 4 May 2006 17:26:12 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, Am 04.05.2006 um 09:49 schrieb Matthias Friedrich: > Hi, > > I've got a question about section 2.8 of the NATFW draft ("Multihomed > Network with NAT"). > > According to the text, "NATFW NSLP must be able to handle this > situation > properly", however the referenced section 3.8.2 only specifies the > REA mechanism. The case where the NAT on the data and signaling path > disappears is not covered. The end hosts could still communicate using > the other NAT in theory, but of course the IP address changes and the > state on the original NAT is lost. There is no straight forward solution for the case where the DR is behind NATs and the NAT goes down. This is due to the properties of NATs. > > I realize that there is no simple solution, it would require creating > new state and modifying existing state on the path (which includes > creating new bindings on the remaining NAT). The application data flow > has to be redirected, too, which isn't trivial. > > Is this scenario out of scope or are there plans to support it in > NATFW? There is need no easy solution, which is due to the NAT itself. However, for a data sender behind a NAT (as in Section 2.8) the unavailable NAT will result in a route change (given that there is routing). The route change behaviour is described in Section 3.10. A data receiver behind a NAT has several mean to detect the unavailable NAT: a) No data yet, but reserved state from the REA exchange b) Data flow is running In a), the REA refresh messages will be re-routed (given that there is routing) to another NAT and the DR will receive a new public IP address. This needs to communicate to the other peers of DR. In b), the DR would need to monitor the data flow and the signaling message exchange (there have to be refresh messages). It can be an indication of a failed NAT, if both, data and signaling, and not alive anymore (also it can indicate other problems, either at the DS side or somewhere else on the way). The DR needs to send a REA message, either reusing old state (i.e., sending a refresh REA) or setting up a complete new session. In any case, the DR will be receiving a new IP address and port number and this needs to told other peers. Martin > > The draft at [1] also lists this as an open question (section 3.2.4 > (4)). > > Thanks, > Matthias > > [1] http://www.ietf.org/internet-drafts/draft-ietf-nsis- > applicability-mobility-signaling-04.txt > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 16:02:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbk2E-0004Ws-St; Thu, 04 May 2006 16:02:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbk2D-0004Wn-8E for nsis@ietf.org; Thu, 04 May 2006 16:02:49 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbk2C-00044R-Pu for nsis@ietf.org; Thu, 04 May 2006 16:02:49 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Thu, 04 May 2006 23:02:44 +0300 id 000703C5.445A5DE4.00005476 Date: Thu, 4 May 2006 23:02:44 +0300 (EEST) From: Jukka MJ Manner To: David Palma Subject: Re: [NSIS] Problem in QoS-NSLP draft In-Reply-To: <44593438.50800@student.dei.uc.pt> Message-ID: References: <44593438.50800@student.dei.uc.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, The ACK-flag will be removed from the next version of the spec. People have felt it is not really needed, GIST can provide the reliability that the ACK-flag was supposed to bring at the NSLP layer. Jukka On Wed, 3 May 2006, David Palma wrote: > Hi all, > > I'm from the University of Coimbra and I'm currently implementing the > QoS-NSLP. > > In page 61 of the draft (draft-ietf-nsis-qos-nslp-10.txt) about RESERVE > message processing, I found: > > If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state > installation action. It does so by sending a RESPONSE with an > INFO_SPEC indicating that the reservation is installed at the QNE > (code 0x03). > > > And in page 63 about RESPONSE message processing I found: > > In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE > flag is set or when an error occurs while processing a received > message. If the received message contains an RII object and the > ACKNOWLEDGE flag is set, a QNE generates a RESPONSE without RII if > the QNE is not the QNR. In this case a successful RESPONSE carries > the INFO_SPEC with success code 0x01 and the received message is > forwarded further along the path towards the QNR. > > > What is the value that we are supposed to include in the INFO_SPEC? 0x03 or > 0x01? > In my opinion regarding this part of the INFO_SPEC description: > > o Success: > > * 0x01 - State installation succeeded > > * 0x02 - Reservation created: reservation installed on > complete path (sent by last node). > > * 0x03 - Reservation accepted: reservation installed at this > QNE, but not yet installed on the rest of the path. > > * 0x04 - Reservation created but modified: reservation > installed, but bandwidth reserved was not the maximum > requested. > > 0x03 would be the most accurate value to include. > > > Best Regards, > > David Palma > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 04 16:36:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkYu-0005H8-E9; Thu, 04 May 2006 16:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbkYt-0005GZ-79 for nsis@ietf.org; Thu, 04 May 2006 16:36:35 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbkYr-0006Ih-Nx for nsis@ietf.org; Thu, 04 May 2006 16:36:35 -0400 Received: (qmail invoked by alias); 04 May 2006 20:36:31 -0000 Received: from p54985C8A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.92.138] by mail.gmx.net (mp026) with SMTP; 04 May 2006 22:36:31 +0200 X-Authenticated: #29516787 Message-ID: <445A65CC.8010008@gmx.net> Date: Thu, 04 May 2006 22:36:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthias Friedrich Subject: Re: [NSIS] NATFW and multihoming References: <20060504074938.GA349@mafr.de> In-Reply-To: <20060504074938.GA349@mafr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, let me also respond to you. Matthias Friedrich wrote: > Hi, > > I've got a question about section 2.8 of the NATFW draft ("Multihomed > Network with NAT"). > > According to the text, "NATFW NSLP must be able to handle this situation > properly", however the referenced section 3.8.2 only specifies the > REA mechanism. The case where the NAT on the data and signaling path > disappears is not covered. > The end hosts could still communicate using > the other NAT in theory, but of course the IP address changes and the > state on the original NAT is lost. Let us look at the picture and assume that MB1 and MB2 are NATs and the network is multi-homed. +----+ DR -------|MB1 |\ \ +----+ \ //---\\ \ -| |-- DS \ \\---// \ +----+ | --|MB2 |-------+ +----+ private public The initial REA allocated a NAT binding at MB1. Now, MB1 goes down. The main question now depends on how data traffic is routed. If the REA routing changes and travels through MB2 then everything will be fine again at the next refresh interval. The REA will hit MB2 and will create a new NAT binding. If traffic sent by the DR travels to MB1 (which does not work anymore) then both data traffic and NSIS signaling traffic will disappear. What do you think? Ciao Hannes > > I realize that there is no simple solution, it would require creating > new state and modifying existing state on the path (which includes > creating new bindings on the remaining NAT). The application data flow > has to be redirected, too, which isn't trivial. > > Is this scenario out of scope or are there plans to support it in NATFW? > > The draft at [1] also lists this as an open question (section 3.2.4(4)). > > Thanks, > Matthias > > [1] http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-04.txt > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 05 09:09:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc03z-0003uE-5K; Fri, 05 May 2006 09:09:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc03t-0003u1-8R for nsis@ietf.org; Fri, 05 May 2006 09:09:37 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc03r-0003KT-Pd for nsis@ietf.org; Fri, 05 May 2006 09:09:37 -0400 Received: from [84.163.15.27] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2Dk-1Fc03l0IKp-0000mF; Fri, 05 May 2006 15:09:29 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id E4AC41911B2; Fri, 5 May 2006 15:09:11 +0200 (CEST) Date: Fri, 5 May 2006 15:09:11 +0200 From: Matthias Friedrich To: nsis@ietf.org Subject: Re: [NSIS] NATFW and multihoming Message-ID: <20060505130911.GA13150@mafr.de> Mail-Followup-To: nsis@ietf.org, Hannes.Tschofenig@gmx.net References: <20060504074938.GA349@mafr.de> <445A65CC.8010008@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445A65CC.8010008@gmx.net> User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, thanks for the answer, more questions below. On Thursday, 2006-05-04, Hannes Tschofenig wrote: > Matthias Friedrich wrote: [...] > Let us look at the picture and assume that MB1 and MB2 are NATs and the > network is multi-homed. > +----+ > DR -------|MB1 |\ > \ +----+ \ //---\\ > \ -| |-- DS > \ \\---// > \ +----+ | > --|MB2 |-------+ > +----+ > > private public > The initial REA allocated a NAT binding at MB1. Now, MB1 goes down. > The main question now depends on how data traffic is routed. If the REA > routing changes and travels through MB2 then everything will be fine > again at the next refresh interval. The REA will hit MB2 and will create > a new NAT binding. OK, so the DR sends REAs regularly to keep the NAT binding alive, as per section 3.8.3. From reading [1] I got the impression that CREATE (or rather RESPONSE?) could also keep the NAT binding alive. See their section 8, state SESSION, which doesn't send refresh REAs. > If traffic sent by the DR travels to MB1 (which does not work anymore) > then both data traffic and NSIS signaling traffic will disappear. > What do you think? This means the DR has to check all RESPONSEs to its REA messages and if the external address has changed, it has to tell the DS the new address via some signaling mechanism (as Martin wrote in his reply). One way would be to use the application level signaling if that's still available. The other would be to send an NATFW NOTIFY to the DS which contains the new external address. For the latter method, an optional "Data Terminal Information Object" would have to be added to NOTIFY. Do you think the use case is important enough to justify this change? Even if the NOTIFY is modified, it's not guaranteed that the DS can redirect the data traffic. For example, it's not easily possible to change the destination address of a TCP session on the fly. Thanks for your answers, Matthias [1] http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-nslp-statemachine-02.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 05 10:45:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Yt-0001jg-De; Fri, 05 May 2006 10:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Ys-0001fH-Gg for nsis@ietf.org; Fri, 05 May 2006 10:45:42 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1Ys-00072r-1h for nsis@ietf.org; Fri, 05 May 2006 10:45:42 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k45EjecD015878; Fri, 5 May 2006 16:45:41 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k45EjekL032486; Fri, 5 May 2006 16:45:40 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 16:45:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] NATFW and multihoming Date: Fri, 5 May 2006 16:45:39 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW and multihoming Thread-Index: AcZwRWTEPQmp6wMGTv26CzDWRMcUyQACzyCQ From: "Tschofenig, Hannes" To: "Matthias Friedrich" , X-OriginalArrivalTime: 05 May 2006 14:45:40.0526 (UTC) FILETIME=[945B04E0:01C67052] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias,=20 > Hi, >=20 > thanks for the answer, more questions below. >=20 > On Thursday, 2006-05-04, Hannes Tschofenig wrote: > > Matthias Friedrich wrote: >=20 > [...] > > Let us look at the picture and assume that MB1 and MB2 are=20 > NATs and the=20 > > network is multi-homed. >=20 > > +----+ > > DR -------|MB1 |\ > > \ +----+ \ //---\\ > > \ -| |-- DS > > \ \\---// > > \ +----+ | > > --|MB2 |-------+ > > +----+ > > > > private public >=20 >=20 > > The initial REA allocated a NAT binding at MB1. Now, MB1 goes down. >=20 > > The main question now depends on how data traffic is=20 > routed. If the REA=20 > > routing changes and travels through MB2 then everything=20 > will be fine=20 > > again at the next refresh interval. The REA will hit MB2=20 > and will create=20 > > a new NAT binding. >=20 > OK, so the DR sends REAs regularly to keep the NAT binding alive, as > per section 3.8.3. Yes, that's the idea of the soft-state mechanisms.=20 > From reading [1] I got the impression that CREATE > (or rather RESPONSE?) could also keep the NAT binding alive. See their > section 8, state SESSION, which doesn't send refresh REAs. A successful CREATE/RESPONSE message run refreshes state. The same is true for REA/RESPONSE messages.=20 >=20 > > If traffic sent by the DR travels to MB1 (which does not=20 > work anymore)=20 > > then both data traffic and NSIS signaling traffic will disappear. That's the difficult part with the roles. To be precise the DR would change its role to a DR when it sends traffic.=20 If the all packets travel to MB1 (which is down) then nothing works.=20 >=20 > > What do you think? >=20 > This means the DR has to check all RESPONSEs to its REA messages and > if the external address has changed, it has to tell the DS the new > address via some signaling mechanism (as Martin wrote in his reply). > One way would be to use the application level signaling if=20 > that's still > available. The other would be to send an NATFW NOTIFY to the DS which > contains the new external address. Right. Note that there is nothing special we introduced with NSIS here. You mentioned the mobility draft. There, you also have some signaling exchanges if IP addresses change (for whatever reason).=20 >=20 > For the latter method, an optional "Data Terminal Information Object" > would have to be added to NOTIFY. Do you think the use case=20 > is important > enough to justify this change? That's a good question.=20 >=20 > Even if the NOTIFY is modified, it's not guaranteed that the DS can > redirect the data traffic. For example, it's not easily possible to > change the destination address of a TCP session on the fly. It is easy to redirect the data traffic. However, the implications depend on an IP address change depends on a number of things. A mobility protocol that deals with IP address changes without impacting the high-layer protocols might be a possibility.=20 Ciao Hannes >=20 > Thanks for your answers, > Matthias Ciao Hannes PS: Are you currently working on an implementation of the draft?=20 >=20 > [1]=20 > http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-ns > lp-statemachine-02.txt >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 05 15:50:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Jb-0006Wn-6O; Fri, 05 May 2006 15:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6JQ-0006Td-7X; Fri, 05 May 2006 15:50:04 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc6JN-0002eo-Qq; Fri, 05 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k45Jo1BX013004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fc6JN-0008Oz-Jv; Fri, 05 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 05 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org --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 : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-02.txt Pages : 12 Date : 2006-5-5 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nsis-y1541-qosm-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-5140624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nsis-y1541-qosm-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-5140624.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --NextPart-- From nsis-bounces@ietf.org Fri May 05 16:04:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Xf-0000ui-BN; Fri, 05 May 2006 16:04:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc6Xe-0000ud-9U for nsis@ietf.org; Fri, 05 May 2006 16:04:46 -0400 Received: from mail124.messagelabs.com ([85.158.136.19]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fc6Xc-0005X0-SM for nsis@ietf.org; Fri, 05 May 2006 16:04:46 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-8.tower-124.messagelabs.com!1146859447!9687307!5 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9463 invoked from network); 5 May 2006 20:04:43 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-8.tower-124.messagelabs.com with SMTP; 5 May 2006 20:04:43 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE001B7413 for nsis@ietf.org; Fri, 5 May 2006 16:04:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2006 15:04:43 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC770E@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt Thread-Index: AcZwfTFUjB8MPqpBTniZdSfDdbQp2QAANQYw From: "Ash, Gerald R \(Jerry\), ALABS" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "Ash, Gerald R \(Jerry\), ALABS" Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, Editorial updates have been made to draft "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes" (http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt). I added the 2 other Y.1541 classes to Section 2.1, and made editorial updates to Section 5 (Security Considerations), Section 6 (IANA Considerations), and Section 9 (Informative References). I think the draft should now be ready for WGLC.=20 Thanks, Jerry =20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Friday, May 05, 2006 3:50 PM To: i-d-announce@ietf.org Cc: nsis@ietf.org Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-02.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. Title : Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes Author(s) : J. Ash, et al. Filename : draft-ietf-nsis-y1541-qosm-02.txt Pages : 12 Date : 2006-5-5 =09 This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 QoS signaling requirements. Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM extensions include A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun May 07 23:47:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcwhR-0008Lm-56; Sun, 07 May 2006 23:46:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcwhP-0008Lh-RX for nsis@ietf.org; Sun, 07 May 2006 23:46:19 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcwhP-0005x4-CV for nsis@ietf.org; Sun, 07 May 2006 23:46:19 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k483kDaP005011; Mon, 8 May 2006 06:46:13 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 06:46:13 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 06:46:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] RE: I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt Date: Mon, 8 May 2006 06:46:12 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB4076FE@esebe100.NOE.Nokia.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC770E@KCCLUST06EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] RE: I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt Thread-Index: AcZwfTFUjB8MPqpBTniZdSfDdbQp2QAANQYwAHTu/EA= From: To: , X-OriginalArrivalTime: 08 May 2006 03:46:13.0619 (UTC) FILETIME=[F3E16430:01C67251] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry,=20 We need to get the QoS NSLP & QSPEC documents out first; hopefully we can resolve the last few issues shortly and get everything through WGLC shortly. However, the WG can review the draft now, and all comments will be considered as part of the WGLC. John >-----Original Message----- >From: ext Ash, Gerald R (Jerry), ALABS [mailto:gash@att.com]=20 >Sent: 05 May, 2006 23:05 >To: nsis@ietf.org >Cc: Ash, Gerald R (Jerry), ALABS >Subject: [NSIS] RE: I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt=20 > >Hi All, > >Editorial updates have been made to draft "Y.1541-QOSM --=20 >Y.1541 QoS Model for Networks Using Y.1541 QoS Classes" >(http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm -02.txt). >I added the 2 other Y.1541 classes to Section 2.1, and made=20 >editorial updates to Section 5 (Security Considerations),=20 >Section 6 (IANA Considerations), and Section 9 (Informative=20 >References). > >I think the draft should now be ready for WGLC.=20 > >Thanks, >Jerry =20 > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Friday, May 05, 2006 3:50 PM >To: i-d-announce@ietf.org >Cc: nsis@ietf.org >Subject: [NSIS] I-D ACTION:draft-ietf-nsis-y1541-qosm-02.txt=20 > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Next Steps in Signaling=20 >Working Group of the IETF. > > Title : Y.1541-QOSM -- Y.1541 QoS Model for Networks >Using Y.1541 QoS Classes > Author(s) : J. Ash, et al. > Filename : draft-ietf-nsis-y1541-qosm-02.txt > Pages : 12 > Date : 2006-5-5 >=09 >This draft describes a QoS-NSLP QoS model (QOSM) based on=20 >ITU-T Recommendation Y.1541 QoS signaling requirements. =20 >Y.1541 specifies 6 standard QoS classes, and the Y.1541-QOSM=20 >extensions include > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-02.txt > >_______________________________________________ >nsis mailing list >nsis@ietf.org >https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 03:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WE-0005gR-Ri; Mon, 08 May 2006 03:51:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WD-0005fN-JD for nsis@ietf.org; Mon, 08 May 2006 03:51:01 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0WC-0004S1-0t for nsis@ietf.org; Mon, 08 May 2006 03:51:01 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k487owi6008009; Mon, 8 May 2006 09:50:58 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k487oww3017588; Mon, 8 May 2006 09:50:58 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 09:50:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] NATFW and multihoming Date: Mon, 8 May 2006 09:49:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW and multihoming Thread-Index: AcZyctOrJRK7zSpVRbCduoBDXzF9NAAAO2nQ From: "Tschofenig, Hannes" To: "Matthias Friedrich" , X-OriginalArrivalTime: 08 May 2006 07:50:58.0286 (UTC) FILETIME=[249FC0E0:01C67274] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias,=20 > Hi, >=20 > On Friday, 2006-05-05, Tschofenig, Hannes wrote: > [...] > >> OK, so the DR sends REAs regularly to keep the NAT binding=20 > alive, as > >> per section 3.8.3. >=20 > > Yes, that's the idea of the soft-state mechanisms.=20 >=20 > Good, then the NATFW state machine draft should be fixed, that's what > confused me a bit. The NR's SESSION state needs another timer=20 > that sends > refresh REAs regularly. You are certainly right. We shipped some updates recently and the draft got out-of-sync with the state machine document. We will provide another draft update for the NATFW NSLP draft very soon (given the feedback we received).=20 >=20 > [ signaling of a changed external address ] > >> For the latter method, an optional "Data Terminal=20 > Information Object" > >> would have to be added to NOTIFY. Do you think the use case is > >> important enough to justify this change? >=20 > > That's a good question.=20 >=20 > It's not like I absolutely wanted this feature, I just got=20 > stuck on that > case and wondered if NATFW could help to solve this. That's certainly an interesting point to think about.=20 Ciao Hannes > Cheers, > Matthias >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 03:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WW-0005q9-QY; Mon, 08 May 2006 03:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WU-0005l8-FA for nsis@ietf.org; Mon, 08 May 2006 03:51:18 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0MW-From nsis-bounces@ietf.org Mon May 08 03:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WE-0005gR-Ri; Mon, 08 May 2006 03:51:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WD-0005fN-JD for nsis@ietf.org; Mon, 08 May 2006 03:51:01 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0WC-0004S1-0t for nsis@ietf.org; Mon, 08 May 2006 03:51:01 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k487owi6008009; Mon, 8 May 2006 09:50:58 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k487oww3017588; Mon, 8 May 2006 09:50:58 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 09:50:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] NATFW and multihoming Date: Mon, 8 May 2006 09:49:58 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW and multihoming Thread-Index: AcZyctOrJRK7zSpVRbCduoBDXzF9NAAAO2nQ From: "Tschofenig, Hannes" To: "Matthias Friedrich" , X-OriginalArrivalTime: 08 May 2006 07:50:58.0286 (UTC) FILETIME=[249FC0E0:01C67274] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias,=20 > Hi, >=20 > On Friday, 2006-05-05, Tschofenig, Hannes wrote: > [...] > >> OK, so the DR sends REAs regularly to keep the NAT binding=20 > alive, as > >> per section 3.8.3. >=20 > > Yes, that's the idea of the soft-state mechanisms.=20 >=20 > Good, then the NATFW state machine draft should be fixed, that's what > confused me a bit. The NR's SESSION state needs another timer=20 > that sends > refresh REAs regularly. You are certainly right. We shipped some updates recently and the draft got out-of-sync with the state machine document. We will provide another draft update for the NATFW NSLP draft very soon (given the feedback we received).=20 >=20 > [ signaling of a changed external address ] > >> For the latter method, an optional "Data Terminal=20 > Information Object" > >> would have to be added to NOTIFY. Do you think the use case is > >> important enough to justify this change? >=20 > > That's a good question.=20 >=20 > It's not like I absolutely wanted this feature, I just got=20 > stuck on that > case and wondered if NATFW could help to solve this. That's certainly an interesting point to think about.=20 Ciao Hannes > Cheers, > Matthias >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 03:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WW-0005q9-QY; Mon, 08 May 2006 03:51:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0WU-0005l8-FA for nsis@ietf.org; Mon, 08 May 2006 03:51:18 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0MW-000375-Qb for nsis@ietf.org; Mon, 08 May 2006 03:41:03 -0400 Received: from [84.163.38.150] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Fd0MR1hR0-0003kE; Mon, 08 May 2006 09:40:56 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 7F3B61911B2; Mon, 8 May 2006 09:40:47 +0200 (CEST) Date: Mon, 8 May 2006 09:40:47 +0200 From: Matthias Friedrich To: nsis@ietf.org Subject: Re: [NSIS] NATFW and multihoming Message-ID: <20060508074047.GA25999@mafr.de> Mail-Followup-To: nsis@ietf.org, hannes.tschofenig@siemens.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: hannes.tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, On Friday, 2006-05-05, Tschofenig, Hannes wrote: [...] >> OK, so the DR sends REAs regularly to keep the NAT binding alive, as >> per section 3.8.3. > Yes, that's the idea of the soft-state mechanisms. Good, then the NATFW state machine draft should be fixed, that's what confused me a bit. The NR's SESSION state needs another timer that sends refresh REAs regularly. [ signaling of a changed external address ] >> For the latter method, an optional "Data Terminal Information Object" >> would have to be added to NOTIFY. Do you think the use case is >> important enough to justify this change? > That's a good question. It's not like I absolutely wanted this feature, I just got stuck on that case and wondered if NATFW could help to solve this. [...] > PS: Are you currently working on an implementation of the draft? That's not completely decided yet, but it could be part of my diploma thesis. At the moment I'm trying to get into the topic, reading some of the NSIS drafts and related work. Cheers, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis 000375-Qb for nsis@ietf.org; Mon, 08 May 2006 03:41:03 -0400 Received: from [84.163.38.150] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Fd0MR1hR0-0003kE; Mon, 08 May 2006 09:40:56 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id 7F3B61911B2; Mon, 8 May 2006 09:40:47 +0200 (CEST) Date: Mon, 8 May 2006 09:40:47 +0200 From: Matthias Friedrich To: nsis@ietf.org Subject: Re: [NSIS] NATFW and multihoming Message-ID: <20060508074047.GA25999@mafr.de> Mail-Followup-To: nsis@ietf.org, hannes.tschofenig@siemens.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: hannes.tschofenig@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, On Friday, 2006-05-05, Tschofenig, Hannes wrote: [...] >> OK, so the DR sends REAs regularly to keep the NAT binding alive, as >> per section 3.8.3. > Yes, that's the idea of the soft-state mechanisms. Good, then the NATFW state machine draft should be fixed, that's what confused me a bit. The NR's SESSION state needs another timer that sends refresh REAs regularly. [ signaling of a changed external address ] >> For the latter method, an optional "Data Terminal Information Object" >> would have to be added to NOTIFY. Do you think the use case is >> important enough to justify this change? > That's a good question. It's not like I absolutely wanted this feature, I just got stuck on that case and wondered if NATFW could help to solve this. [...] > PS: Are you currently working on an implementation of the draft? That's not completely decided yet, but it could be part of my diploma thesis. At the moment I'm trying to get into the topic, reading some of the NSIS drafts and related work. Cheers, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 05:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2Pb-0005q4-Jy; Mon, 08 May 2006 05:52:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd2Pa-0005pr-2G for nsis@ietf.org; Mon, 08 May 2006 05:52:18 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd2PX-0002LI-61 for nsis@ietf.org; Mon, 08 May 2006 05:52:18 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k489poYK014216; Mon, 8 May 2006 10:51:56 +0100 Received: from [193.118.197.86] ([193.118.197.86]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:51:49 +0100 Message-ID: <445F14AD.5000001@roke.co.uk> Date: Mon, 08 May 2006 10:51:41 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QoS NSLP INFO_SPEC and error codes References: <9473683187ADC049A855ED2DA739ABCA0DDC76E6@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC76E6@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2006 09:51:49.0922 (UTC) FILETIME=[06EF9820:01C67285] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: attila.bader@ericsson.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, I've been looking at some scribbled notes I've got, and subsequent e-mails on the subject. At the breakfast meeting, the thing I seem to have jotted down was "use the Optional Error-Specific Information" component of the INFO_SPEC for QSpec information. However, in some subsequent off-list discussion, I think I went off this idea a bit. The main problem is that you drag information about QSPEC parameters into the NSLP. Stacking may also create issues with this. The subsequent suggestion was, I believe, that the QoS NSLP should provided a limited set of error codes (e.g. "Total Success", "Partial Success", "Total Failure"). The QSpec parameters then have a flag to indicate which (if any) parameters failed to be satisfied. This is signalled back to the QNI in the response. The QNI then makes the determination about whether to continue or tear down the partial reservation that has been established. Does that sound reasonable? Does it fit with other peoples thoughts? Does the 'E' flag in the QSPEC parameters already provide the necessary QSpec information? (not clear if 'error' covers 'reservation could not be satisfied') Something I've also noticed in looking at the QSpec template document is that the introduction talks about its role as a 'toolbox', but does not talk about the processing flexibility aspect (e.g. the fact that it allows for nodes that support different subsets of QSpec parameters). Andrew Ash, Gerald R (Jerry), ALABS wrote: > Hi Andrew, > > We're still awaiting your proposed response/resolution to this issue RE > QoS-NSLP error codes. This is one remaining issue needing resolution > for the QSPEC I-D to be reissued, as requested by John on 10 April > http://www1.ietf.org/mail-archive/web/nsis/current/msg06158.html. > > See the attached thread, which ended with my post on 16 March, > http://www1.ietf.org/mail-archive/web/nsis/current/msg06060.html, where > I made some suggestions to resolve the issue. We discussed this > suggestion at the NSIS breakfast meeting in Dallas, but I think you > wanted to better separate the signaling aspects of the error codes > (should be specified in QoS-NSLP) from the QSPEC/RMF aspects (which > should be specified in QSPEC). > > Please let us know what you propose to resolve this issue. > > Thanks, > Regards, > Jerry > > -----Original Message----- > From: Ash, Gerald R (Jerry), ALABS > Sent: Thursday, March 16, 2006 12:42 PM > To: 'Andrew McDonald'; 'nsis@ietf.org' > Cc: Ash, Gerald R (Jerry), ALABS; 'cornelia.kappler@siemens.com'; > 'attila.bader@ericsson.com' > Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes > > Hi Andrew, All, > > Please see comments in line: > >> -----Original Message----- >> From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk] >> Sent: Thursday, March 09, 2006 12:23 PM >> To: Jukka MJ Manner; Georgios Karagiannis >> Cc: nsis@ietf.org >> Subject: [NSIS] QoS NSLP INFO_SPEC and error codes >> >> A few comments in the area of the INFO_SPEC object and error codes. >> >> Draft -10 doesn't seem to have appeared yet, but these comments apply >> equally to -09 and -10. >> >> Protocol errors include: >> * 0x08 - Unknown QSPEC type: the QoS Model ID refers to a >> QoS Model which is not known by this QNE. >> It's not clear to me that is a protocol error. Firstly, QoS Model ID >> is inside the QSPEC (so not a 'QoS NSLP protocol error'). Secondly, >> my understanding from the QSPEC template is that, in the case of an >> unknown QoS Model ID, the RMF should continue to process mandatory >> QSPEC parameters. > > Jerry> Both comments are correct. This error subcode should probably be > deleted. Should it be replaced by some other type of error involving > QOSM ID (none come to mind for me)? > >> Transient failure codes include: >> * 0x01 - Requested resources not available >> * 0x02 - Insufficient bandwidth available >> * 0x03 - Delay requirement cannot be met >> >> Should 0x02 and 0x03 be QoS model specific subcodes of 0x01, since >> they directly relate to information in the QSPEC rather than the >> main QoS NSLP data? > > Jerry> I agree that 0x02 and 0x03 are specific cases of 0x01, but they > are not IMO "QoS model specific" since is a mandatory QSPEC > parameter and is an optional QSPEC parameter. Similarly, > perhaps "cannot be met" error subcodes should be defined for Jitter>, , and parameters, which are also optional > QSPEC parameters. > > Perhaps it's better to describe the '4-bit error class', '12-bit error > codes', and '8-bit QoS model-specific error subcode' in terms of > "QSPEC/RMF-specific" rather than "QoS Model specific". > > So then the 4-bit error class > "0x06 - QoS model-specific Error" > becomes > "0x06 - QSPEC/RMF-specific Error". > > And also redefine the > "8-bit QoS model-specific error subcode" > as > "8-bit QSPEC/RMF-specific error subcode". > > Then within the 4-bit error class "0x06 - QSPEC/RMF-specific Error" the > following 12-bit error code is defined (now a 'transient failure code"): > 0x01 - Requested resources not available > > And within that 12-bit error code the following "8-bit > QSPEC/RMF-specific error subcodes" are defined: > > 0x02 - cannot be met > 0x03 - cannot be met > and perhaps others, e.g., > 0xab - cannot be met > 0xcd - cannot be met > 0xef - cannot be met > etc. > > These error codes pertaining to mandatory/optional QSPEC parameters > (defined within the QSPEC I-D) can either be defined in the QoS-NSLP I-D > (preferably IMO) or alternatively within the QSPEC I-D. > > Additional 'QSPEC/RMF-specific Errors' and their '12-bit error code' and > '8-bit QSPEC/RMF-specific error subcodes' pertaining to (optional) QSPEC > parameters defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, > etc.) should also be defined in the QOSM-specific I-Ds. > > Should any of the above be identified as issues to be discussed at > IETF-65? > > Please let me know what you think. > > Thanks, > Regards, > Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 08:35:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4wi-0002gZ-3M; Mon, 08 May 2006 08:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd4wh-0002g3-C9 for nsis@ietf.org; Mon, 08 May 2006 08:34:39 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd4r3-0005Y0-IE for nsis@ietf.org; Mon, 08 May 2006 08:28:53 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 6071C11B; Mon, 8 May 2006 14:28:46 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 14902-02; Mon, 8 May 2006 14:28:44 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E1DF8144; Mon, 8 May 2006 14:28:43 +0200 (DFT) Message-ID: <445F397B.8030905@uni-tuebingen.de> Date: Mon, 08 May 2006 14:28:43 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nsis Subject: [NSIS] Comments to the NATFW NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin and all NATFW NSLP co-authors, you can find some comments on the NATFW NSLP draft on: http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/fessi/IETF/draft-ietf-nsis-nslp-natfw-11-ali.doc just few cents: - some of the comments are editorial - I think many critical issues have been already discussed on the mailing list. - IMHO, the "Security Considerations" section still needs some revision; the discussions on the mailing list could be used as input for the revision. Have a good day, Ali _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 08:44:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd560-00045A-JZ; Mon, 08 May 2006 08:44:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd55z-00044v-97 for nsis@ietf.org; Mon, 08 May 2006 08:44:15 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd55x-0006NY-Pc for nsis@ietf.org; Mon, 08 May 2006 08:44:15 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k48CiCQU001642; Mon, 8 May 2006 14:44:12 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k48CiCEk032534; Mon, 8 May 2006 14:44:12 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 14:44:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] Comments to the NATFW NSLP Date: Mon, 8 May 2006 14:44:08 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] Comments to the NATFW NSLP Thread-Index: AcZynGMMU4wnJ2kZTna6buoDx3d7gQAAFXnA From: "Tschofenig, Hannes" To: "Ali Fessi" , "Martin Stiemerling" X-OriginalArrivalTime: 08 May 2006 12:44:12.0566 (UTC) FILETIME=[1BA1D360:01C6729D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali,=20 > Hi Martin and all NATFW NSLP co-authors, >=20 > you can find some comments on the NATFW NSLP draft on: >=20 > http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/fe > ssi/IETF/draft-ietf-nsis-nslp-natfw-11-ali.doc Thanks for the comments. I will go through them as soon as possible.=20 >=20 > just few cents: >=20 > - some of the comments are editorial > - I think many critical issues have been already discussed on the=20 > mailing list. > - IMHO, the "Security Considerations" section still needs=20 > some revision;=20 > the discussions on the mailing list could be used as input=20 > for the revision. Yes; draft version -11 does not yet address our recent discussions.=20 Ciao Hannes >=20 > Have a good day, > Ali >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 10:11:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6RT-0008KJ-AR; Mon, 08 May 2006 10:10:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd6RS-0008IU-EW for nsis@ietf.org; Mon, 08 May 2006 10:10:30 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd6RR-0002hR-4r for nsis@ietf.org; Mon, 08 May 2006 10:10:30 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 791E91BAC4D; Mon, 8 May 2006 16:03:47 +0200 (CEST) In-Reply-To: <445F397B.8030905@uni-tuebingen.de> References: <445F397B.8030905@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A4EC9CC-0698-4FEE-84FF-33F5A85AA82A@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Mon, 8 May 2006 16:10:25 +0200 To: Ali Fessi X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nsis Subject: [NSIS] Re: Comments to the NATFW NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, Thanks for the comments, we gonna look at them soon and will come back to you if necessary. Thanks, Martin Am 08.05.2006 um 14:28 schrieb Ali Fessi: > Hi Martin and all NATFW NSLP co-authors, > > you can find some comments on the NATFW NSLP draft on: > > http://net.informatik.uni-tuebingen.de/fileadmin/RI/members/fessi/ > IETF/draft-ietf-nsis-nslp-natfw-11-ali.doc > > just few cents: > > - some of the comments are editorial > - I think many critical issues have been already discussed on the > mailing list. > - IMHO, the "Security Considerations" section still needs some > revision; the discussions on the mailing list could be used as > input for the revision. > > Have a good day, > Ali > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 11:01:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7EY-00077L-LJ; Mon, 08 May 2006 11:01:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7EX-00075N-5f for nsis@ietf.org; Mon, 08 May 2006 11:01:13 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7EU-0005ck-DJ for nsis@ietf.org; Mon, 08 May 2006 11:01:13 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 98DCD1BAC4D; Mon, 8 May 2006 16:54:28 +0200 (CEST) In-Reply-To: <60367.24.199.92.165.1145650000.squirrel@mail.piranho.net> References: <60367.24.199.92.165.1145650000.squirrel@mail.piranho.net> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Mon, 8 May 2006 17:01:07 +0200 To: Henning Peters X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Henning, Am 21.04.2006 um 22:06 schrieb Henning Peters: > Dear WG, dear NAT/Firewall NSLP authors, > > NAT/Firewall NSLP is a quite stable and usable protocol. There is > running > code already available that covers broad aspects of its functionality. > This proves at least that from an complexity and functional > viewpoint it Good to hear that! > can be considered feasible. Still, I find that some parts of the > spec can > be improved. Here, I would like to present my concerns connected to > LE-MRM/DTINFO that I developed during working on our implementation. Comments and suggestions are always welcome. > > shortcut: the questions related to WG discussion are at 4). > > 1) Confusing directions > > Most notable, the directions are a bit confusing in this object. > src port > is data sender (DS) port, dst port is data receiver (DR) port. DR > port is > subject of rewrite, whereas DS port specifies the data sender. I would > appreciate avoiding the term source and destination in this > context, this > would also leverage the positioning issue (see later *** when > discussing > the message format that confusely destination port is positioned > before > source port). While the naming is technically correct, I have to admit that it is confusing. So, I would suggest to change the names directly to what you have proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This is then inline with the naming of 'data sender's IP address' in the same object. > > Anyway, I will refer to DS port and DR port in the following. > > 2) LE-MRM / DTINFO ports > > After introduction of LE-MRM (loose end message routing method) to the > spec last year it was found that NAT traversal in NAPTs is broken as > LE-MRM does not carry port information. Ports are considered as not > part > of GIST routing and therefore omitted from MRI. There are two things to differentiate: NAPT support is not broken in the NATFW NSLP and whether NAPT traversal of GIST is broken when using LE-MRM is a different story that depends on the view point. My concern here is about why we need a GIST/LE-MRM NAPT traversal mechanism? When there is a NAT on your side of the network that is not NATFW NSLP enabled you anyway need to fall back to all the other workarounds, such as STUN, TURN, or other tricks. > > To compensate this DTINFO object was enhanced later with the port > information that was previously accessable in PC-MRM (signaling the > wrong > way) MRI. I believe that the current approach is not a good design There is non compensation needed, because GIST carries all information necessary for the message routing and the DTINFO object carries information about the later expected data flow. That are basically two different things: The message routing information and the expected data flow. > decision as GIST NAT traversal would be rendered broken. GIST NAT > traversal is crucial as we cannot assume a domainwide deployment of > NAT/Firewall NSLP instantly. I would appreciate a deployable over a > 100% > clean solution as deployment will be very crucial to NAT/Firewall NSLP > success anyway. I do not see the applicability given for the GIST with LE-MRM and NAT traversal. I probably need a good example why it is needed. > > See Martin's and my discussion in the issue tracker: > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 > > Actually, only the DR port and protocol field is needed for NAT > traversal > as REA/LE-MRM needs only a one-sided translation. > > 3) DTINFO message format > > The message format of the current solution is a bit confusing and > lacks > IPv6 support (DTINFOv6 object was removed in previous draft). Let > me start > with its figure: The DTINFO_IPV6 object has been removed since there is no IPv6 NAT and the usage of NAT-PT seems to be deprecated. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I|P|S| reserved | dest prefix | protocol | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > (***): dst port number [DR] | src port number [DS] : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : IPsec SPI : > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | data sender's IPv4 address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The purpose of this object is two-fold: > > - specify data sender during REA (aka: the cone-ness of the NAT) > > - supply DR port/protocol for NAT traversal > > Unfortunately, the draft heavily mixes and overloads these two > different > semantical aspects in this object. Specifically, I see following > issues: > > a) The P flag specifies whether port numbers are present or not. This > means that either both ports are present or none. Confusely, DR > port and > DS port cover different semantic aspects: > > DS port specifies the data sender, DR port is necessary for NAT > traversal. > A single flag to enable/disable two fields with different semantical > meaning can be problematic. I makes sense to either enable usage of ports or not. However, if ports are enabled you still can wildcard the DS port. This makes some sense from the point of whether your policy rule to be installed in the device covers port numbers or not. > > b) The I flag specifies whether the protocol field should be > interpreted > or not. The protocol defines the protocol used for above mentioned > ports > if the P flag is set aswell. Although the ports are of different > semantical meaning, the protocol covers both equally. > > I am not sure whether this semantical overloading may introduce new > problems, at least this limits flexibility compared to PC-MRM case > where a > protocol can be set in MRI and in DTINFO independently. DTINFO and PC-MRM cannot be used at the same time. *BUT* this is not specified in the draft :-) I will fix this. > > c) DTINFO object might be used for firewall signaling scenarios. But > LE-MRM can only cover NAT-only scenarios. That means that the NR > has to > know the scenario in advance to choose between PC-MRM and LE-MRM > signaling. The more intelligence is put into NR the more it evolves > to a > probing NR. Right, NR needs to choose carefully in what scenario it is. But the DTINFO object is not useful in firewall only scenarios, since those messages are anyway carried using the PC-MRM. > > A probing NR sounds to me a bit like the situations BEHAVE working > group > deal with; this is not the situation I would like to see NAT/ > Firewall NSLP > in. I think that our network states can be used more flexibly to > assist > the NR better. The NR should not care about the network, but only > give the > definitions that the network should adapt to. I would prefer a different way of deciding whether the NR is NATed or firewalled only. However, until now there has been now good proposal how to avoid this. Suggestions are welcome. > > Surely, this is a design decision that needs WG consensus. > > d) DTINFO object MUST be included when using LE-MRM as NAT > traversal is > not possible as long as DR port is not available. Therefore, following > paragraphs might need correction: > >> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message >> when using the LE-MRM. The LE-MRM does not include enough > > also: > >> When the data sender's address information is known in advance the >> NI+ >> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as >> described >> above). Already noted this. > > 4) I hope I pointed out that a discussion of following points in > the WG is > necessary: > > - How much intelligence should have the NR -> shall the network > handle the > deployment sceario or should the NR know/probe the network scenario? As said, I'm open for suggestions! > > - Is a broken GIST NAT traversal worth giving up a 100% clean MRM > design? I still lack the real usage scenario for GIST with LE-MRM NAT traversal. > > The message format issues heavily depend on these discussions, > therefore I > would rather like to delay the message format design until both > questions > gained consensus. > > I also appreciate any feedback on our NAT/Firewall NSLP implementation > available at: > > http://user.informatik.uni-goettingen.de/~nsis/ I hope to get some time for checking this out. > > Thank you for your attention, Thanks a lot for the comments! > Henning Peters > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 08 13:10:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9En-0001DV-0G; Mon, 08 May 2006 13:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9El-0001DQ-F8 for nsis@ietf.org; Mon, 08 May 2006 13:09:35 -0400 Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fd9Ek-00043v-1Y for nsis@ietf.org; Mon, 08 May 2006 13:09:35 -0400 Received: (qmail 13583 invoked from network); 8 May 2006 17:09:32 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 8 May 2006 17:09:32 -0000 Received: from 24.199.92.165 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Mon, 8 May 2006 13:09:32 -0400 (EDT) Message-ID: <42855.24.199.92.165.1147108172.squirrel@mail.piranho.net> In-Reply-To: <20060508074047.GA25999@mafr.de> References: <20060508074047.GA25999@mafr.de> Date: Mon, 8 May 2006 13:09:32 -0400 (EDT) Subject: Re: [NSIS] NATFW and multihoming From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, just a comment on the NATFW statemachine draft: > Good, then the NATFW state machine draft should be fixed, that's what > confused me a bit. The NR's SESSION state needs another timer that sends > refresh REAs regularly. The NR's tg_REA will result in REA_WAITRESP state, and if a successfull response is received, in REA state (not SESSION). The REA state defines REFRESH timers: >>> ----------- State: REA Entry: ResetCounter(REA); StartTimer(REFRESH); Exit : StopTimer(RESPONSE); StopTimer(REFRESH); ----------- <<< http://www.ietf.org/internet-drafts/draft-werner-nsis-natfw-nslp-statemachine-02.txt > That's not completely decided yet, but it could be part of my diploma > thesis. At the moment I'm trying to get into the topic, reading some of > the NSIS drafts and related work. Great! Henning Peters _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 10 05:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkY4-00016K-63; Wed, 10 May 2006 05:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdkY2-00016A-QE for nsis@ietf.org; Wed, 10 May 2006 04:59:58 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdkY0-0002ZJ-Na for nsis@ietf.org; Wed, 10 May 2006 04:59:58 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4A8xenY002181; Wed, 10 May 2006 09:59:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OlkEid: 8884162386E8EBA0AB9E034F9CA3F58219AC1FC2 Content-class: urn:content-classes:message Subject: RE: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Wed, 10 May 2006 09:59:39 +0100 Message-ID: Thread-Topic: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Thread-Index: AcZ0EBJ0xw3xHEV8RFiPe7y5Oqihpw== From: "Hancock, Robert" To: "Martin Stiemerling" , "Henning Peters" X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi all,=20 i'm still trying to get my head round sections 3.8.2 and 3.8.7 of=20 the spec (which i think is what most of the thread below is about).=20 however, i do have a specific comment about the applicability of the=20 LE-MRM and PC-MRM for various types of scenario. i'll say in advance=20 that i'm not 100% certain that the LE-MRM definition is right;=20 however, the discussion below is not persuading me that it is wrong.=20 i'll try to explain why: from a GIST perspective, the purpose of the LE-MRM is to allow an NSLP at an end host to talk to the 'edge' of the network and to get signalling messages back. from that point of view, no port numbers are needed at the GIST level, because there are no port numbers associated with the concept 'edge of the network'. routing state can be quite happily created at NATs along the path [how? see below] and GIST=20 messages can be sent backwards and forwards as the NSLP requires. it turns out that the NATFW NSLP may need a port number for NATFW purposes; specifically, that the external address that gets allocated may actually be a {address, port} pair, if the NAT is doing address sharing [if i understand it right ...]. However, in this particular case, it's vital that the {address, port} information is *not* carried at the GIST level, since it's vital that these are *not* translated on the way back to the end host - the end-host wants these unmodified so it can advertise them in the public network. so {address, port} have to be carried at the NSLP level (where other funny processing also takes place on them). the question then arises whether other NSLPs might want to use the LE-MRM and might need to have port numbers translated for them if=20 the signalling path went through a NAT. I can't assess that either=20 way at the moment; however, I can say that the QoS-NSLP is not a=20 valid example. if the QoS-NSLP wants to use some sort of proxy mode,=20 then it should use the upstream PC-MRM, not the LE-MRM. this is=20 because the QoS-NSLP talks about flows, not about network edges. if the QoS-NSLP wanted to manage QoS for something which wasn't a=20 flow but which was bound to a network edge for some reason, then the LE-MRM might be appropriate - but then there would be no port numbers involved anyway. and i think that the same line of reasoning would be applied to other NSLPs also. there remains the question of how GIST gets LE-MRM-routed traffic through a NAT. i think there are two cases here: *) if the NAT hosts the NSLP in question, it is a non-issue. the signalling traffic is presented to GIST by the NSLP separately on each interface, and the NSLP is responsible for choosing the MRI/SID/NSLP to pick out the routing state towards the right peer. *) if the NAT does not host the NSLP in question, GIST has to do MRI/NLI/SCD re-writing to get the Query/Response messages backwards and forwards correctly. no GIST routing state gets established, but NAT bindings need to be established for the signalling traffic=20 itself. but I don't see this requiring access to information that might be carried in the NSLP; the NAT can use the SID or the UDP=20 source port from the Query as keys for its binding table; the=20 former we assume to be unique and the latter can be rewritten. summary: at the moment, I think that the LE-MRM is ok. However, it's a subtle subject and it's possible that I haven't understood all the concerns. I'm also not certain at the moment that the way the NATFW NSLP does things like proxy REA are correct - still thinking ... cheers, r. > -----Original Message-----=20 > From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de]=20 > Sent: 08 May 2006 16:01=20 > To: Henning Peters=20 > Cc: nsis@ietf.org=20 > Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns=20 >=20 >=20 > Hi Henning,=20 >=20 >=20 > Am 21.04.2006 um 22:06 schrieb Henning Peters:=20 >=20 > > Dear WG, dear NAT/Firewall NSLP authors,=20 > >=20 > > NAT/Firewall NSLP is a quite stable and usable protocol. There is =20 > > running=20 > > code already available that covers broad aspects of its=20 > functionality.=20 > > This proves at least that from an complexity and functional =20 > > viewpoint it=20 >=20 > Good to hear that!=20 >=20 > > can be considered feasible. Still, I find that some parts of the =20 > > spec can=20 > > be improved. Here, I would like to present my concerns connected to=20 > > LE-MRM/DTINFO that I developed during working on our implementation. >=20 > Comments and suggestions are always welcome.=20 >=20 > >=20 > > shortcut: the questions related to WG discussion are at 4).=20 > >=20 > > 1) Confusing directions=20 > >=20 > > Most notable, the directions are a bit confusing in this object. =20 > > src port=20 > > is data sender (DS) port, dst port is data receiver (DR) port. DR =20 > > port is=20 > > subject of rewrite, whereas DS port specifies the data=20 > sender. I would=20 > > appreciate avoiding the term source and destination in this =20 > > context, this=20 > > would also leverage the positioning issue (see later *** when =20 > > discussing=20 > > the message format that confusely destination port is positioned =20 > > before=20 > > source port).=20 >=20 > While the naming is technically correct, I have to admit that it is =20 > confusing.=20 > So, I would suggest to change the names directly to what you have=20 > proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This =20 > is then=20 > inline with the naming of 'data sender's IP address' in the=20 > same object.=20 >=20 > >=20 > > Anyway, I will refer to DS port and DR port in the following.=20 > >=20 > > 2) LE-MRM / DTINFO ports=20 > >=20 > > After introduction of LE-MRM (loose end message routing=20 > method) to the=20 > > spec last year it was found that NAT traversal in NAPTs is broken as > > LE-MRM does not carry port information. Ports are=20 > considered as not =20 > > part=20 > > of GIST routing and therefore omitted from MRI.=20 >=20 > There are two things to differentiate: NAPT support is not=20 > broken in the=20 > NATFW NSLP and whether NAPT traversal of GIST is broken when using=20 > LE-MRM is a different story that depends on the view point.=20 >=20 > My concern here is about why we need a GIST/LE-MRM NAPT traversal=20 > mechanism? When there is a NAT on your side of the network that is=20 > not NATFW NSLP enabled you anyway need to fall back to all the=20 > other workarounds, such as STUN, TURN, or other tricks.=20 >=20 >=20 > >=20 > > To compensate this DTINFO object was enhanced later with the port=20 > > information that was previously accessable in PC-MRM=20 > (signaling the =20 > > wrong=20 > > way) MRI. I believe that the current approach is not a good design=20 >=20 > There is non compensation needed, because GIST carries all information > necessary for the message routing and the DTINFO object carries=20 > information about the later expected data flow. That are basically two > different things: The message routing information and the expected=20 > data flow.=20 >=20 > > decision as GIST NAT traversal would be rendered broken. GIST NAT=20 > > traversal is crucial as we cannot assume a domainwide deployment of=20 > > NAT/Firewall NSLP instantly. I would appreciate a=20 > deployable over a =20 > > 100%=20 > > clean solution as deployment will be very crucial to=20 > NAT/Firewall NSLP=20 > > success anyway.=20 >=20 > I do not see the applicability given for the GIST with LE-MRM and NAT=20 > traversal. I probably need a good example why it is needed.=20 >=20 > >=20 > > See Martin's and my discussion in the issue tracker:=20 > > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50=20 > >=20 > > Actually, only the DR port and protocol field is needed for NAT =20 > > traversal=20 > > as REA/LE-MRM needs only a one-sided translation.=20 > >=20 > > 3) DTINFO message format=20 > >=20 > > The message format of the current solution is a bit confusing and =20 > > lacks=20 > > IPv6 support (DTINFOv6 object was removed in previous draft). Let =20 > > me start=20 > > with its figure:=20 >=20 > The DTINFO_IPV6 object has been removed since there is no IPv6 NAT=20 > and the usage of NAT-PT seems to be deprecated.=20 >=20 > >=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > |I|P|S| reserved | dest prefix | =20 > protocol |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > (***): dst port number [DR] | src port number=20 > [DS] :=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > : IPsec SPI =20 > :=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > > | data sender's IPv4 address =20 > |=20 > > =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 > >=20 > > The purpose of this object is two-fold:=20 > >=20 > > - specify data sender during REA (aka: the cone-ness of the NAT)=20 > >=20 > > - supply DR port/protocol for NAT traversal=20 > >=20 > > Unfortunately, the draft heavily mixes and overloads these two =20 > > different=20 > > semantical aspects in this object. Specifically, I see following =20 > > issues:=20 > >=20 > > a) The P flag specifies whether port numbers are present or=20 > not. This=20 > > means that either both ports are present or none. Confusely, DR =20 > > port and=20 > > DS port cover different semantic aspects:=20 > >=20 > > DS port specifies the data sender, DR port is necessary for NAT =20 > > traversal.=20 > > A single flag to enable/disable two fields with different semantical > > meaning can be problematic.=20 >=20 > I makes sense to either enable usage of ports or not.=20 > However, if ports=20 > are enabled you still can wildcard the DS port. This makes some sense=20 > from the point of whether your policy rule to be installed in=20 > the device=20 > covers port numbers or not.=20 >=20 > >=20 > > b) The I flag specifies whether the protocol field should be =20 > > interpreted=20 > > or not. The protocol defines the protocol used for above mentioned =20 > > ports=20 > > if the P flag is set aswell. Although the ports are of different=20 > > semantical meaning, the protocol covers both equally.=20 > >=20 > > I am not sure whether this semantical overloading may introduce new=20 > > problems, at least this limits flexibility compared to PC-MRM case =20 > > where a=20 > > protocol can be set in MRI and in DTINFO independently.=20 >=20 > DTINFO and PC-MRM cannot be used at the same time. *BUT* this is=20 > not specified in the draft :-)=20 > I will fix this.=20 >=20 > >=20 > > c) DTINFO object might be used for firewall signaling scenarios. But > > LE-MRM can only cover NAT-only scenarios. That means that the NR =20 > > has to=20 > > know the scenario in advance to choose between PC-MRM and LE-MRM=20 > > signaling. The more intelligence is put into NR the more it=20 > evolves =20 > > to a=20 > > probing NR.=20 >=20 > Right, NR needs to choose carefully in what scenario it is. But the =20 > DTINFO object=20 > is not useful in firewall only scenarios, since those messages are =20 > anyway=20 > carried using the PC-MRM.=20 >=20 > >=20 > > A probing NR sounds to me a bit like the situations BEHAVE working =20 > > group=20 > > deal with; this is not the situation I would like to see NAT/=20 > > Firewall NSLP=20 > > in. I think that our network states can be used more flexibly to =20 > > assist=20 > > the NR better. The NR should not care about the network, but only =20 > > give the=20 > > definitions that the network should adapt to.=20 >=20 > I would prefer a different way of deciding whether the NR is NATed or=20 > firewalled only. However, until now there has been now good proposal=20 > how to avoid this. Suggestions are welcome.=20 >=20 > >=20 > > Surely, this is a design decision that needs WG consensus.=20 > >=20 > > d) DTINFO object MUST be included when using LE-MRM as NAT =20 > > traversal is=20 > > not possible as long as DR port is not available.=20 > Therefore, following=20 > > paragraphs might need correction:=20 > >=20 > >> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message=20 > >> when using the LE-MRM. The LE-MRM does not include enough=20 > >=20 > > also:=20 > >=20 > >> When the data sender's address information is known in=20 > advance the =20 > >> NI+=20 > >> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as =20 > >> described=20 > >> above).=20 >=20 > Already noted this.=20 >=20 > >=20 > > 4) I hope I pointed out that a discussion of following points in =20 > > the WG is=20 > > necessary:=20 > >=20 > > - How much intelligence should have the NR -> shall the network =20 > > handle the=20 > > deployment sceario or should the NR know/probe the network scenario? >=20 > As said, I'm open for suggestions!=20 >=20 > >=20 > > - Is a broken GIST NAT traversal worth giving up a 100% clean MRM =20 > > design?=20 >=20 > I still lack the real usage scenario for GIST with LE-MRM NAT=20 > traversal.=20 >=20 > >=20 > > The message format issues heavily depend on these discussions, =20 > > therefore I=20 > > would rather like to delay the message format design until both =20 > > questions=20 > > gained consensus.=20 > >=20 > > I also appreciate any feedback on our NAT/Firewall NSLP=20 > implementation=20 > > available at:=20 > >=20 > > http://user.informatik.uni-goettingen.de/~nsis/=20 >=20 > I hope to get some time for checking this out.=20 >=20 > >=20 > > Thank you for your attention,=20 >=20 > Thanks a lot for the comments!=20 >=20 > > Henning Peters=20 > >=20 > >=20 > > _______________________________________________=20 > > nsis mailing list=20 > > nsis@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 >=20 > _______________________________________________=20 > nsis mailing list=20 > nsis@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/nsis=20 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 10 06:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdlsv-0002WE-E9; Wed, 10 May 2006 06:25:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdlsu-0002TZ-6h for nsis@ietf.org; Wed, 10 May 2006 06:25:36 -0400 Received: from smtp.dei.uc.pt ([193.137.203.228] helo=smtp2.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdlss-00064Z-GM for nsis@ietf.org; Wed, 10 May 2006 06:25:36 -0400 Received: from [10.3.1.136] (din-cisuc136.dei.uc.pt [10.3.1.136]) (authenticated bits=0) by smtp2.dei.uc.pt (8.13.6/8.13.6) with ESMTP id k4AAP7iN018272 for ; Wed, 10 May 2006 11:25:08 +0100 Message-ID: <4461BF7F.60300@student.dei.uc.pt> Date: Wed, 10 May 2006 11:25:03 +0100 From: David Palma User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis@ietf.org X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-4.184, required 3, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.21) X-FCTUC-DEI-SIC-MailScanner-From: palma@student.dei.uc.pt X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [NSIS] Packet Classifier in QoS NSLP X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1212876242==" Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1212876242== Content-Type: multipart/alternative; boundary="------------000500010102020100040307" This is a multi-part message in MIME format. --------------000500010102020100040307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, In QoS NSLP draft (v10) the Packet Classifier object is described as below: 5.1.3.5. PACKET_CLASSIFIER Type: Packet Classifier Length: Variable Value: Contains a 2 byte value indicating the MRM being used, and then additional variable length MRM-specific data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Routing-Method | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // Method-specific classifier data (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the basic path-coupled routing MRM, the method specific data is two bytes long and consists of a set of flags: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If I am understanding the above text correctly, the Packet Classifier should have a short for Loose End routing and 2 shorts for Path Coupled. So I assume that will always have Length 1 (1 word) to both routing methods right? The word "variable" to the length confuses me a little bit. Are my assumptions correct? Regards, David Palma --------------000500010102020100040307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Hi all,
 
In QoS NSLP draft (v10) the Packet Classifier object is described as below:
 
5.1.3.5.  PACKET_CLASSIFIER
 
   Type: Packet Classifier
 
   Length: Variable
 
   Value: Contains a 2 byte value indicating the MRM being used, and
   then additional variable length MRM-specific data
 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Message-Routing-Method     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   //          Method-specific classifier data (variable)         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
   For the basic path-coupled routing MRM, the method specific data is
   two bytes long and consists of a set of flags:
 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|Y|P|T|F|S|A|B|   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
 
If I am understanding the above text correctly, the Packet Classifier should have a short for Loose End routing and 2 shorts for Path Coupled.
So I assume that will always have Length 1 (1 word) to both routing methods right? The word "variable" to the length confuses me a little bit.
Are my assumptions correct?
 
Regards,
 
David Palma
--------------000500010102020100040307-- --===============1212876242== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============1212876242==-- From nsis-bounces@ietf.org Wed May 10 14:33:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtUQ-0002r1-EU; Wed, 10 May 2006 14:32:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdtUP-0002qw-AM for nsis@ietf.org; Wed, 10 May 2006 14:32:49 -0400 Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FdtUL-0002lv-6g for nsis@ietf.org; Wed, 10 May 2006 14:32:49 -0400 Received: (qmail 22883 invoked from network); 10 May 2006 18:32:37 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 10 May 2006 18:32:37 -0000 Received: from 24.199.92.165 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Wed, 10 May 2006 14:32:37 -0400 (EDT) Message-ID: <37901.24.199.92.165.1147285957.squirrel@mail.piranho.net> In-Reply-To: References: Date: Wed, 10 May 2006 14:32:37 -0400 (EDT) Subject: RE: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Cc: "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert, good summary. Though, I am missing one point: In a hierarchical NAT scenario, is it sufficient only talk to the edge to make a reservation? An example: A:NI --[ B:NF(NAT) --[ C:NF(NAT) --- D:NR 1) <=========================REA 2) RESPONSE====================> 3) CREATE====> ============> X =========> X...marks the problem loc. 4) <========== <============= <==RESPONSE Assumption: In this scenario I assume that a REA(1) message with LE-MRM does only talk to the edge and traverses C seemlessly. C may trigger a reservation, read the flow, but will not change any data of the message exchange between B and D. For an upcoming CREATE(3) message from A it seems to be necessary for B to previously store the IP address of the C during REA(1) operation, because B has to map between different session IDs based upon the external port reservations. It also has to know the external port reservation of C. Thus, in respect to NAT behavior, B has to translate the IP and TCP/UDP layer and update MRI accordingly to match the new destination address/port. But: how does B know about a valid destination port at C? In my view all NAT have to do a mapping unrelated to session ID, but on IP address and port, because REA and CREATE messages are different sessions. Thus, they need a mechanism to signal their external port reservation to the upstream NAT, this is not possible without modifying the exchange between B and D. Thus my previously made assumption is wrong. Hence, I asked Martin to give me a port field, it was introduced in last fall. The whole issue is complicated, so I am not 100% sure whether I might not miss a point. If I might be right, then I have following concern: LE-MRM is not only about "talking to the edge". Therefore, I find it sensible to put the port into LE-MRM. Please keep in mind that I might be biased, because I want to keep my codebase small ;). Currently the port resides in DTINFO object. So, if signaled with LE-MRM one has to use this field, when using PC-MRM one has to use MRI port although the port is here needed for the same purpose: giving the upstream NAT information about the local NATs port reservation. Sure, in PC-MRM this information is overloaded the same way as NAT is already overloading identifiers. Henning Hancock, Robert sagte Mi, 10.05.2006, 04:59: > hi all, > > i'm still trying to get my head round sections 3.8.2 and 3.8.7 of > the spec (which i think is what most of the thread below is about). > > however, i do have a specific comment about the applicability of the > LE-MRM and PC-MRM for various types of scenario. i'll say in advance > that i'm not 100% certain that the LE-MRM definition is right; > however, the discussion below is not persuading me that it is wrong. > i'll try to explain why: > > from a GIST perspective, the purpose of the LE-MRM is to allow an > NSLP at an end host to talk to the 'edge' of the network and to > get signalling messages back. from that point of view, no port numbers > are needed at the GIST level, because there are no port numbers > associated > with the concept 'edge of the network'. routing state can be quite > happily created at NATs along the path [how? see below] and GIST > messages can be sent backwards and forwards as the NSLP requires. > > it turns out that the NATFW NSLP may need a port number for NATFW > purposes; specifically, that the external address that gets allocated > may actually be a {address, port} pair, if the NAT is doing address > sharing [if i understand it right ...]. However, in this particular > case, it's vital that the {address, port} information is *not* carried > at the GIST level, since it's vital that these are *not* translated > on the way back to the end host - the end-host wants these unmodified > so it can advertise them in the public network. so {address, port} have > to be carried at the NSLP level (where other funny processing also > takes place on them). > > the question then arises whether other NSLPs might want to use the > LE-MRM and might need to have port numbers translated for them if > the signalling path went through a NAT. I can't assess that either > way at the moment; however, I can say that the QoS-NSLP is not a > valid example. if the QoS-NSLP wants to use some sort of proxy mode, > then it should use the upstream PC-MRM, not the LE-MRM. this is > because the QoS-NSLP talks about flows, not about network edges. > if the QoS-NSLP wanted to manage QoS for something which wasn't a > flow but which was bound to a network edge for some reason, then the > LE-MRM might be appropriate - but then there would be no port numbers > involved anyway. and i think that the same line of reasoning would > be applied to other NSLPs also. > > there remains the question of how GIST gets LE-MRM-routed traffic > through a NAT. i think there are two cases here: > *) if the NAT hosts the NSLP in question, it is a non-issue. the > signalling traffic is presented to GIST by the NSLP separately > on each interface, and the NSLP is responsible for choosing the > MRI/SID/NSLP to pick out the routing state towards the right peer. > > *) if the NAT does not host the NSLP in question, GIST has to do > MRI/NLI/SCD re-writing to get the Query/Response messages backwards > and forwards correctly. no GIST routing state gets established, but > NAT bindings need to be established for the signalling traffic > itself. but I don't see this requiring access to information that > might be carried in the NSLP; the NAT can use the SID or the UDP > source port from the Query as keys for its binding table; the > former we assume to be unique and the latter can be rewritten. > > summary: at the moment, I think that the LE-MRM is ok. However, it's > a subtle subject and it's possible that I haven't understood all the > concerns. I'm also not certain at the moment that the way the NATFW > NSLP does things like proxy REA are correct - still thinking ... > > > cheers, > > r. > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: 08 May 2006 16:01 >> To: Henning Peters >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns >> >> >> Hi Henning, >> >> >> Am 21.04.2006 um 22:06 schrieb Henning Peters: >> >> > Dear WG, dear NAT/Firewall NSLP authors, >> > >> > NAT/Firewall NSLP is a quite stable and usable protocol. There is >> > running >> > code already available that covers broad aspects of its >> functionality. >> > This proves at least that from an complexity and functional >> > viewpoint it >> >> Good to hear that! >> >> > can be considered feasible. Still, I find that some parts of the >> > spec can >> > be improved. Here, I would like to present my concerns connected to >> > LE-MRM/DTINFO that I developed during working on our implementation. > >> >> Comments and suggestions are always welcome. >> >> > >> > shortcut: the questions related to WG discussion are at 4). >> > >> > 1) Confusing directions >> > >> > Most notable, the directions are a bit confusing in this object. >> > src port >> > is data sender (DS) port, dst port is data receiver (DR) port. DR >> > port is >> > subject of rewrite, whereas DS port specifies the data >> sender. I would >> > appreciate avoiding the term source and destination in this >> > context, this >> > would also leverage the positioning issue (see later *** when >> > discussing >> > the message format that confusely destination port is positioned >> > before >> > source port). >> >> While the naming is technically correct, I have to admit that it is >> confusing. >> So, I would suggest to change the names directly to what you have >> proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This >> is then >> inline with the naming of 'data sender's IP address' in the >> same object. >> >> > >> > Anyway, I will refer to DS port and DR port in the following. >> > >> > 2) LE-MRM / DTINFO ports >> > >> > After introduction of LE-MRM (loose end message routing >> method) to the >> > spec last year it was found that NAT traversal in NAPTs is broken as > >> > LE-MRM does not carry port information. Ports are >> considered as not >> > part >> > of GIST routing and therefore omitted from MRI. >> >> There are two things to differentiate: NAPT support is not >> broken in the >> NATFW NSLP and whether NAPT traversal of GIST is broken when using >> LE-MRM is a different story that depends on the view point. >> >> My concern here is about why we need a GIST/LE-MRM NAPT traversal >> mechanism? When there is a NAT on your side of the network that is >> not NATFW NSLP enabled you anyway need to fall back to all the >> other workarounds, such as STUN, TURN, or other tricks. >> >> >> > >> > To compensate this DTINFO object was enhanced later with the port >> > information that was previously accessable in PC-MRM >> (signaling the >> > wrong >> > way) MRI. I believe that the current approach is not a good design >> >> There is non compensation needed, because GIST carries all information > >> necessary for the message routing and the DTINFO object carries >> information about the later expected data flow. That are basically two > >> different things: The message routing information and the expected >> data flow. >> >> > decision as GIST NAT traversal would be rendered broken. GIST NAT >> > traversal is crucial as we cannot assume a domainwide deployment of >> > NAT/Firewall NSLP instantly. I would appreciate a >> deployable over a >> > 100% >> > clean solution as deployment will be very crucial to >> NAT/Firewall NSLP >> > success anyway. >> >> I do not see the applicability given for the GIST with LE-MRM and NAT >> traversal. I probably need a good example why it is needed. >> >> > >> > See Martin's and my discussion in the issue tracker: >> > https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 >> > >> > Actually, only the DR port and protocol field is needed for NAT >> > traversal >> > as REA/LE-MRM needs only a one-sided translation. >> > >> > 3) DTINFO message format >> > >> > The message format of the current solution is a bit confusing and >> > lacks >> > IPv6 support (DTINFOv6 object was removed in previous draft). Let >> > me start >> > with its figure: >> >> The DTINFO_IPV6 object has been removed since there is no IPv6 NAT >> and the usage of NAT-PT seems to be deprecated. >> >> > >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > |I|P|S| reserved | dest prefix | >> protocol | >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > (***): dst port number [DR] | src port number >> [DS] : >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > : IPsec SPI >> : >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | data sender's IPv4 address >> | >> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > >> > The purpose of this object is two-fold: >> > >> > - specify data sender during REA (aka: the cone-ness of the NAT) >> > >> > - supply DR port/protocol for NAT traversal >> > >> > Unfortunately, the draft heavily mixes and overloads these two >> > different >> > semantical aspects in this object. Specifically, I see following >> > issues: >> > >> > a) The P flag specifies whether port numbers are present or >> not. This >> > means that either both ports are present or none. Confusely, DR >> > port and >> > DS port cover different semantic aspects: >> > >> > DS port specifies the data sender, DR port is necessary for NAT >> > traversal. >> > A single flag to enable/disable two fields with different semantical > >> > meaning can be problematic. >> >> I makes sense to either enable usage of ports or not. >> However, if ports >> are enabled you still can wildcard the DS port. This makes some sense >> from the point of whether your policy rule to be installed in >> the device >> covers port numbers or not. >> >> > >> > b) The I flag specifies whether the protocol field should be >> > interpreted >> > or not. The protocol defines the protocol used for above mentioned >> > ports >> > if the P flag is set aswell. Although the ports are of different >> > semantical meaning, the protocol covers both equally. >> > >> > I am not sure whether this semantical overloading may introduce new >> > problems, at least this limits flexibility compared to PC-MRM case >> > where a >> > protocol can be set in MRI and in DTINFO independently. >> >> DTINFO and PC-MRM cannot be used at the same time. *BUT* this is >> not specified in the draft :-) >> I will fix this. >> >> > >> > c) DTINFO object might be used for firewall signaling scenarios. But > >> > LE-MRM can only cover NAT-only scenarios. That means that the NR >> > has to >> > know the scenario in advance to choose between PC-MRM and LE-MRM >> > signaling. The more intelligence is put into NR the more it >> evolves >> > to a >> > probing NR. >> >> Right, NR needs to choose carefully in what scenario it is. But the >> DTINFO object >> is not useful in firewall only scenarios, since those messages are >> anyway >> carried using the PC-MRM. >> >> > >> > A probing NR sounds to me a bit like the situations BEHAVE working >> > group >> > deal with; this is not the situation I would like to see NAT/ >> > Firewall NSLP >> > in. I think that our network states can be used more flexibly to >> > assist >> > the NR better. The NR should not care about the network, but only >> > give the >> > definitions that the network should adapt to. >> >> I would prefer a different way of deciding whether the NR is NATed or >> firewalled only. However, until now there has been now good proposal >> how to avoid this. Suggestions are welcome. >> >> > >> > Surely, this is a design decision that needs WG consensus. >> > >> > d) DTINFO object MUST be included when using LE-MRM as NAT >> > traversal is >> > not possible as long as DR port is not available. >> Therefore, following >> > paragraphs might need correction: >> > >> >> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message >> >> when using the LE-MRM. The LE-MRM does not include enough >> > >> > also: >> > >> >> When the data sender's address information is known in >> advance the >> >> NI+ >> >> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as >> >> described >> >> above). >> >> Already noted this. >> >> > >> > 4) I hope I pointed out that a discussion of following points in >> > the WG is >> > necessary: >> > >> > - How much intelligence should have the NR -> shall the network >> > handle the >> > deployment sceario or should the NR know/probe the network scenario? > >> >> As said, I'm open for suggestions! >> >> > >> > - Is a broken GIST NAT traversal worth giving up a 100% clean MRM >> > design? >> >> I still lack the real usage scenario for GIST with LE-MRM NAT >> traversal. >> >> > >> > The message format issues heavily depend on these discussions, >> > therefore I >> > would rather like to delay the message format design until both >> > questions >> > gained consensus. >> > >> > I also appreciate any feedback on our NAT/Firewall NSLP >> implementation >> > available at: >> > >> > http://user.informatik.uni-goettingen.de/~nsis/ >> >> I hope to get some time for checking this out. >> >> > >> > Thank you for your attention, >> >> Thanks a lot for the comments! >> >> > Henning Peters >> > >> > >> > _______________________________________________ >> > nsis mailing list >> > nsis@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nsis >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 07:57:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9n5-00026C-PE; Thu, 11 May 2006 07:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9n4-000252-HO for nsis@ietf.org; Thu, 11 May 2006 07:57:10 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9n2-0005HM-52 for nsis@ietf.org; Thu, 11 May 2006 07:57:10 -0400 Received: from [84.163.3.253] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Fe9mw1UGp-0000jh; Thu, 11 May 2006 13:57:02 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id AF53C5E8476; Thu, 11 May 2006 13:56:45 +0200 (CEST) Date: Thu, 11 May 2006 13:56:45 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060511115645.GA22784@mafr.de> Mail-Followup-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [NSIS] NATFW message format X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, while reading section 4 (NATFW NSLP Message Components), I noticed the following minor issues: * The order the objects may appear in a message is not specified. If there is no fixed order, it should be stated explicitly. It could also be noted that only one object of a type may appear in a message. * It would be nice to have preliminary object type IDs to make sure experimental implementations are compatible. The message types already have IDs. * The "Forward" treatment is never used in the draft. Is there a use case where it is necessary? * The NATFW_LT object is named "session lifetime", but sections 4.3.[123] just use "lifetime". * The NATFW_INFO object has a 16 bit object type, while the common object header only allows for 12 bits. * The NATFW_DTINFO_IPv4 object seems to have a variable length, judging from text and diagram, but the length is specified as 3 words. * The NATFW_TRACE's hop count seems to be unnecessary. The number of hops can be derived from the number of IP addresses in this object. * Is the NATFW_CREDENTIAL's length field really necessary? A concrete credential type could still decide to use these bits as a length field to support padding. For other credential types it might not be needed. If the credential data is a multiple of 32 bit, the leading 16 bit could be used as padding. * Would a version number in the message header make sense? Thanks for reading, Matthias _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 08:34:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAMO-00034t-Pz; Thu, 11 May 2006 08:33:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAMN-00034n-ML for nsis@ietf.org; Thu, 11 May 2006 08:33:39 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9nX-0005HJ-FV for nsis@ietf.org; Thu, 11 May 2006 07:57:39 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fe9ed-0007n3-RF for nsis@ietf.org; Thu, 11 May 2006 07:48:32 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4BBm8Ct012101; Thu, 11 May 2006 12:48:13 +0100 Received: from [193.118.197.86] ([193.118.197.86]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 12:48:07 +0100 Message-ID: <44632477.2050604@roke.co.uk> Date: Thu, 11 May 2006 12:48:07 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: David Palma Subject: Re: [NSIS] Packet Classifier in QoS NSLP References: <4461BF7F.60300@student.dei.uc.pt> In-Reply-To: <4461BF7F.60300@student.dei.uc.pt> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2006 11:48:07.0843 (UTC) FILETIME=[C5571730:01C674F0] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: -2.6 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi David, David Palma wrote: > In QoS NSLP draft (v10) the Packet Classifier object is described as > below: [snip] > If I am understanding the above text correctly, the Packet Classifier > should have a short for Loose End routing and 2 shorts for Path > Coupled. > > So I assume that will always have Length 1 (1 word) to both routing > methods right? The word "variable" to the length confuses me a little > bit. > > Are my assumptions correct? The QoS NSLP does not make use of the GIST LE-MRM. It is only defined to use the PC-MRM. I thought I had added a statement about this in draft -10. Having had a quick check, I can't see it. This obviously needs clarifying in the draft. (Added to QoS NSLP issue tracker as issue 59: http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue59) regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 08:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAWd-0004ix-2U; Thu, 11 May 2006 08:44:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAWb-0004ip-Bc for nsis@ietf.org; Thu, 11 May 2006 08:44:13 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAWY-0007Iz-NE for nsis@ietf.org; Thu, 11 May 2006 08:44:13 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1C5AB1BAC4D; Thu, 11 May 2006 14:37:08 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW protocol/specification structure issues Date: Thu, 11 May 2006 14:44:06 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert and All, Am 02.05.2006 um 15:23 schrieb Hancock, Robert: > hi all, > > while reading the NATFW spec, i was continually tripped over by a > number > of partly editorial/partly structural issues, which made it quite hard > for me to get to grips with the protocol in a concrete way. Bad to know that there editorial/party structural issues BUT good to hear about them :-) Thanks! > > basically it seems to me that there is a good > *) high level description of what problem space the protocol attempts > to address and the design approach which has been taken > *) low level description of how individual messages are processed at > particular nodes > > but > it's hard to understand the protocol structure at an intermediate > level > - > in particular, how different messages depend on each other or have to > be processed consistently, or under what circumstances messages can be > processed totally independently. (i think this becomes most visible in > the discussion of REA-like messages that might create firewall state, > which everyone seems to find a bit confusing. it also shows up in > other > ways - for example, which messages control which state, how SIDs are > allocated, and so on.) the very start of the spec talks about there > being > two 'modes' but it doesn't really say what is the significance of > a particular mode being used (i.e. what the 'mode' concept really > means). > the document also talks about 'signalling exchanges' at several points > but doesn't really talk about what the boundaries of such exchanges > are. You are right about the report issues. > > [you can think of this as a comment on section 3.2. 3.2.3 describes > session lifecycles quite nicely, but the definition of a session > itself > is not given there. in other places, the session definition seems > to be > tied to the concept of application sessions, but I'm sure this isn't > valid in reality. For example, using a REA session as part of > speculatively > registering an external address might not correspond to any specific > application session, whereas another call flow might use both a REA > messaging and CREATE messaging - is this actually one session or two?] When talking about session we always refer to signaling session. Granted that the document is not very clear about this. There are two sessions created when using REA and afterwards CREATE. One for REA and one for CREATE. The NI+ may decided to uphold the signaling session for REA or delete it immediately after having received the CREATE message. This depends mainly on whether the NI+ is awaiting other incoming CREATE messages. > > i also find the NI/NI+/NR/NR+/DR/DS terminology confusing. (for > example, > sometimes the term 'NSIS initiator' refers to the NI+ (see for example I see. Do you find the terms NI/NI+/NR/NR+/DR/DS in general confusing or just the missing good introduction and straight forward usage? > the top of p41.) i also find the CREATE/REA terminology confusing as > mentioned by others, especially since the spec refers to 'request' > messages without saying explicitly what they are (so far as I could > see). Yes, you are right. The request message is not defined. This terminology seems to be a left over from the very beginning of the draft. Does anybody mind to change from "CREATE request" or "REA request" to solely "CREATE" or "REA"? Since the actually responses to those messages are anyway RESPONSE messages; so it should be clear what is meant. > > the following is my attempt to impose such an intermediate level > structure on the protocol. it would be interesting to know if it was > correct: > > *) the NATFW NSLP uses signalling sessions to manage state at > middleboxes Right. > > *) all the messages for a given session have the same SID and MRM/MRI > [modulo upstream/downstream setting]. the SIDs for different sessions > are > un-related. Right. > > *) a session has a specific lifetime, which is negotiated by all the > nodes taking part in the session at session creation, and can be > updated during session refresh Right. > > *) a session is iniated with a 'request' message (there are two > types). > The node at one end of the path which sends the first request is > called > the NSIS initiator (NI). Right. As said above I would favor of avoiding 'request' message and name them directly as CREATE and REA. NI definition is fine. > > *) a node at the other end of the path terminates the signalling and > replies to the request with a RESPONSE message. It is called the NSIS > responder (NR). Fine and I assume this implicitly includes to my answer about the terms NI/NI+/NR/NR+/DR/DS. You are in favour of removing the distinction between NI and NI+? > > *) all the other nodes are called forwarders (NFs). Ok. > > *) for the first type of session, the request is called CREATE and > the PC-MRM is used Right. > > *) for the second type of session, the request is called REA and the > LE-MRM is used. [I know this isn't consistent with 3.8.2; however, Right. > there are bits of 3.8.2 which I don't see how they could work in > the first place.] Can you point me precisely to the part? I assume that it is either incomplete or missing text, because this section go reworked (heavily) between -09 and -10. > > *) the NSLP state data is independent between different sessions. > [Actually > I am fairly sure this is wrong. However, I cannot work out what the > dependencies are!] The NSLP state data is independent for independent signaling sessions, i.e., two CREATEs. There is dependency for REA and CREATEs, which in my view not clearly described > > Clearly this doesn't capture all the details. What I'm not sure about > is whether it is consistent with all the details for proxy mode etc. > (However, if I find inconsistencies, at least it pins down which of > the > details I don't understand properly yet.) Good to hear from you about the inconsistencies, since those issues are hard to spot for me and the other authors. We are too deep in the matter. Things are very clear for me but I am one of the editors... > > In particular, it doesn't mention DS/DR issues directly. As I see it, > DS/DR show up because either > - it's easy to have the first session type where NI=DS (but this is > an artifact of GIST behaviour, not fundamental to the NSLP design), > but you can try NI=DR > - you have have NI=DR for the second session type, because the case > NI=DS is pointless. Yep, this needs some clarifications. > > And so on... > > I'll try to write up my more specific points in the near future. If > any of them don't make sense, at least what's written above may > clarify where my fundamental misunderstandings are. As said, good to hear about these issues! Actually, you have hit one of my major concerns on document structure and terminology. Typically, those issues are better spotted and described by people not directly editing the document. ;-) Many thanks! Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:02:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAoM-0007ID-CU; Thu, 11 May 2006 09:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAoK-0007I7-Qu for nsis@ietf.org; Thu, 11 May 2006 09:02:32 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAoI-0008MC-Bd for nsis@ietf.org; Thu, 11 May 2006 09:02:32 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 1776D1BAC4D; Thu, 11 May 2006 14:55:28 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1D9AE7B3-FC7F-4E82-826D-56B9F5B9CE03@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] comments on the handling of RESPONSE/TRACE/NOTIFY messages Date: Thu, 11 May 2006 15:02:26 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Robert and All, Am 02.05.2006 um 17:24 schrieb Hancock, Robert: > hi, > > these comments are most inspired by a reading of sections 4.3.3/4/5 > (additional cross references added where appropriate): > > i think all of these messages need slightly clearer specification > about what MRM is used and what direction they can be sent in. > > i assume that in reality all of these messages have to be sent > using the same MRM as the session was created with (by CREATE or > REA message). otherwise there is no guarantee that the routing > state to forward them exists. (note that the routing state is > keyed by MRM, so you cannot leave it unspecified.) [this affects > at least 4.3.5. I assume here that the TRACE does not create a > new session but traces an existing one.] You are right. Especially, TRACE is sent via an existing signaling session. > > also, I don't think the terminology 'upstream/downstream' is useful > here, since flows may not even exist yet (what do these terms mean > if you are sending a NOTIFY about a REA?) should the direction > just be described as 'towards NI' rather than 'upstream'? But Ok, you are right, especially people that are not completely NSIS-safe will have hard times in understanding it right. I see the 'towards NI' as a good candidate; This suits also the 'DR behind a NAT' case well, where REA must be used. It would read 'send REA with LE-MRM towards SDA'. > in fact > - is it clear that you can only NOTIFY in one direction? You can only NOTIFY in one direction, as it is defined in Section 3.8.5 Reporting Asynchronous Events: NOTIFY messages are sent hop-by-hop upstream towards NI until they reach NI. > - why are you only allowed to TRACE from the session owner? For simplicity it has been decided to allow TRACE only from the session owner. BUT: This has been decided as a preliminary semantics, since there have been requests to the WG about the TRACE semantics in general. The requests have been without larger responses. Long story short: The semantics of TRACE is quite young and we have not received anything else than "...this might be useful" from the WG. Anyway, I will send a separate email about the semantics of TRACE. > > I note (4.2.8) that the TRACE object can only hold one type of > IP address. How would this function in a mixed v4/6 environment > using NAT-PT? (is this an error condition?) Also, which IP address > is actually inserted - outgoing interface or incoming interface > of the message? NAT-PT: This was left out intentionally, because NAT-PT seems to be viewed as a bad idea in the IETF. The "what IP address is actually inserted" falls under the point I have raised above: Need input from the WG. (I will send an email, as said above). > > There are some oddities in the processing of RESPONSE messages. > In 3.2.2 ("Classification of RESPONSE Messages") it says that > 'Informational' is normally only used with NOTIFY messages. Does > this mean that a RESPONSE can be sent in response to a NOTIFY? No, A RESPONSE cannot be sent in a response to a NOTIFY. This will be clarified! > The scenario at the end of page 29 implies that a RESPONSE can > be generated as a result of a RESPONSE, but doesn't say which Good catch. This will be clarified that responses are only sent upstream. > direction this second RESPONSE is sent in; 3.2.1 says that RESPONSE > messages are only caused by CREATE/REA/NOTIFY. 3.2.1 says RESPONSES are only caused by CREATE/REA/TRACE! Many thanks for the good review Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAtZ-0001uv-9Q; Thu, 11 May 2006 09:07:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAtY-0001qq-4g for nsis@ietf.org; Thu, 11 May 2006 09:07:56 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAtX-0000CQ-Qo for nsis@ietf.org; Thu, 11 May 2006 09:07:56 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 87C4D1BAC4D for ; Thu, 11 May 2006 15:00:53 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: <35F9F869-0972-4393-896D-A72B6E6E1935@netlab.nec.de> Content-Type: text/plain; charset=US-ASCII; format=flowed To: nsis From: Martin Stiemerling Date: Thu, 11 May 2006 15:07:52 +0200 X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [NSIS] NATFW TRACE semantics X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, This is a request to read about the TRACE message in the NATFW NSLP draft (http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt) and to comment on it. The semantics of TRACE is preliminary and we need to get more input on it what exactly TRACE should do in the opinion of the working group. The important section about TRACE are: - 3.8.6 - 4.2.8 - 4.3.5 Currently, TRACE can be only sent by the session owner. TRACE will collect the identifiers of the NATFW NSLP nodes involved in a particular session. However, it is not specified which identifier in a case of a NAT is included or what happens if there is a change of the address family (e.g. from IPv4 to IPv6) is happening. Looking forward to the proposals and discussions Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:13:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAyD-0003d4-IX; Thu, 11 May 2006 09:12:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAyB-0003cz-QK for nsis@ietf.org; Thu, 11 May 2006 09:12:43 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAy9-0000YY-Gg for nsis@ietf.org; Thu, 11 May 2006 09:12:43 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 373421BAC4D for ; Thu, 11 May 2006 15:05:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: nsis From: Martin Stiemerling Date: Thu, 11 May 2006 15:12:38 +0200 X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Dear all, The draft -11 of the NATFW NSLP is somewhat unspecified about the usage of the IPv4 to IPv6 (and vice versa) transition mechanism NAT Protocol Translation (NAT-PT, RFC 2766). While in the past the NSLP had some text specifying how the NSLP should handle NAT-PT, it has been removed. One of the reasons is the draft http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt- to-exprmntl-03.txt The question is where to go with NAT-PT. Should the NATFW NSLP support NAT-PT or not? Probably, this is requires more a political answer rather than a technical! Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeB3D-0007O0-4p; Thu, 11 May 2006 09:17:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeB3C-0007Nv-Jx for nsis@ietf.org; Thu, 11 May 2006 09:17:54 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeB3C-0000uT-4z for nsis@ietf.org; Thu, 11 May 2006 09:17:54 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8F7BE1BAC4D; Thu, 11 May 2006 15:10:51 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8875E848-A62D-4144-AC6A-D550D43E8FDB@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] some comments on SDA selection in the NATFW NSLP Date: Thu, 11 May 2006 15:17:50 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Am 03.05.2006 um 14:34 schrieb Hancock, Robert: > hi, > > these comments are mainly inspired by appendix A and the > other sections on SDA use. > > to me, App A seems to make the whole problem seem much more > complicated than it really needs to be. to take the various True. > options there in turn: > > 1) seems to say 'use the DS address if it is known'. The > first problem listed is not actually a problem, just a statement > of fact about how this is done if the DS is behind a NAT. The > second problem listed I could not be certain that I understood, > but I don't really see what problem arises: it is up to the > DS to obtain an address which is valid at the NAT it is behind, > and if it can't then no-one will ever be able to communicate > with it. If the address is valid at the NAT it is behind, then > I don't see how routing asymmetry (which is about differences > between the routing for forward and reverse traffic between two > nodes) causes issues, since the route is pinned at the NAT anyway. > In any case, such a discussion is not relevant here; if the > DR knows the DS address, it surely just has to believe it for > the purpose of choosing an SDA. Discussing how that DS address > might not be valid at all doesn't really change that. > > 2) if the DR already knows its public address, then I don't see > why REA signalling is taking place at all. > > 3) is about using the application server address. The first problem > would seem only to arise if the DR was not behind a NAT in the > first place (in which case the DR doesn't need the REA signalling > to work); the second problem I would say is a minor issue. All agreed > > What i think is missing is a overall perspective on how a NATFW > implementation is expected to/able to interact with other application > layer protocols. I'm not talking about APIs, but more abstract > points like who is expected to provide what information and when. > (This question also occurred to me while reading 2.4.) The key > point for App A is that the only reason why the DR might be > obtaining an external address is in order to communicate it to > someone (if DR doesn't communicate the address, why bother to > obtain it?); so the address of the person it communicates with > is surely a reasonable address to use as the SDA. It doesn't > actually matter whether the SDA corresponds to an application > server or a host and you could quite easily have multiple ones. > Nor does it matter which address realm the SDA is in - the implementor > just has to know that the DR will be reachable from the address > realm in which the SDA lives, and choose the SDA accordingly. All right! We are going to change the section towards your proposal of "overall perspective on how a NATFW implementation is expected to/able to interact with other application layer protocols". > > (A problem arises if the DR only knows an SDA for a node in the > wrong address realm - for example, it can only talk to a local > SIP proxy behind the same NAT as itself. I can't think of a good > solution to that problem.) I can't think about a good solution to that problem either. This falls under "choose the SDA is a wise way". Thanks, Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:31:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBFg-0003n5-Jv; Thu, 11 May 2006 09:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBFf-0003n0-Ni for nsis@ietf.org; Thu, 11 May 2006 09:30:47 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBFd-0001mu-M7 for nsis@ietf.org; Thu, 11 May 2006 09:30:47 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 40F7C1BAC4D; Thu, 11 May 2006 15:23:43 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Thu, 11 May 2006 15:30:41 +0200 To: "Hancock, Robert" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 442d80051e0361a34f3560325c4a7092 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Robert and All, Am 10.05.2006 um 10:59 schrieb Hancock, Robert: > hi all, > > i'm still trying to get my head round sections 3.8.2 and 3.8.7 of > the spec (which i think is what most of the thread below is about). > > however, i do have a specific comment about the applicability of the > LE-MRM and PC-MRM for various types of scenario. i'll say in advance > that i'm not 100% certain that the LE-MRM definition is right; > however, the discussion below is not persuading me that it is wrong. > i'll try to explain why: > > from a GIST perspective, the purpose of the LE-MRM is to allow an > NSLP at an end host to talk to the 'edge' of the network and to > get signalling messages back. from that point of view, no port numbers > are needed at the GIST level, because there are no port numbers > associated > with the concept 'edge of the network'. routing state can be quite > happily created at NATs along the path [how? see below] and GIST > messages can be sent backwards and forwards as the NSLP requires. > > it turns out that the NATFW NSLP may need a port number for NATFW > purposes; specifically, that the external address that gets allocated > may actually be a {address, port} pair, if the NAT is doing address > sharing [if i understand it right ...]. However, in this particular > case, it's vital that the {address, port} information is *not* carried > at the GIST level, since it's vital that these are *not* translated > on the way back to the end host - the end-host wants these unmodified > so it can advertise them in the public network. so {address, port} > have > to be carried at the NSLP level (where other funny processing also > takes place on them). > > the question then arises whether other NSLPs might want to use the > LE-MRM and might need to have port numbers translated for them if > the signalling path went through a NAT. I can't assess that either > way at the moment; however, I can say that the QoS-NSLP is not a > valid example. if the QoS-NSLP wants to use some sort of proxy mode, > then it should use the upstream PC-MRM, not the LE-MRM. this is > because the QoS-NSLP talks about flows, not about network edges. > if the QoS-NSLP wanted to manage QoS for something which wasn't a > flow but which was bound to a network edge for some reason, then the > LE-MRM might be appropriate - but then there would be no port numbers > involved anyway. and i think that the same line of reasoning would > be applied to other NSLPs also. Nothing to say other that I fully agree. Good that we've had the sushi in San Diego ;-) > > there remains the question of how GIST gets LE-MRM-routed traffic > through a NAT. i think there are two cases here: > *) if the NAT hosts the NSLP in question, it is a non-issue. the > signalling traffic is presented to GIST by the NSLP separately > on each interface, and the NSLP is responsible for choosing the > MRI/SID/NSLP to pick out the routing state towards the right peer. > > *) if the NAT does not host the NSLP in question, GIST has to do > MRI/NLI/SCD re-writing to get the Query/Response messages backwards > and forwards correctly. no GIST routing state gets established, but > NAT bindings need to be established for the signalling traffic > itself. but I don't see this requiring access to information that > might be carried in the NSLP; the NAT can use the SID or the UDP > source port from the Query as keys for its binding table; the > former we assume to be unique and the latter can be rewritten. From the NTLP point that is all right. However, semantically the purpose of LE-MRM NAT traversal support at the NTLP is questionable (therefore I have asked Henning about use cases). A message with LE-MRM is used to locate a network edge with a NAT to enable inbound traffic. A REA message would be used in conjunction with the LE-MRM. If this type of message is transparently pushed through a NAT (let's call it N1) and intercepted by yet another edge-NAT (N2) beyond this, we get some non-issue as well. N2 can enable locally the NAT bindings for inbound data traffic, but how is this done at N1? The NATFW NSLP signaling messages can be exchanged between the hop before N1 and N2, but there is no way out of the NATFW NSLP to configure N1 for the expected inbound traffic. The NI would anyway need to use some other sort of NAT traversal technique. > > summary: at the moment, I think that the LE-MRM is ok. However, it's > a subtle subject and it's possible that I haven't understood all the > concerns. I'm also not certain at the moment that the way the NATFW > NSLP does things like proxy REA are correct - still thinking ... I also see no issue with LE-MRM in the current NATFW NSLP usage. However, no guarantee for other NSLPs. There is no doubt from my side about proxy REA and LE-MRM. The semantics of REA on the NTLP level itself is not changed for proxy REA. Proxy REA just needs to carry additional information for generating the latter CREATE. The CREATE is independent of the signaling state created by REA. The proxy REA is, in the first place, doing exactly the same job as REA: Finding the network edge with an edge-NAT. Martin > > > cheers, > > r. > >> -----Original Message----- >> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >> Sent: 08 May 2006 16:01 >> To: Henning Peters >> Cc: nsis@ietf.org >> Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns >> >> >> Hi Henning, >> >> >> Am 21.04.2006 um 22:06 schrieb Henning Peters: >> >>> Dear WG, dear NAT/Firewall NSLP authors, >>> >>> NAT/Firewall NSLP is a quite stable and usable protocol. There is >>> running >>> code already available that covers broad aspects of its >> functionality. >>> This proves at least that from an complexity and functional >>> viewpoint it >> >> Good to hear that! >> >>> can be considered feasible. Still, I find that some parts of the >>> spec can >>> be improved. Here, I would like to present my concerns connected to >>> LE-MRM/DTINFO that I developed during working on our implementation. > >> >> Comments and suggestions are always welcome. >> >>> >>> shortcut: the questions related to WG discussion are at 4). >>> >>> 1) Confusing directions >>> >>> Most notable, the directions are a bit confusing in this object. >>> src port >>> is data sender (DS) port, dst port is data receiver (DR) port. DR >>> port is >>> subject of rewrite, whereas DS port specifies the data >> sender. I would >>> appreciate avoiding the term source and destination in this >>> context, this >>> would also leverage the positioning issue (see later *** when >>> discussing >>> the message format that confusely destination port is positioned >>> before >>> source port). >> >> While the naming is technically correct, I have to admit that it is >> confusing. >> So, I would suggest to change the names directly to what you have >> proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This >> is then >> inline with the naming of 'data sender's IP address' in the >> same object. >> >>> >>> Anyway, I will refer to DS port and DR port in the following. >>> >>> 2) LE-MRM / DTINFO ports >>> >>> After introduction of LE-MRM (loose end message routing >> method) to the >>> spec last year it was found that NAT traversal in NAPTs is broken as > >>> LE-MRM does not carry port information. Ports are >> considered as not >>> part >>> of GIST routing and therefore omitted from MRI. >> >> There are two things to differentiate: NAPT support is not >> broken in the >> NATFW NSLP and whether NAPT traversal of GIST is broken when using >> LE-MRM is a different story that depends on the view point. >> >> My concern here is about why we need a GIST/LE-MRM NAPT traversal >> mechanism? When there is a NAT on your side of the network that is >> not NATFW NSLP enabled you anyway need to fall back to all the >> other workarounds, such as STUN, TURN, or other tricks. >> >> >>> >>> To compensate this DTINFO object was enhanced later with the port >>> information that was previously accessable in PC-MRM >> (signaling the >>> wrong >>> way) MRI. I believe that the current approach is not a good design >> >> There is non compensation needed, because GIST carries all >> information > >> necessary for the message routing and the DTINFO object carries >> information about the later expected data flow. That are basically >> two > >> different things: The message routing information and the expected >> data flow. >> >>> decision as GIST NAT traversal would be rendered broken. GIST NAT >>> traversal is crucial as we cannot assume a domainwide deployment of >>> NAT/Firewall NSLP instantly. I would appreciate a >> deployable over a >>> 100% >>> clean solution as deployment will be very crucial to >> NAT/Firewall NSLP >>> success anyway. >> >> I do not see the applicability given for the GIST with LE-MRM and NAT >> traversal. I probably need a good example why it is needed. >> >>> >>> See Martin's and my discussion in the issue tracker: >>> https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 >>> >>> Actually, only the DR port and protocol field is needed for NAT >>> traversal >>> as REA/LE-MRM needs only a one-sided translation. >>> >>> 3) DTINFO message format >>> >>> The message format of the current solution is a bit confusing and >>> lacks >>> IPv6 support (DTINFOv6 object was removed in previous draft). Let >>> me start >>> with its figure: >> >> The DTINFO_IPV6 object has been removed since there is no IPv6 NAT >> and the usage of NAT-PT seems to be deprecated. >> >>> >>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |I|P|S| reserved | dest prefix | >> protocol | >>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> (***): dst port number [DR] | src port number >> [DS] : >>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> : IPsec SPI >> : >>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | data sender's IPv4 address >> | >>> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> The purpose of this object is two-fold: >>> >>> - specify data sender during REA (aka: the cone-ness of the NAT) >>> >>> - supply DR port/protocol for NAT traversal >>> >>> Unfortunately, the draft heavily mixes and overloads these two >>> different >>> semantical aspects in this object. Specifically, I see following >>> issues: >>> >>> a) The P flag specifies whether port numbers are present or >> not. This >>> means that either both ports are present or none. Confusely, DR >>> port and >>> DS port cover different semantic aspects: >>> >>> DS port specifies the data sender, DR port is necessary for NAT >>> traversal. >>> A single flag to enable/disable two fields with different semantical > >>> meaning can be problematic. >> >> I makes sense to either enable usage of ports or not. >> However, if ports >> are enabled you still can wildcard the DS port. This makes some sense >> from the point of whether your policy rule to be installed in >> the device >> covers port numbers or not. >> >>> >>> b) The I flag specifies whether the protocol field should be >>> interpreted >>> or not. The protocol defines the protocol used for above mentioned >>> ports >>> if the P flag is set aswell. Although the ports are of different >>> semantical meaning, the protocol covers both equally. >>> >>> I am not sure whether this semantical overloading may introduce new >>> problems, at least this limits flexibility compared to PC-MRM case >>> where a >>> protocol can be set in MRI and in DTINFO independently. >> >> DTINFO and PC-MRM cannot be used at the same time. *BUT* this is >> not specified in the draft :-) >> I will fix this. >> >>> >>> c) DTINFO object might be used for firewall signaling scenarios. But > >>> LE-MRM can only cover NAT-only scenarios. That means that the NR >>> has to >>> know the scenario in advance to choose between PC-MRM and LE-MRM >>> signaling. The more intelligence is put into NR the more it >> evolves >>> to a >>> probing NR. >> >> Right, NR needs to choose carefully in what scenario it is. But the >> DTINFO object >> is not useful in firewall only scenarios, since those messages are >> anyway >> carried using the PC-MRM. >> >>> >>> A probing NR sounds to me a bit like the situations BEHAVE working >>> group >>> deal with; this is not the situation I would like to see NAT/ >>> Firewall NSLP >>> in. I think that our network states can be used more flexibly to >>> assist >>> the NR better. The NR should not care about the network, but only >>> give the >>> definitions that the network should adapt to. >> >> I would prefer a different way of deciding whether the NR is NATed or >> firewalled only. However, until now there has been now good proposal >> how to avoid this. Suggestions are welcome. >> >>> >>> Surely, this is a design decision that needs WG consensus. >>> >>> d) DTINFO object MUST be included when using LE-MRM as NAT >>> traversal is >>> not possible as long as DR port is not available. >> Therefore, following >>> paragraphs might need correction: >>> >>>> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message >>>> when using the LE-MRM. The LE-MRM does not include enough >>> >>> also: >>> >>>> When the data sender's address information is known in >> advance the >>>> NI+ >>>> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as >>>> described >>>> above). >> >> Already noted this. >> >>> >>> 4) I hope I pointed out that a discussion of following points in >>> the WG is >>> necessary: >>> >>> - How much intelligence should have the NR -> shall the network >>> handle the >>> deployment sceario or should the NR know/probe the network scenario? > >> >> As said, I'm open for suggestions! >> >>> >>> - Is a broken GIST NAT traversal worth giving up a 100% clean MRM >>> design? >> >> I still lack the real usage scenario for GIST with LE-MRM NAT >> traversal. >> >>> >>> The message format issues heavily depend on these discussions, >>> therefore I >>> would rather like to delay the message format design until both >>> questions >>> gained consensus. >>> >>> I also appreciate any feedback on our NAT/Firewall NSLP >> implementation >>> available at: >>> >>> http://user.informatik.uni-goettingen.de/~nsis/ >> >> I hope to get some time for checking this out. >> >>> >>> Thank you for your attention, >> >> Thanks a lot for the comments! >> >>> Henning Peters >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >> >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis >> > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:33:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBI4-000562-6D; Thu, 11 May 2006 09:33:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBI3-00055x-9K for nsis@ietf.org; Thu, 11 May 2006 09:33:15 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBI1-0001vQ-Qq for nsis@ietf.org; Thu, 11 May 2006 09:33:15 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5D80D1BAC4D; Thu, 11 May 2006 15:26:11 +0200 (CEST) In-Reply-To: <44632477.2050604@roke.co.uk> References: <4461BF7F.60300@student.dei.uc.pt> <44632477.2050604@roke.co.uk> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <162933AF-00FF-4246-AEDB-11ABB323E2A4@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] Packet Classifier in QoS NSLP Date: Thu, 11 May 2006 15:33:10 +0200 To: Andrew McDonald X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, My comment is related to the below email but not directly for the QoS NSLP. Probably it is good to add a paragraph to John's draft on NSLP extensibility saying that future NSLPs need to clarify what message routing methods (MRM) they are going to use. Martin Am 11.05.2006 um 13:48 schrieb Andrew McDonald: > Hi David, > > David Palma wrote: >> In QoS NSLP draft (v10) the Packet Classifier object is described as >> below: > [snip] >> If I am understanding the above text correctly, the Packet Classifier >> should have a short for Loose End routing and 2 shorts for Path >> Coupled. >> So I assume that will always have Length 1 (1 word) to both routing >> methods right? The word "variable" to the length confuses me a little >> bit. >> Are my assumptions correct? > > The QoS NSLP does not make use of the GIST LE-MRM. It is only > defined to use the PC-MRM. > > I thought I had added a statement about this in draft -10. Having > had a quick check, I can't see it. This obviously needs clarifying > in the draft. > > (Added to QoS NSLP issue tracker as issue 59: > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/ > issue59) > > regards, > > Andrew > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 09:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBMe-00087U-Ij; Thu, 11 May 2006 09:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeBMe-00087O-14 for nsis@ietf.org; Thu, 11 May 2006 09:38:00 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBMc-00026h-V6 for nsis@ietf.org; Thu, 11 May 2006 09:37:59 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 743CB1BAC4D; Thu, 11 May 2006 15:30:56 +0200 (CEST) In-Reply-To: <37901.24.199.92.165.1147285957.squirrel@mail.piranho.net> References: <37901.24.199.92.165.1147285957.squirrel@mail.piranho.net> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21A356F7-E84A-4131-AEE0-7872E21D4CAB@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Thu, 11 May 2006 15:37:55 +0200 To: Henning Peters X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e Cc: nsis@ietf.org, "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Henning, Am 10.05.2006 um 20:32 schrieb Henning Peters: > Hi Robert, > > good summary. Though, I am missing one point: > > In a hierarchical NAT scenario, is it sufficient only talk to the > edge to > make a reservation? An example: > > A:NI --[ B:NF(NAT) --[ C:NF(NAT) --- D:NR > 1) <=========================REA > 2) RESPONSE====================> > 3) CREATE====> ============> X =========> X...marks the problem > loc. > 4) <========== <============= <==RESPONSE > > Assumption: In this scenario I assume that a REA(1) message with LE- > MRM > does only talk to the edge and traverses C seemlessly. C may trigger a > reservation, read the flow, but will not change any data of the > message > exchange between B and D. Does this imply C:NF(NAT) being NATFW NSLP unaware or do you say C:NF(NAT) is NATFW NSLP aware but does not care about the message? The picture does not show the NATFW NSLP operation if C:NF(NAT) is NATFW NSLP aware. Can you clarify this? Otherwise the answer to this email is going full of ifs. Thanks, Martin > > For an upcoming CREATE(3) message from A it seems to be necessary > for B to > previously store the IP address of the C during REA(1) operation, > because > B has to map between different session IDs based upon the external > port > reservations. It also has to know the external port reservation of C. > > Thus, in respect to NAT behavior, B has to translate the IP and TCP/ > UDP > layer and update MRI accordingly to match the new destination > address/port. But: how does B know about a valid destination port > at C? > > In my view all NAT have to do a mapping unrelated to session ID, > but on IP > address and port, because REA and CREATE messages are different > sessions. > Thus, they need a mechanism to signal their external port > reservation to > the upstream NAT, this is not possible without modifying the exchange > between B and D. Thus my previously made assumption is wrong. > > Hence, I asked Martin to give me a port field, it was introduced in > last > fall. The whole issue is complicated, so I am not 100% sure whether I > might not miss a point. If I might be right, then I have following > concern: > > LE-MRM is not only about "talking to the edge". Therefore, I find it > sensible to put the port into LE-MRM. Please keep in mind that I > might be > biased, because I want to keep my codebase small ;). > > Currently the port resides in DTINFO object. So, if signaled with > LE-MRM > one has to use this field, when using PC-MRM one has to use MRI port > although the port is here needed for the same purpose: giving the > upstream > NAT information about the local NATs port reservation. Sure, in PC-MRM > this information is overloaded the same way as NAT is already > overloading > identifiers. > > Henning > > > Hancock, Robert sagte Mi, 10.05.2006, 04:59: >> hi all, >> >> i'm still trying to get my head round sections 3.8.2 and 3.8.7 of >> the spec (which i think is what most of the thread below is about). >> >> however, i do have a specific comment about the applicability of the >> LE-MRM and PC-MRM for various types of scenario. i'll say in advance >> that i'm not 100% certain that the LE-MRM definition is right; >> however, the discussion below is not persuading me that it is wrong. >> i'll try to explain why: >> >> from a GIST perspective, the purpose of the LE-MRM is to allow an >> NSLP at an end host to talk to the 'edge' of the network and to >> get signalling messages back. from that point of view, no port >> numbers >> are needed at the GIST level, because there are no port numbers >> associated >> with the concept 'edge of the network'. routing state can be quite >> happily created at NATs along the path [how? see below] and GIST >> messages can be sent backwards and forwards as the NSLP requires. >> >> it turns out that the NATFW NSLP may need a port number for NATFW >> purposes; specifically, that the external address that gets allocated >> may actually be a {address, port} pair, if the NAT is doing address >> sharing [if i understand it right ...]. However, in this particular >> case, it's vital that the {address, port} information is *not* >> carried >> at the GIST level, since it's vital that these are *not* translated >> on the way back to the end host - the end-host wants these unmodified >> so it can advertise them in the public network. so {address, port} >> have >> to be carried at the NSLP level (where other funny processing also >> takes place on them). >> >> the question then arises whether other NSLPs might want to use the >> LE-MRM and might need to have port numbers translated for them if >> the signalling path went through a NAT. I can't assess that either >> way at the moment; however, I can say that the QoS-NSLP is not a >> valid example. if the QoS-NSLP wants to use some sort of proxy mode, >> then it should use the upstream PC-MRM, not the LE-MRM. this is >> because the QoS-NSLP talks about flows, not about network edges. >> if the QoS-NSLP wanted to manage QoS for something which wasn't a >> flow but which was bound to a network edge for some reason, then the >> LE-MRM might be appropriate - but then there would be no port numbers >> involved anyway. and i think that the same line of reasoning would >> be applied to other NSLPs also. >> >> there remains the question of how GIST gets LE-MRM-routed traffic >> through a NAT. i think there are two cases here: >> *) if the NAT hosts the NSLP in question, it is a non-issue. the >> signalling traffic is presented to GIST by the NSLP separately >> on each interface, and the NSLP is responsible for choosing the >> MRI/SID/NSLP to pick out the routing state towards the right peer. >> >> *) if the NAT does not host the NSLP in question, GIST has to do >> MRI/NLI/SCD re-writing to get the Query/Response messages backwards >> and forwards correctly. no GIST routing state gets established, but >> NAT bindings need to be established for the signalling traffic >> itself. but I don't see this requiring access to information that >> might be carried in the NSLP; the NAT can use the SID or the UDP >> source port from the Query as keys for its binding table; the >> former we assume to be unique and the latter can be rewritten. >> >> summary: at the moment, I think that the LE-MRM is ok. However, it's >> a subtle subject and it's possible that I haven't understood all the >> concerns. I'm also not certain at the moment that the way the NATFW >> NSLP does things like proxy REA are correct - still thinking ... >> >> >> cheers, >> >> r. >> >>> -----Original Message----- >>> From: Martin Stiemerling [mailto:stiemerling@netlab.nec.de] >>> Sent: 08 May 2006 16:01 >>> To: Henning Peters >>> Cc: nsis@ietf.org >>> Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns >>> >>> >>> Hi Henning, >>> >>> >>> Am 21.04.2006 um 22:06 schrieb Henning Peters: >>> >>>> Dear WG, dear NAT/Firewall NSLP authors, >>>> >>>> NAT/Firewall NSLP is a quite stable and usable protocol. There is >>>> running >>>> code already available that covers broad aspects of its >>> functionality. >>>> This proves at least that from an complexity and functional >>>> viewpoint it >>> >>> Good to hear that! >>> >>>> can be considered feasible. Still, I find that some parts of the >>>> spec can >>>> be improved. Here, I would like to present my concerns connected to >>>> LE-MRM/DTINFO that I developed during working on our >>>> implementation. >> >>> >>> Comments and suggestions are always welcome. >>> >>>> >>>> shortcut: the questions related to WG discussion are at 4). >>>> >>>> 1) Confusing directions >>>> >>>> Most notable, the directions are a bit confusing in this object. >>>> src port >>>> is data sender (DS) port, dst port is data receiver (DR) port. DR >>>> port is >>>> subject of rewrite, whereas DS port specifies the data >>> sender. I would >>>> appreciate avoiding the term source and destination in this >>>> context, this >>>> would also leverage the positioning issue (see later *** when >>>> discussing >>>> the message format that confusely destination port is positioned >>>> before >>>> source port). >>> >>> While the naming is technically correct, I have to admit that it is >>> confusing. >>> So, I would suggest to change the names directly to what you have >>> proposed: 'src port' -> 'DS port' and 'dst port' -> 'DR port'. This >>> is then >>> inline with the naming of 'data sender's IP address' in the >>> same object. >>> >>>> >>>> Anyway, I will refer to DS port and DR port in the following. >>>> >>>> 2) LE-MRM / DTINFO ports >>>> >>>> After introduction of LE-MRM (loose end message routing >>> method) to the >>>> spec last year it was found that NAT traversal in NAPTs is >>>> broken as >> >>>> LE-MRM does not carry port information. Ports are >>> considered as not >>>> part >>>> of GIST routing and therefore omitted from MRI. >>> >>> There are two things to differentiate: NAPT support is not >>> broken in the >>> NATFW NSLP and whether NAPT traversal of GIST is broken when using >>> LE-MRM is a different story that depends on the view point. >>> >>> My concern here is about why we need a GIST/LE-MRM NAPT traversal >>> mechanism? When there is a NAT on your side of the network that is >>> not NATFW NSLP enabled you anyway need to fall back to all the >>> other workarounds, such as STUN, TURN, or other tricks. >>> >>> >>>> >>>> To compensate this DTINFO object was enhanced later with the port >>>> information that was previously accessable in PC-MRM >>> (signaling the >>>> wrong >>>> way) MRI. I believe that the current approach is not a good design >>> >>> There is non compensation needed, because GIST carries all >>> information >> >>> necessary for the message routing and the DTINFO object carries >>> information about the later expected data flow. That are >>> basically two >> >>> different things: The message routing information and the expected >>> data flow. >>> >>>> decision as GIST NAT traversal would be rendered broken. GIST NAT >>>> traversal is crucial as we cannot assume a domainwide deployment of >>>> NAT/Firewall NSLP instantly. I would appreciate a >>> deployable over a >>>> 100% >>>> clean solution as deployment will be very crucial to >>> NAT/Firewall NSLP >>>> success anyway. >>> >>> I do not see the applicability given for the GIST with LE-MRM and >>> NAT >>> traversal. I probably need a good example why it is needed. >>> >>>> >>>> See Martin's and my discussion in the issue tracker: >>>> https://kobe.netlab.nec.de/roundup/nsis-natfw-nslp/issue50 >>>> >>>> Actually, only the DR port and protocol field is needed for NAT >>>> traversal >>>> as REA/LE-MRM needs only a one-sided translation. >>>> >>>> 3) DTINFO message format >>>> >>>> The message format of the current solution is a bit confusing and >>>> lacks >>>> IPv6 support (DTINFOv6 object was removed in previous draft). Let >>>> me start >>>> with its figure: >>> >>> The DTINFO_IPV6 object has been removed since there is no IPv6 NAT >>> and the usage of NAT-PT seems to be deprecated. >>> >>>> >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |I|P|S| reserved | dest prefix | >>> protocol | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> (***): dst port number [DR] | src port number >>> [DS] : >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> : IPsec SPI >>> : >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | data sender's IPv4 address >>> | >>>> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> The purpose of this object is two-fold: >>>> >>>> - specify data sender during REA (aka: the cone-ness of the NAT) >>>> >>>> - supply DR port/protocol for NAT traversal >>>> >>>> Unfortunately, the draft heavily mixes and overloads these two >>>> different >>>> semantical aspects in this object. Specifically, I see following >>>> issues: >>>> >>>> a) The P flag specifies whether port numbers are present or >>> not. This >>>> means that either both ports are present or none. Confusely, DR >>>> port and >>>> DS port cover different semantic aspects: >>>> >>>> DS port specifies the data sender, DR port is necessary for NAT >>>> traversal. >>>> A single flag to enable/disable two fields with different >>>> semantical >> >>>> meaning can be problematic. >>> >>> I makes sense to either enable usage of ports or not. >>> However, if ports >>> are enabled you still can wildcard the DS port. This makes some >>> sense >>> from the point of whether your policy rule to be installed in >>> the device >>> covers port numbers or not. >>> >>>> >>>> b) The I flag specifies whether the protocol field should be >>>> interpreted >>>> or not. The protocol defines the protocol used for above mentioned >>>> ports >>>> if the P flag is set aswell. Although the ports are of different >>>> semantical meaning, the protocol covers both equally. >>>> >>>> I am not sure whether this semantical overloading may introduce new >>>> problems, at least this limits flexibility compared to PC-MRM case >>>> where a >>>> protocol can be set in MRI and in DTINFO independently. >>> >>> DTINFO and PC-MRM cannot be used at the same time. *BUT* this is >>> not specified in the draft :-) >>> I will fix this. >>> >>>> >>>> c) DTINFO object might be used for firewall signaling scenarios. >>>> But >> >>>> LE-MRM can only cover NAT-only scenarios. That means that the NR >>>> has to >>>> know the scenario in advance to choose between PC-MRM and LE-MRM >>>> signaling. The more intelligence is put into NR the more it >>> evolves >>>> to a >>>> probing NR. >>> >>> Right, NR needs to choose carefully in what scenario it is. But the >>> DTINFO object >>> is not useful in firewall only scenarios, since those messages are >>> anyway >>> carried using the PC-MRM. >>> >>>> >>>> A probing NR sounds to me a bit like the situations BEHAVE working >>>> group >>>> deal with; this is not the situation I would like to see NAT/ >>>> Firewall NSLP >>>> in. I think that our network states can be used more flexibly to >>>> assist >>>> the NR better. The NR should not care about the network, but only >>>> give the >>>> definitions that the network should adapt to. >>> >>> I would prefer a different way of deciding whether the NR is >>> NATed or >>> firewalled only. However, until now there has been now good proposal >>> how to avoid this. Suggestions are welcome. >>> >>>> >>>> Surely, this is a design decision that needs WG consensus. >>>> >>>> d) DTINFO object MUST be included when using LE-MRM as NAT >>>> traversal is >>>> not possible as long as DR port is not available. >>> Therefore, following >>>> paragraphs might need correction: >>>> >>>>> The NI+ MAY include a NATFW_DTINFO_IPv4 object in the REA message >>>>> when using the LE-MRM. The LE-MRM does not include enough >>>> >>>> also: >>>> >>>>> When the data sender's address information is known in >>> advance the >>>>> NI+ >>>>> MAY include a NATFW_DTINFO_IPv4 object in the REA message (as >>>>> described >>>>> above). >>> >>> Already noted this. >>> >>>> >>>> 4) I hope I pointed out that a discussion of following points in >>>> the WG is >>>> necessary: >>>> >>>> - How much intelligence should have the NR -> shall the network >>>> handle the >>>> deployment sceario or should the NR know/probe the network >>>> scenario? >> >>> >>> As said, I'm open for suggestions! >>> >>>> >>>> - Is a broken GIST NAT traversal worth giving up a 100% clean MRM >>>> design? >>> >>> I still lack the real usage scenario for GIST with LE-MRM NAT >>> traversal. >>> >>>> >>>> The message format issues heavily depend on these discussions, >>>> therefore I >>>> would rather like to delay the message format design until both >>>> questions >>>> gained consensus. >>>> >>>> I also appreciate any feedback on our NAT/Firewall NSLP >>> implementation >>>> available at: >>>> >>>> http://user.informatik.uni-goettingen.de/~nsis/ >>> >>> I hope to get some time for checking this out. >>> >>>> >>>> Thank you for your attention, >>> >>> Thanks a lot for the comments! >>> >>>> Henning Peters >>>> >>>> >>>> _______________________________________________ >>>> nsis mailing list >>>> nsis@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nsis >>> >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis >>> >> >> > > > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 10:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCPs-00079R-6r; Thu, 11 May 2006 10:45:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCPq-00079J-AQ for nsis@ietf.org; Thu, 11 May 2006 10:45:22 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeBfI-0002rx-8f for nsis@ietf.org; Thu, 11 May 2006 09:57:16 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeBZy-00014U-1g for nsis@ietf.org; Thu, 11 May 2006 09:51:47 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id DAC6C1BAC4D; Thu, 11 May 2006 15:44:40 +0200 (CEST) In-Reply-To: <20060511115645.GA22784@mafr.de> References: <20060511115645.GA22784@mafr.de> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW message format Date: Thu, 11 May 2006 15:51:39 +0200 To: Matthias Friedrich X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -2.6 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Matthias, Am 11.05.2006 um 13:56 schrieb Matthias Friedrich: > Hi, > > while reading section 4 (NATFW NSLP Message Components), I noticed the > following minor issues: > > * The order the objects may appear in a message is not specified. > If there is no fixed order, it should be stated explicitly. It > could also be noted that only one object of a type may appear > in a message. There is no fixed order of the objects and each object must only appear once in the message. Will be fixed. > > * It would be nice to have preliminary object type IDs to make sure > experimental implementations are compatible. The message types > already have IDs. Alright, this will be added to the next version. > > * The "Forward" treatment is never used in the draft. Is there a use > case where it is necessary? The "Forward" treatment, as described in Section 4.2, is not used by the objects defined in the NATFW NSLP draft. But this treatment is likely used by future objects that are yet to defined. Imagine a new "mobile IP" object (however this may look like and useful). This "mobile IP" object may request packet treatment by the firewall that is are possibly needed, i.e., make life easier but is not 100% needed for life. Another scenario would be a vendor specific object that can only be handled by particular firewalls/NATs of that vendor. > > * The NATFW_LT object is named "session lifetime", but sections > 4.3.[123] just use "lifetime". Should all read "session lifetime" or even better "signaling session lifetime". Will be fixed. > > * The NATFW_INFO object has a 16 bit object type, while the common > object header only allows for 12 bits. Yes, the object field should be limited to 12 bits as well. Will be fixed. > > * The NATFW_DTINFO_IPv4 object seems to have a variable length, > judging > from text and diagram, but the length is specified as 3 words. Right! Will be fixed. > > * The NATFW_TRACE's hop count seems to be unnecessary. The number of > hops can be derived from the number of IP addresses in this object. Right, and see the extra email threat about the TRACE semantics. Feel free to comment on this threat about TRACE in general. > > * Is the NATFW_CREDENTIAL's length field really necessary? A concrete > credential type could still decide to use these bits as a length > field to support padding. For other credential types it might not > be needed. If the credential data is a multiple of 32 bit, the > leading 16 bit could be used as padding. So will need so length information, some won't. This requires a field where the length can be stored. Otherwise we would need a flag that indicates whether the length field is used or not. > > * Would a version number in the message header make sense? You mean the NSLP header? No, it does not make sense per WG decision. There will be new NSLP ID assigned, whenever there is a new version of an NSLPs. This has been decided very long ago. > > > Thanks for reading, Thank you for reading! Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 13:56:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFOm-0005LA-Bd; Thu, 11 May 2006 13:56:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFOl-0005CW-0y for nsis@ietf.org; Thu, 11 May 2006 13:56:27 -0400 Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeFOj-000543-KD for nsis@ietf.org; Thu, 11 May 2006 13:56:27 -0400 Received: (qmail 12021 invoked from network); 11 May 2006 17:56:24 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 11 May 2006 17:56:24 -0000 Received: from 24.199.92.165 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Thu, 11 May 2006 13:56:24 -0400 (EDT) Message-ID: <53037.24.199.92.165.1147370184.squirrel@mail.piranho.net> In-Reply-To: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de> References: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de> Date: Thu, 11 May 2006 13:56:24 -0400 (EDT) Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, hi Robert, Martin said: > ... semantically the > purpose of LE-MRM NAT traversal support at the NTLP is > questionable (therefore I have asked Henning about use > cases). Sure: 1) I might want to configure my local NAT (fitted with an NSIS ALG) manually, but do not have access to a hierarchical remote NAT (e.g., located at ISP). Therefore, I want to have a mechanism that works seemlessly. Future application might support NSIS + NAT/FW NSLP out-of-the-box, without being able to "talk to the edge" creating a NAT reservation at ISP level is impossible. Also, the local NAT can be later replaced transparently with real NSIS machine to cope more functionality (e.g. QoS NSLP). I see this as a deployment advantage. Otherwise we have to believe that within all domains deployment switches to NSIS at once - this would be nice (i.e., IPv6), but hard to believe (i.e., IPv6)... ;) 2) I don't care about semantics if it does not work in reality. My view is that NAT/Firewall NSLP should avoid any type of probing, otherwise we are not much better off than BEHAVE folks doing hole-punching or praying for hairpin-translation. Thus, an application (aka NI+) that wants to receive incoming traffic should not worry about the difficulties about this operation. This means that it should not need to probe anything. The decision whether to use PC-MRM or LE-MRM requires knowledge about the network structure: Is there a firewall in the administrative domain or not. Honestly, I would not miss LE-MRM if we would drop it. In case we stay with LE-MRM in the spec (whether it will be used might be a different question), I think that we should design it with maximum deployment support in mind - in this sense I believe that we should not equip the semantical aspect with the highest priority, So let me pose the question the other way around: What is the use case for NAT-only operation (aka LE-MRM)? Aren't our networks already fitted with a multitude of both: NATs and firewalls?! Can we really be sure that the network does not change or that endpoints attach to new networks at any time? Those changes should be handled transparently... and LE-MRM is not able to do this for firewalls, but only for NATs... Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 11 13:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFRJ-00071K-Ei; Thu, 11 May 2006 13:59:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFRH-00071C-SD for nsis@ietf.org; Thu, 11 May 2006 13:59:03 -0400 Received: from mail.piranho.net ([80.190.191.60]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FeFRF-0005Bn-Eg for nsis@ietf.org; Thu, 11 May 2006 13:59:03 -0400 Received: (qmail 12223 invoked from network); 11 May 2006 17:59:00 -0000 Received: from localhost (HELO mail.piranho.net) (127.0.0.1) by 0 with SMTP; 11 May 2006 17:59:00 -0000 Received: from 24.199.92.165 (SquirrelMail authenticated user zedsoy) by mail.piranho.net with HTTP; Thu, 11 May 2006 13:59:00 -0400 (EDT) Message-ID: <42260.24.199.92.165.1147370340.squirrel@mail.piranho.net> In-Reply-To: <21A356F7-E84A-4131-AEE0-7872E21D4CAB@netlab.nec.de> References: <37901.24.199.92.165.1147285957.squirrel@mail.piranho.net> <21A356F7-E84A-4131-AEE0-7872E21D4CAB@netlab.nec.de> Date: Thu, 11 May 2006 13:59:00 -0400 (EDT) Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns From: "Henning Peters" To: nsis@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Hancock, Robert" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, > Does this imply C:NF(NAT) being NATFW NSLP unaware or do you say > C:NF(NAT) is NATFW NSLP aware but does not care about the message? > > The picture does not show the NATFW NSLP operation > if C:NF(NAT) is NATFW NSLP aware. C is a NATFW NSLP aware hop with the artificial restriction that it does not add port information. By this negative conjecture I wanted to show that the port indeed is necessary for upstream NAPTs, not only the edge. My point was that LE-MRM does not only talk to the edge (as Robert said previously), but also to all intermediate NAPTs. Henning > > Can you clarify this? Otherwise the answer to this email is going > full of ifs. > > Thanks, > > Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 12 05:09:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeTe8-000818-VM; Fri, 12 May 2006 05:09:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeTe7-000813-Iy for nsis@ietf.org; Fri, 12 May 2006 05:09:15 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeTe6-0006y9-1C for nsis@ietf.org; Fri, 12 May 2006 05:09:15 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k4C99DF2026780 for ; Fri, 12 May 2006 11:09:13 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4C99DQn009040 for ; Fri, 12 May 2006 11:09:13 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 11:09:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 May 2006 11:09:07 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: QSPEC Comments Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorsw== From: "Tschofenig, Hannes" To: "nsis" X-OriginalArrivalTime: 12 May 2006 09:09:12.0781 (UTC) FILETIME=[BC69D7D0:01C675A3] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [NSIS] QSPEC Comments X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all I have a few minor comments for the QSPEC draft: - Use either 'QoS NSLP' or 'QoS-NSLP' terminology. The QoS NSLP draft uses 'QoS NSLP' - Don't use RFC 2119 language in examples (e.g., Section 4.3). The same is true for RFC 2119 language in the appendix.=20 - Review RFC 2119 language in the text. Example: First sentence in Section 4.6: MAY is inappropriate there.=20 - Ability to define mandatory QoS parameters in QOSMs no clear - Reference to [NSIS-EXTENSIBILITY] in the IANA consideration section is not a good idea. It also needs to be removed from the normative reference since otherwise this document will be blocked.=20 - You shouldn't request IANA to allocate value for QOSMs in the QSPEC template document. - Why do you need information of the type of QoS signaling in the QSPEC template (e.g., sender-initiated, receiver-oriented QoS signaling)? - Is the idea of the tunneled parameter flag inline with the QoS NSLP understanding of tunneling?=20 - Use capitalized words in captions and headlines. The RFC editor will thank you. =20 Other comments have been posted by Andrew already (e.g., definition of mandatory parameters).=20 Ciao Hannes _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 12 06:50:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVDR-0002pp-9S; Fri, 12 May 2006 06:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVDQ-0002pk-7y for nsis@ietf.org; Fri, 12 May 2006 06:49:48 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeVDN-0003EY-HU for nsis@ietf.org; Fri, 12 May 2006 06:49:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4CAnceI027117; Fri, 12 May 2006 13:49:42 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 13:49:20 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 13:49:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) Date: Fri, 12 May 2006 13:49:15 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB4077BF@esebe100.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) Thread-Index: AcZ0/R9KppEDtV9UQXiu7o2RN6V3NgAtHIJg From: To: , X-OriginalArrivalTime: 12 May 2006 10:49:20.0574 (UTC) FILETIME=[B9564DE0:01C675B1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org >The draft -11 of the NATFW NSLP is somewhat unspecified about=20 >the usage of the IPv4 to IPv6 (and vice versa) transition=20 >mechanism NAT Protocol Translation (NAT-PT, RFC 2766). While=20 >in the past the NSLP had some text specifying how the NSLP=20 >should handle NAT-PT, it has been removed. One of the reasons=20 >is the draft=20 >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt- >to-exprmntl-03.txt > >The question is where to go with NAT-PT. Should the NATFW NSLP=20 >support NAT-PT or not? Probably, this is requires more a=20 >political answer rather than a technical! Well, I'd say that we don't need to address NAT-PT, unless anyone in the audience (in the mailing list) is specifically interested in it. John _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 12 07:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVVV-00056v-IJ; Fri, 12 May 2006 07:08:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeVVU-00056q-6o for nsis@ietf.org; Fri, 12 May 2006 07:08:28 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeVVS-0004IC-Ok for nsis@ietf.org; Fri, 12 May 2006 07:08:28 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4CB84Xq013491; Fri, 12 May 2006 12:08:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) Date: Fri, 12 May 2006 12:08:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) Thread-Index: AcZ0/R9KppEDtV9UQXiu7o2RN6V3NgAtHIJgAABP8PA= From: "Hancock, Robert" To: , , X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: robert.hancock@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org hi, i think this is a question of what is the current deployment.=20 if NAT-PT is currently seriously deployed to any extent, we=20 have to deal with it. however, dealing with it may simply mean=20 detecting and returning an error condition. if NAT-PT is not currently seriously deployed, then we can probably forget about it. r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: 12 May 2006 11:49 > To: stiemerling@netlab.nec.de; nsis@ietf.org > Subject: RE: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to=20 > IPv6 translation) >=20 >=20 >=20 > >The draft -11 of the NATFW NSLP is somewhat unspecified about=20 > >the usage of the IPv4 to IPv6 (and vice versa) transition=20 > >mechanism NAT Protocol Translation (NAT-PT, RFC 2766). While=20 > >in the past the NSLP had some text specifying how the NSLP=20 > >should handle NAT-PT, it has been removed. One of the reasons=20 > >is the draft=20 > >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt- > >to-exprmntl-03.txt > > > >The question is where to go with NAT-PT. Should the NATFW NSLP=20 > >support NAT-PT or not? Probably, this is requires more a=20 > >political answer rather than a technical! >=20 > Well, I'd say that we don't need to address NAT-PT, unless anyone in > the audience (in the mailing list) is specifically interested in it. >=20 > John >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 12 12:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fea4K-0004xd-P6; Fri, 12 May 2006 12:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fea4K-0004wa-5m for nsis@ietf.org; Fri, 12 May 2006 12:00:44 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fea4I-00031c-EL for nsis@ietf.org; Fri, 12 May 2006 12:00:44 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id F218D11B; Fri, 12 May 2006 18:00:38 +0200 (MST) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 14982-01; Fri, 12 May 2006 18:00:31 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id C4A49144; Fri, 12 May 2006 18:00:29 +0200 (DFT) Message-ID: <4464B11B.8090609@uni-tuebingen.de> Date: Fri, 12 May 2006 18:00:27 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hancock, Robert" Subject: Re: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: john.loughney@nokia.com, stiemerling@netlab.nec.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, Hancock, Robert wrote: > hi, > > i think this is a question of what is the current deployment. aren't NAT-PTs deployed to connect 3G PS domains to the Internet? > > if NAT-PT is currently seriously deployed to any extent, we > have to deal with it. however, dealing with it may simply mean > detecting and returning an error condition. that would be one option. The other option is that the NATFW signaling can be scoped at the NAT-PT, which acts as NR. NATFW NSLP does already support this with the proxy mode. ali > > if NAT-PT is not currently seriously deployed, then we can > probably forget about it. > > r. > > >>-----Original Message----- >>From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >>Sent: 12 May 2006 11:49 >>To: stiemerling@netlab.nec.de; nsis@ietf.org >>Subject: RE: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to >>IPv6 translation) >> >> >> >> >>>The draft -11 of the NATFW NSLP is somewhat unspecified about >>>the usage of the IPv4 to IPv6 (and vice versa) transition >>>mechanism NAT Protocol Translation (NAT-PT, RFC 2766). While >>>in the past the NSLP had some text specifying how the NSLP >>>should handle NAT-PT, it has been removed. One of the reasons >>>is the draft >>>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt- >>>to-exprmntl-03.txt >>> >>>The question is where to go with NAT-PT. Should the NATFW NSLP >>>support NAT-PT or not? Probably, this is requires more a >>>political answer rather than a technical! >> >>Well, I'd say that we don't need to address NAT-PT, unless anyone in >>the audience (in the mailing list) is specifically interested in it. >> >>John >> >>_______________________________________________ >>nsis mailing list >>nsis@ietf.org >>https://www1.ietf.org/mailman/listinfo/nsis >> > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > -- Ali Fessi Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat May 13 03:24:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeoTZ-00084o-0h; Sat, 13 May 2006 03:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeoTX-00084j-Tw for nsis@ietf.org; Sat, 13 May 2006 03:23:43 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeoTW-0001MU-FV for nsis@ietf.org; Sat, 13 May 2006 03:23:43 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4D7NeEA001755; Sat, 13 May 2006 10:23:41 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 May 2006 10:23:40 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 May 2006 10:23:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) Date: Sat, 13 May 2006 10:23:39 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB4077CE@esebe100.NOE.Nokia.com> In-Reply-To: <4464B11B.8090609@uni-tuebingen.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] NATFW NSLP support for NAT-PT (IPv4 to IPv6 translation) Thread-Index: AcZ13Z/JPof6kXrLTRaRTmNAWmrL4QAgD1kw From: To: , X-OriginalArrivalTime: 13 May 2006 07:23:40.0184 (UTC) FILETIME=[284DF980:01C6765E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: stiemerling@netlab.nec.de, nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Ali, >aren't NAT-PTs deployed to connect 3G PS domains to the Internet? NAT-PTs have been discussed as a way to connected 3G IMS deployments to internet SIP deployments, but in practice, I don't know if anything has been deployed. =20 But this is more of a question to the list - does anyone see any major NAT-PT deployments, and would the NATFW NSLP be something do consider in this type of deployment? John >> if NAT-PT is currently seriously deployed to any extent, we have to=20 >> deal with it. however, dealing with it may simply mean detecting and=20 >> returning an error condition. > >that would be one option. The other option is that the NATFW=20 >signaling can be scoped at the NAT-PT, which acts as NR. >NATFW NSLP does already support this with the proxy mode. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 16 16:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6au-0002KV-11; Tue, 16 May 2006 16:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6as-0002KL-Fy for nsis@ietf.org; Tue, 16 May 2006 16:56:38 -0400 Received: from mail126.messagelabs.com ([216.82.250.99]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fg6ar-0006pw-1d for nsis@ietf.org; Tue, 16 May 2006 16:56:38 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-126.messagelabs.com!1147812916!11618649!25 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 8489 invoked from network); 16 May 2006 20:56:34 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-126.messagelabs.com with SMTP; 16 May 2006 20:56:34 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE002FD06C; Tue, 16 May 2006 16:56:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QoS NSLP INFO_SPEC and error codes Date: Tue, 16 May 2006 15:56:33 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC774C@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <445F14AD.5000001@roke.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP INFO_SPEC and error codes Thread-Index: AcZyhRSMoNU54QQ/R8GZjfsvmroXJwGm2NCA From: "Ash, Gerald R \(Jerry\), ALABS" To: "Andrew McDonald" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: "Ash, Gerald R \(Jerry\), ALABS" , attila.bader@ericsson.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Andrew, See comments below. Thanks, Jerry > -----Original Message----- > From: Andrew McDonald [mailto:andrew.mcdonald@roke.co.uk]=20 > Sent: Monday, May 08, 2006 5:52 AM > To: Ash, Gerald R (Jerry), ALABS > Cc: nsis@ietf.org; cornelia.kappler@siemens.com;=20 > attila.bader@ericsson.com > Subject: Re: [NSIS] QoS NSLP INFO_SPEC and error codes >=20 > Hi Jerry, >=20 > I've been looking at some scribbled notes I've got, and subsequent > e-mails on the subject. >=20 > At the breakfast meeting, the thing I seem to have jotted down was > "use the Optional Error-Specific Information" component of the=20 > INFO_SPEC for QSpec information. >=20 > However, in some subsequent off-list discussion, I think I went > off this idea a bit. The main problem is that you drag information > about QSPEC parameters into the NSLP. Stacking may also create > issues with this. >=20 > The subsequent suggestion was, I believe, that the QoS NSLP should=20 > provided a limited set of error codes (e.g. "Total Success", "Partial=20 > Success", "Total Failure"). The QSpec parameters then have a flag to=20 > indicate which (if any) parameters failed to be satisfied. This is=20 > signalled back to the QNI in the response. The QNI then makes the=20 > determination about whether to continue or tear down the partial=20 > reservation that has been established. >=20 > Does that sound reasonable? Does it fit with other peoples thoughts? This sounds reasonable to me. We need to nail down how this error code functionality will work. =20 What is now specified in the QSPEC I-D (Section 4.5.1 in http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt) is as follows: "When an RMF cannot interpret the QSPEC because the coding is erroneous, it raises corresponding flags in the QSPEC. The 'error flags' are located in each QSPEC Object and in each parameter. If such a flag is set, at least one QNE along the data transmission path between the QNI and QNR cannot interpret a mandatory or optional QSPEC parameter or the QSPEC object for any reason, such as a protocol error, QNE fault, etc. In this case, more detailed error information may be given in the QoS NSLP error message. That is, if possible the RMF must communicate error details to the QoS NSLP processing. QoS NSLP [QoS-SIG] describes how the erroneous message is handled further. As stated in Section 5.1.3.6 (INFO_SPEC) of [QoS-SIG]: "Values in the error subcode field are defined in each QOSM specification separately. The default value for the subcode is 0x00. A default value means that the QoS model does not want or does not need to give more information about the error/result, anything else in the subcode must be defined in the QoS model specification." That is, any additional error codes beyond those defined in [QoS-SIG] MUST be defined in individual QOSM specifications." I suggest this be modified along the lines of your suggestion so that QSPEC/RMF-specific codes are identified in the QSPEC I-D. That is, for example, the 4-bit error class is defined in QoS-NSLP as follows: "0x06 - QSPEC/RMF-specific Error" This error is set by QoS-NSLP if QSPEC/RMF sets an 8-bit QSPEC/RMF-specific error subcode, specified below. Perhaps other QSPEC/RMF-specific error codes can be defined in QoS-NSLP based on QSPEC/RMF specific failure conditions. Within the 4-bit error class "0x06 - QSPEC/RMF-specific Error", the "8-bit QSPEC/RMF-specific error subcodes" are defined and set by QSPEC/RMF; for example: 0x02 - cannot be met 0x03 - cannot be met 0xab - cannot be met 0xcd - cannot be met 0xef - cannot be met=20 etc. These '8-bit QSPEC/RMF-specific error subcodes' pertain to QSPEC parameters and are defined within the QSPEC I-D. Additional '8-bit QSPEC/RMF-specific error subcodes' pertaining to QSPEC parameters defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, etc.) should also be defined in the QOSM-specific I-Ds. Does this sound OK? If not, please make a counter proposal. > Does the 'E' flag in the QSPEC parameters already provide the=20 > necessary QSpec information? (not clear if 'error' covers > 'reservation could not be satisfied') As above, the 'E flag' would be set by QSPEC/RMF if some error condition arises wrt a QSPEC parameter. The '8-bit QSPEC/RMF-specific error subcode' is set by QSPEC/RMF to a specific value if additional information on the error is to be conveyed to the QNI. =20 > Something I've also noticed in looking at the QSpec template=20 > document is that the introduction talks about its role as a > 'toolbox', but does not talk about the processing flexibility aspect > (e.g. the fact that it allows for nodes that support different > subsets of QSpec parameters). Good point, the 'different subsets of QSPEC parameters' functionality needs to be added in the introduction. I think we need to revise somewhat the 'toolbox' description to clarify. _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 17 05:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIFi-0000zc-QB; Wed, 17 May 2006 05:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIFh-0000zX-Kc for nsis@ietf.org; Wed, 17 May 2006 05:23:33 -0400 Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgIFf-0004g5-TH for nsis@ietf.org; Wed, 17 May 2006 05:23:33 -0400 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 994B211C; Wed, 17 May 2006 11:23:30 +0200 (MST) Received: from mx5.informatik.uni-tuebingen.de ([127.0.0.1]) by localhost (mx5 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14966-05; Wed, 17 May 2006 11:23:28 +0200 (DFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id 4A65D115; Wed, 17 May 2006 11:23:28 +0200 (MST) Message-ID: <446AEB90.9060609@uni-tuebingen.de> Date: Wed, 17 May 2006 11:23:28 +0200 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP; using REA mode for blocking data flows References: <4443F69F.9000708@uni-tuebingen.de> <4D167603-348A-48BA-AB2E-634153ACF4F6@netlab.nec.de> In-Reply-To: <4D167603-348A-48BA-AB2E-634153ACF4F6@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, just a suggestion for the name of the REA message: in some earlier versions of the draft you had a UCREATE message (Upstream Create). I think UCREATE would fit better, since: - in case the data receiver (DR) is behind a firewall, UCREATE creates a firewall pinhole to receive the data - in case DR is behind a NAT it creates a NAT binding with a external address - in case DR want to block some unwanted traffic UCREATE creates a firewall rule to block this data traffic So the naming UCREATE fits well in all cases. My concerns with REA is that in few years any historical reasons for choosing this name will not be obvious and the name will be rather inappropriate. Especially using REA for blocking incoming data traffic is confusing. cheers, ali Martin Stiemerling wrote: > Hi Ali, > > I have been away on vacation and now catching up with the emails. > > The name REA (RESERVE-EXTERNAL-ADDRESS) has its roots in the time of > reserving a public reachable IP address at a NAT. The semantics of this > REA message has changed over time and does now include firewalls as well. > > We have had some proposals for a new name of REA, but none of them > could ultimately convince. My current reading for REA is, that in any > case (NAT or firewall) you do reserve the external reachable IP > address. For the NAT case, this is the public reachable IP address; for > the firewall case this is the globally routable IP address of the host > (or one of these addresses). Both "types" of addresses are external > addresses. > > However, if somebody has a good proposal for another name describing > the semantics in a better way -- send it NOW. (yet another naming > contest :-) > > Martin > > Am 17.04.2006 um 22:12 schrieb Ali Fessi: > >> Hi all, >> >> the REA mode (Reserving External Address) was originally called REA >> mode because it is used by hosts behind a NAT to reserve a publicly >> reachable IP address (and port number). >> >> Now, the REA mode is also used by hosts behind a firewall to signal >> to a firewall for blocking data traffic. >> >> Although from functionality point of view, it might be fine to use >> the same name for these two similar functionalities; but from >> terminology point of view, this is rather confusing to signal for >> blocking data traffic and call it "REA mode". >> >> So, why not use a different name that matches more the functionality, >> something like "BLOCK mode" for example?! This would make it easier >> for the readers to understand. >> >> Cheers, >> Ali >> -- >> Ali Fessi >> University of Tuebingen, Germany >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis -- Ali Fessi Computer Networks and Internet Wilhelm Schickard Institute for Computer Science University of Tuebingen, Germany Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 18 08:30:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fghd1-0000NE-Ou; Thu, 18 May 2006 08:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fghd0-0000N9-Gm for nsis@ietf.org; Thu, 18 May 2006 08:29:18 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fghcv-000772-Vp for nsis@ietf.org; Thu, 18 May 2006 08:29:18 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 213AB1BAC4D; Thu, 18 May 2006 14:21:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E0A857A-5518-4200-9F23-1BE2372757A7@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Date: Thu, 18 May 2006 14:29:09 +0200 To: nsis X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Lars Eggert Subject: [NSIS] Current Status of NATFW NSLP in 3GPP2 X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi All, Here is a short update with respect to the NATFW NSLP involvement in 3GPP2 (see also email below). The NATFW NSLP has been been added to the "Network Firewall Configuration and Control (NFCC)" document. The 3GPP2 document names is X31-20060424-006 NFCC_Baseline.doc. So it is sure that the NATFW NSLP is used as the NFCC protocol. The working group (WG31, TSG-X) is currently discussing the architecture and the work on the integration of the NSLP is expected to start soon. I will keep the NSIS working group updated about further progress. Martin > Dear all, > > You still remember the draft "Requirements for Firewall > Configuration Protocol" (draft-bajko-nsis-FW-reqs-04.txt) on > 3GPP2's requirements wrt the NATFW NSLP. 3GPP2 is calling this > protocol NFCCP (Network Firewall Configuration and Control Protocol). > > Based on this draft and further discussions between 3GPP2 members > (mainly Gabor) and the NATFW NSLP authors, the NSIS WG has been > invited by the 3GPP2 TSG-X WG 31 (PSN, packet switched networks) to > present the NATFW NSLP protocol. This 3GPP2 WG is looking for > firewall signaling protocol, running mainly between the mobile > terminal and the 3GPP2 network firewalls. > > The NATFW NSLP authors and John have prepared a slide set and > finally John has presented the slides at the last 3GPP2 meeting in > Vancouver (Jan 17th). There has been second proposal for the NFCCP > by Qualcom (http://www.ietf.org/internet-drafts/draft-paddon- > pfcp-00.txt) which is client/server based. The WG had to decided > whether is goes for a client/server or path-coupled approach. > > The presentation worked out fine and almost all questions by 3GPP2 > have been answered. The WG is in favour of the path-coupled NSIS > approach, i.e., the NSIS NATFW NSLP will be the NFCCP. Only some > open issues remained in the end (see below for a list of them). > > The slide set is available here: > > http://www.stiemerling.org/ietf/nsis/ > 3gpp2/3gpp2_nsis_natfw_overview_final.ppt > > The open issues to clarify are: > > 1) port range parameter field > 2) ICMP support > 3) Query method for firewall capabilities > 4) Mobile IPv6 support (later, probably in draft 10) > 5) Wildcarding, i.e., one shot signaling message to teardown a > whole set of policy rules belonging to a specific IP address > 6) Roaming > > All issues are currently being discussed and will be posted issue > by issue to the mailing list soon. Issue 6 is subject to further > discussions with 3GPP2, since the exact technical background is not > yet fully understood by the NATFW authors. Issue 1) has been > discussed at the last IETF meeting and has been agreed to include > this feature. Issue 2) will have a separated email thread > > > With best regards, > > Martin Stiemerling > > NEC Europe Ltd. -- Network Laboratories stiemerling@netlab.nec.de > PGP Key at: http://www.stiemerling.org/stiemerling_nec.gpg > WWW: http://www.netlab.nec.de > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 18 11:10:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgk8T-0007oQ-2F; Thu, 18 May 2006 11:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgk8R-0007nq-Ir for nsis@ietf.org; Thu, 18 May 2006 11:09:55 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgk8R-0007Sn-8C for nsis@ietf.org; Thu, 18 May 2006 11:09:55 -0400 Received: from bear.cs.columbia.edu (IDENT:QWb6eqOuobzXUJyjbv8L+rTvAGCBoaXc@bear.cs.columbia.edu [128.59.16.121]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k4IF6AX6007732 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 18 May 2006 11:09:55 -0400 (EDT) Received: from [128.59.19.246] (dhcp46.cs.columbia.edu [128.59.19.246]) (authenticated bits=0) by bear.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k4IF68fX017226 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 18 May 2006 11:06:10 -0400 Message-ID: <446C8D60.2080706@math.uni-goettingen.de> Date: Thu, 18 May 2006 11:06:08 -0400 From: Henning Peters User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nsis Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns References: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de> <53037.24.199.92.165.1147370184.squirrel@mail.piranho.net> <939CD3F7-D2B0-4AE2-9F0B-58A888AC19A4@netlab.nec.de> In-Reply-To: <939CD3F7-D2B0-4AE2-9F0B-58A888AC19A4@netlab.nec.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Martin, see inline: >> 1) I might want to configure my local NAT (fitted with an NSIS ALG) >> manually, but do not have access to a hierarchical remote NAT (e.g., >> located at ISP). Therefore, I want to have a mechanism that works >> seemlessly. Future application might support NSIS + NAT/FW NSLP >> out-of-the-box, without being able to "talk to the edge" creating a NAT >> reservation at ISP level is impossible. > > > A question ahead: Why should NAT be equipped with an NSIS ALG but > not with an NATFW NSLP? When the NAT vendor is already providing > an NSIS ALG (I assume a GIST ALG) the way to the NATFW NSLP is > not that long anymore. This seems to be a very constructed case. Sorry, surely a GIST ALG. I think it's just practical, i.e., one might extend iptables with such a functionality without much trouble, but iptables guys probably don't want to support a full NSIS stack. Iptables has a very high coverage of deployed NATs, including non-PC devices. Of course, this should not drive our thinking as it's focus is on a short-term scale, but I think we should have an idea how reality looks like beyond IETF documents. Thus, I think my scenario is very real and far away from being constructed. > However, even the local NAT is configured manually to let GIST messages > traverse and the NAT bindings for the data flow are statically configured, > how is the correlation at the edge-NAT made between the the inbound > external port and the port at the local NAT? This would require that the > NI sets the IP address and port information to the external parameters at > the local NAT? This isn't anymore the NATFW NSLP as it is right now. I don't understand this paragraph, could you explain it to me again, please. >> Also, the local NAT can be later replaced transparently with real NSIS >> machine to cope more functionality (e.g. QoS NSLP). I see this as a >> deployment advantage. Otherwise we have to believe that within all >> domains >> deployment switches to NSIS at once - this would be nice (i.e., >> IPv6), but >> hard to believe (i.e., IPv6)... ;) > The assumption is NOT that NSIS is deployed at once in all domains > (whatever > domains means here). The assumption is that at least one side of the > network > is NSIS-aware. The case you have mentioned could be already seen as > two domains (you and the operator ;-) ok. But then GIST NAT traversal is bogus anyway...!? If you have deployed GIST, adding NAT/FW NSLP is not the issue. Having support for GIST is a much harder deployment constraint. >> 2) I don't care about semantics if it does not work in reality. My >> view is >> that NAT/Firewall NSLP should avoid any type of probing, otherwise we >> are >> not much better off than BEHAVE folks doing hole-punching or praying for >> hairpin-translation. > Well, semantics are usually derived from real life. Every derivation includes errors. If there would occur no errors in the derivation process I would assume that semantics must perfectly match reality. This does not seem always the case. I argue that the semantics of LE-MRM look clean, but might not match "real life" as good as possible. > However, there are > cases where you need to obtain a public IP address even you do not > know from where your later data traffic is coming, e.g., SIP early media. Sure, most prominently all symmetric NAT issues are concerned with that problem. I don't see a reason why PC-MRM should not disallow DTInfo object. Also, GIST MRI supports wildcarding in a similar way as DTInfo supports it. > There is possibly not much probing. When you are NAT'ed, use the > LE-MRM; if not use the PC-MRM. Still you could argue about the NI > being unable to find out if it is NAT'ed our not. However, this could be > either a configuration or some other mechanisms. NAT is not a problem (-> STUN), firewalls are: What about being NAT'ed _and_ firewall'ed? How do you detect the firewalls? I only know non-deterministic approaches to do that. >> Thus, an application (aka NI+) that wants to receive incoming traffic >> should not worry about the difficulties about this operation. This means >> that it should not need to probe anything. The decision whether to use >> PC-MRM or LE-MRM requires knowledge about the network structure: Is >> there >> a firewall in the administrative domain or not. Honestly, I would not >> miss >> LE-MRM if we would drop it. > There is no knowledge about the network structure needed, i.e., you do > not care about topology and order of devices in the topology. You need > to know wether you are NAT'ed or not. This is indeed difficulty in some > environments but in many it is quite obvious. see above. >> In case we stay with LE-MRM in the spec (whether it will be used >> might be >> a different question), I think that we should design it with maximum >> deployment support in mind - in this sense I believe that we should not >> equip the semantical aspect with the highest priority, >> >> So let me pose the question the other way around: What is the use >> case for >> NAT-only operation (aka LE-MRM)? Aren't our networks already fitted >> with a >> multitude of both: NATs and firewalls?! Can we really be sure that the >> network does not change or that endpoints attach to new networks at any >> time? Those changes should be handled transparently... and LE-MRM is not >> able to do this for firewalls, but only for NATs... > Right, the LE-MRM is "only" used for NAT'ed hosts that do not know the > other > side, i.e., the data sender. In this case, the PC-MRM cannot be used. You mean: NAT'ed _and_ not firewall'ed. How would you use wildcarding in a NAT+firewall environment using PC-MRM. The same way it could be done for NAT-only case with marginal effort and complexity (from both, development and standardization perspective). Henning _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Thu May 18 11:46:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkgy-0005JW-Fx; Thu, 18 May 2006 11:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgkgy-0005HY-1k for nsis@ietf.org; Thu, 18 May 2006 11:45:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgj0X-0002ib-Hd for nsis@ietf.org; Thu, 18 May 2006 09:57:41 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgioh-00037l-2L for nsis@ietf.org; Thu, 18 May 2006 09:45:28 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 83C3B1BAC4D; Thu, 18 May 2006 15:37:34 +0200 (CEST) In-Reply-To: <53037.24.199.92.165.1147370184.squirrel@mail.piranho.net> References: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de> <53037.24.199.92.165.1147370184.squirrel@mail.piranho.net> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <939CD3F7-D2B0-4AE2-9F0B-58A888AC19A4@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Thu, 18 May 2006 15:45:23 +0200 To: Henning Peters X-Mailer: Apple Mail (2.750) X-Spam-Score: -2.6 (--) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Am 11.05.2006 um 19:56 schrieb Henning Peters: > Hi Martin, hi Robert, > > Martin said: >> ... semantically the >> purpose of LE-MRM NAT traversal support at the NTLP is >> questionable (therefore I have asked Henning about use >> cases). > > Sure: > > 1) I might want to configure my local NAT (fitted with an NSIS ALG) > manually, but do not have access to a hierarchical remote NAT (e.g., > located at ISP). Therefore, I want to have a mechanism that works > seemlessly. Future application might support NSIS + NAT/FW NSLP > out-of-the-box, without being able to "talk to the edge" creating a > NAT > reservation at ISP level is impossible. A question ahead: Why should NAT be equipped with an NSIS ALG but not with an NATFW NSLP? When the NAT vendor is already providing an NSIS ALG (I assume a GIST ALG) the way to the NATFW NSLP is not that long anymore. This seems to be a very constructed case. However, even the local NAT is configured manually to let GIST messages traverse and the NAT bindings for the data flow are statically configured, how is the correlation at the edge-NAT made between the the inbound external port and the port at the local NAT? This would require that the NI sets the IP address and port information to the external parameters at the local NAT? This isn't anymore the NATFW NSLP as it is right now. > > Also, the local NAT can be later replaced transparently with real NSIS > machine to cope more functionality (e.g. QoS NSLP). I see this as a > deployment advantage. Otherwise we have to believe that within all > domains > deployment switches to NSIS at once - this would be nice (i.e., > IPv6), but > hard to believe (i.e., IPv6)... ;) The assumption is NOT that NSIS is deployed at once in all domains (whatever domains means here). The assumption is that at least one side of the network is NSIS-aware. The case you have mentioned could be already seen as two domains (you and the operator ;-) > > 2) I don't care about semantics if it does not work in reality. My > view is > that NAT/Firewall NSLP should avoid any type of probing, otherwise > we are > not much better off than BEHAVE folks doing hole-punching or > praying for > hairpin-translation. Well, semantics are usually derived from real life. However, there are cases where you need to obtain a public IP address even you do not know from where your later data traffic is coming, e.g., SIP early media. There is possibly not much probing. When you are NAT'ed, use the LE-MRM; if not use the PC-MRM. Still you could argue about the NI being unable to find out if it is NAT'ed our not. However, this could be either a configuration or some other mechanisms. > > Thus, an application (aka NI+) that wants to receive incoming traffic > should not worry about the difficulties about this operation. This > means > that it should not need to probe anything. The decision whether to use > PC-MRM or LE-MRM requires knowledge about the network structure: Is > there > a firewall in the administrative domain or not. Honestly, I would > not miss > LE-MRM if we would drop it. There is no knowledge about the network structure needed, i.e., you do not care about topology and order of devices in the topology. You need to know wether you are NAT'ed or not. This is indeed difficulty in some environments but in many it is quite obvious. > > In case we stay with LE-MRM in the spec (whether it will be used > might be > a different question), I think that we should design it with maximum > deployment support in mind - in this sense I believe that we should > not > equip the semantical aspect with the highest priority, > > So let me pose the question the other way around: What is the use > case for > NAT-only operation (aka LE-MRM)? Aren't our networks already fitted > with a > multitude of both: NATs and firewalls?! Can we really be sure that the > network does not change or that endpoints attach to new networks at > any > time? Those changes should be handled transparently... and LE-MRM > is not > able to do this for firewalls, but only for NATs... Right, the LE-MRM is "only" used for NAT'ed hosts that do not know the other side, i.e., the data sender. In this case, the PC-MRM cannot be used. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 09:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiASA-0003Rt-ST; Mon, 22 May 2006 09:28:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiARH-0002xS-JI for nsis@ietf.org; Mon, 22 May 2006 09:27:15 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiAOf-0008IA-TP for nsis@ietf.org; Mon, 22 May 2006 09:24:35 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1148301682!537313!30 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 17634 invoked from network); 22 May 2006 12:47:02 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-120.messagelabs.com with SMTP; 22 May 2006 12:47:02 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE003915C6; Mon, 22 May 2006 08:46:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comments Date: Mon, 22 May 2006 07:46:46 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC77A4@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comments Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorswH9wAAQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Tschofenig, Hannes" , "nsis" X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Thanks for the comments.=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Friday, May 12, 2006 5:09 AM > To: nsis > Subject: [NSIS] QSPEC Comments >=20 > Hi all >=20 > I have a few minor comments for the QSPEC draft: >=20 > - Use either 'QoS NSLP' or 'QoS-NSLP' terminology. The QoS NSLP draft > uses 'QoS NSLP' > - Don't use RFC 2119 language in examples (e.g., Section=20 > 4.3). The same is true for RFC 2119 language in the appendix.=20 > - Review RFC 2119 language in the text. Example: First sentence in > Section 4.6: MAY is inappropriate there.=20 > - Ability to define mandatory QoS parameters in QOSMs no clear > - Reference to [NSIS-EXTENSIBILITY] in the IANA consideration=20 > section is not a good idea. It also needs to be removed from the > normative reference since otherwise this document will be blocked.=20 Agree with all the above comments. > - You shouldn't request IANA to allocate value for QOSMs in the QSPEC > template document. Then where should that be done, in the QoS-NSLP document perhaps? IMO it needs to be done either in the QSPEC document or QoS-NSLP document. > - Why do you need information of the type of QoS signaling in=20 > the QSPEC template (e.g., sender-initiated, receiver-oriented QoS > signaling)? Section 6 specifies procedures for using QSPEC in the RMF, for various scenarios. For example, the "RSVP-style" scenario specified in Section 6.2 was specifically requested at one of the Interim NSIS meetings. It ensures backward compatibility with RSVP. > - Is the idea of the tunneled parameter flag inline with the QoS NSLP > understanding of tunneling? AFAIK it is consistent. The flag is set as specified in Section 4.5.2: " Each QSPEC parameter has an associated 'tunneled-parameter flag'. When a RESERVE message is tunneled through a domain, QNEs inside the domain cannot update read-write parameters. The egress QNE in a domain has two choices: either it is configured to have the knowledge to update the parameters correctly. Or it cannot update the parameters. In this case it MUST set the tunneled-parameter flag to tell the QNI (or QNR) that the information contained in the read-write parameter is most likely incorrect (or a lower bound)." The egress QNE (end of tunnel) sets the flag accordingly. Do you think this is inconsistent? > - Use capitalized words in captions and headlines. The RFC editor will > thank you. =20 >=20 > Other comments have been posted by Andrew already (e.g., definition of > mandatory parameters).=20 Haven't heard further from Andrew RE error-codes discussion, so I think we're ready now to update the QSPEC I-D. Thanks, Jerry >=20 > Ciao > Hannes >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 09:41:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAfA-0007Tb-Ba; Mon, 22 May 2006 09:41:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAf9-0007TW-St for nsis@ietf.org; Mon, 22 May 2006 09:41:35 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiAf8-0000u2-8O for nsis@ietf.org; Mon, 22 May 2006 09:41:35 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k4MDfVE8016514; Mon, 22 May 2006 15:41:31 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k4MDfVHU026697; Mon, 22 May 2006 15:41:31 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 15:41:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC Comments Date: Mon, 22 May 2006 15:41:35 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comments Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorswH9wAAQAAMJbcA= From: "Tschofenig, Hannes" To: "Ash, Gerald R \(Jerry\), ALABS" , "nsis" X-OriginalArrivalTime: 22 May 2006 13:41:31.0012 (UTC) FILETIME=[6EE38C40:01C67DA5] X-Spam-Score: 0.1 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry,=20 thanks for your response.=20 > Hi Hannes, >=20 > Thanks for the comments.=20 >=20 > > -----Original Message----- > > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > > Sent: Friday, May 12, 2006 5:09 AM > > To: nsis > > Subject: [NSIS] QSPEC Comments > >=20 > > Hi all > >=20 > > I have a few minor comments for the QSPEC draft: > >=20 > > - Use either 'QoS NSLP' or 'QoS-NSLP' terminology. The QoS=20 > NSLP draft > > uses 'QoS NSLP' > > - Don't use RFC 2119 language in examples (e.g., Section=20 > > 4.3). The same is true for RFC 2119 language in the appendix.=20 > > - Review RFC 2119 language in the text. Example: First sentence in > > Section 4.6: MAY is inappropriate there.=20 > > - Ability to define mandatory QoS parameters in QOSMs no clear > > - Reference to [NSIS-EXTENSIBILITY] in the IANA consideration=20 > > section is not a good idea. It also needs to be removed from the > > normative reference since otherwise this document will be blocked.=20 >=20 > Agree with all the above comments. >=20 > > - You shouldn't request IANA to allocate value for QOSMs in=20 > the QSPEC > > template document. >=20 > Then where should that be done, in the QoS-NSLP document perhaps? IMO > it needs to be done either in the QSPEC document or QoS-NSLP document. I think that this should be done in QOSMs.=20 That's the right place.=20 >=20 > > - Why do you need information of the type of QoS signaling in=20 > > the QSPEC template (e.g., sender-initiated, receiver-oriented QoS > > signaling)? >=20 > Section 6 specifies procedures for using QSPEC in the RMF, for various > scenarios. For example, the "RSVP-style" scenario specified=20 > in Section > 6.2 was specifically requested at one of the Interim NSIS=20 > meetings. It > ensures backward compatibility with RSVP. But you have this information already in the QoS NSLP and it would be trivial to indicate this info when the QoS NSLP interacts with the RMF. I think it is duplicate info.=20 >=20 > > - Is the idea of the tunneled parameter flag inline with=20 > the QoS NSLP > > understanding of tunneling? >=20 > AFAIK it is consistent. The flag is set as specified in=20 > Section 4.5.2: >=20 > " Each QSPEC parameter has an associated 'tunneled-parameter flag'. > When a RESERVE message is tunneled through a domain, QNEs=20 > inside the > domain cannot update read-write parameters. The egress QNE in a > domain has two choices: either it is configured to have=20 > the knowledge > to update the parameters correctly. Or it cannot update the > parameters. In this case it MUST set the=20 > tunneled-parameter flag to > tell the QNI (or QNR) that the information contained in the > read-write parameter is most likely incorrect (or a lower bound)." >=20 > The egress QNE (end of tunnel) sets the flag accordingly. Do=20 > you think > this is inconsistent? The tunneled QSPEC is never interpreted in the way how the QoS NSLP works and hence interior QoS nodes will never see the flag.=20 >=20 > > - Use capitalized words in captions and headlines. The RFC=20 > editor will > > thank you. =20 > >=20 > > Other comments have been posted by Andrew already (e.g.,=20 > definition of > > mandatory parameters).=20 >=20 > Haven't heard further from Andrew RE error-codes discussion,=20 > so I think > we're ready now to update the QSPEC I-D. Ok.=20 Ciao Hannes >=20 > Thanks, > Jerry >=20 > >=20 > > Ciao > > Hannes > >=20 > > _______________________________________________ > > nsis mailing list > > nsis@ietf.org > > https://www1.ietf.org/mailman/listinfo/nsis > >=20 >=20 > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 09:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAvG-0005PF-Sk; Mon, 22 May 2006 09:58:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAvF-0005PA-Cj for nsis@ietf.org; Mon, 22 May 2006 09:58:13 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiAvE-0001ZB-0g for nsis@ietf.org; Mon, 22 May 2006 09:58:13 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1148306169!8836955!22 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 15249 invoked from network); 22 May 2006 13:58:10 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-15.tower-120.messagelabs.com with SMTP; 22 May 2006 13:58:10 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE0039557F; Mon, 22 May 2006 09:58:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comments Date: Mon, 22 May 2006 08:58:08 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC77A6@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comments Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorswH9wAAQAAMJbcAAAEPqIA== From: "Ash, Gerald R \(Jerry\), ALABS" To: "Tschofenig, Hannes" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, > > > - You shouldn't request IANA to allocate value for QOSMs in the > > > QSPEC template document. > > Then where should that be done, in the QoS-NSLP document perhaps? > > IMO it needs to be done either in the QSPEC document or QoS-NSLP > > document. > I think that this should be done in QOSMs.=20 > That's the right place. That makes no sense to me. A registry must be established to be *used* by new QOSMs, as they are developed. We don't want each QOSM I-D to establish a new registry. I think the registry as specified in the QSPEC is OK. It's also OK with me to put it in the QoS-NSLP document. > > > - Why do you need information of the type of QoS signaling in=20 > > > the QSPEC template (e.g., sender-initiated, receiver-oriented QoS > > > signaling)? > > Section 6 specifies procedures for using QSPEC in the RMF, for > > various scenarios. For example, the "RSVP-style" scenario > > specified in Section 6.2 was specifically requested at one of the > > Interim NSIS meetings. It ensures backward compatibility with > > RSVP. > But you have this information already in the QoS NSLP and it would be > trivial to indicate this info when the QoS NSLP interacts with the > RMF. I think it is duplicate info.=20 I don't see any such info in the QoS-NSLP document. Where are you looking? In any case, since these procedures relate to the RMF, they belong in the QSPEC rather than QoS-NSLP. > > > - Is the idea of the tunneled parameter flag inline with the QoS > > > NSLP understanding of tunneling? > > AFAIK it is consistent. The flag is set as specified in Section > > 4.5.2: > >=20 > > " Each QSPEC parameter has an associated 'tunneled-parameter flag'. > > When a RESERVE message is tunneled through a domain, QNEs inside > > the domain cannot update read-write parameters. The egress QNE > > in a domain has two choices: either it is configured to have=20 > > the knowledge to update the parameters correctly. Or it cannot > > update the parameters. In this case it MUST set the=20 > > tunneled-parameter flag to tell the QNI (or QNR) that the > > information contained in the read-write parameter is most likely > > incorrect (or a lower bound)." > >=20 > > The egress QNE (end of tunnel) sets the flag accordingly. Do you > > think this is inconsistent? > The tunneled QSPEC is never interpreted in the way how the QoS NSLP > works and hence interior QoS nodes will never see the flag. What you say is correct. Interior QNEs will not see the flag, and nothing is stated in the QSPEC that contradicts that. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 10:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB2e-0007Yb-HK; Mon, 22 May 2006 10:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB2c-0007YV-LI for nsis@ietf.org; Mon, 22 May 2006 10:05:50 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiB2b-0001xR-7l for nsis@ietf.org; Mon, 22 May 2006 10:05:50 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 7E00E1BAC4D; Mon, 22 May 2006 15:57:28 +0200 (CEST) In-Reply-To: <42260.24.199.92.165.1147370340.squirrel@mail.piranho.net> References: <37901.24.199.92.165.1147285957.squirrel@mail.piranho.net> <21A356F7-E84A-4131-AEE0-7872E21D4CAB@netlab.nec.de> <42260.24.199.92.165.1147370340.squirrel@mail.piranho.net> Mime-Version: 1.0 (Apple Message framework v750) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7CB9AE4B-E796-4D9B-B2E0-EC4E6B02F8FC@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Mon, 22 May 2006 16:05:46 +0200 To: Henning Peters X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Henning, Am 11.05.2006 um 19:59 schrieb Henning Peters: > Hi Martin, > >> Does this imply C:NF(NAT) being NATFW NSLP unaware or do you say >> C:NF(NAT) is NATFW NSLP aware but does not care about the message? >> >> The picture does not show the NATFW NSLP operation >> if C:NF(NAT) is NATFW NSLP aware. > > C is a NATFW NSLP aware hop with the artificial restriction that it > does > not add port information. By this negative conjecture I wanted to show > that the port indeed is necessary for upstream NAPTs, not only the > edge. > My point was that LE-MRM does not only talk to the edge (as Robert > said > previously), but also to all intermediate NAPTs. I see us on the same side. The intermediate NAPTs need the port information as well. However, Robert's comment on "need for talking to the edge" is valid, since the host behind a NAT is basically interested in the external IP address and port and does not care about what is happening in between. Martin > > Henning > >> >> Can you clarify this? Otherwise the answer to this email is going >> full of ifs. >> >> Thanks, >> >> Martin > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 10:08:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB5C-0008HR-Lz; Mon, 22 May 2006 10:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiB5A-0008HD-Vt for nsis@ietf.org; Mon, 22 May 2006 10:08:28 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiB59-00025q-G4 for nsis@ietf.org; Mon, 22 May 2006 10:08:28 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k4ME8Nng014552; Mon, 22 May 2006 16:08:23 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k4ME8No9030441; Mon, 22 May 2006 16:08:23 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 16:08:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QSPEC Comments Date: Mon, 22 May 2006 16:08:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comments Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorswH9wAAQAAMJbcAAAEPqIAAAhfyQ From: "Tschofenig, Hannes" To: "Ash, Gerald R \(Jerry\), ALABS" , "nsis" X-OriginalArrivalTime: 22 May 2006 14:08:22.0966 (UTC) FILETIME=[2FB03560:01C67DA9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry,=20 thanks for your quick response.=20 > Hi Hannes, >=20 > > > > - You shouldn't request IANA to allocate value for QOSMs in the > > > > QSPEC template document. >=20 > > > Then where should that be done, in the QoS-NSLP document perhaps? > > > IMO it needs to be done either in the QSPEC document or QoS-NSLP > > > document. >=20 > > I think that this should be done in QOSMs.=20 > > That's the right place. >=20 > That makes no sense to me. A registry must be established to=20 > be *used* > by new QOSMs, as they are developed. We don't want each QOSM I-D to > establish a new registry. I think the registry as specified in the > QSPEC is OK. It's also OK with me to put it in the QoS-NSLP document. I see where we have a disagreement.=20 You can create a registry in the QSPEC template for later usage by the QOSMs but you cannot request IANA to already allocate values for QOSMs that are described in separate specifications.=20 Hence, you create a registry at the QSPEC template document and you provide information about the allocation strategy but you do not request IANA to allocate even a single value.=20 >=20 > > > > - Why do you need information of the type of QoS signaling in=20 > > > > the QSPEC template (e.g., sender-initiated,=20 > receiver-oriented QoS > > > > signaling)? >=20 > > > Section 6 specifies procedures for using QSPEC in the RMF, for > > > various scenarios. For example, the "RSVP-style" scenario > > > specified in Section 6.2 was specifically requested at one of the > > > Interim NSIS meetings. It ensures backward compatibility with > > > RSVP. >=20 > > But you have this information already in the QoS NSLP and=20 > it would be > > trivial to indicate this info when the QoS NSLP interacts with the > > RMF. I think it is duplicate info.=20 >=20 > I don't see any such info in the QoS-NSLP document. Where are you > looking? In any case, since these procedures relate to the RMF, they > belong in the QSPEC rather than QoS-NSLP. When the QoS NSLP starts an interaction then it needs to know whether it is doing a sender-initiated or a receiver-initiated QoS signaling exchange. Section 4, for example, shows the different message exchanges.=20 >=20 > > > > - Is the idea of the tunneled parameter flag inline with the QoS > > > > NSLP understanding of tunneling? >=20 > > > AFAIK it is consistent. The flag is set as specified in Section > > > 4.5.2: > > >=20 > > > " Each QSPEC parameter has an associated=20 > 'tunneled-parameter flag'. > > > When a RESERVE message is tunneled through a domain,=20 > QNEs inside > > > the domain cannot update read-write parameters. The egress QNE > > > in a domain has two choices: either it is configured to have=20 > > > the knowledge to update the parameters correctly. Or it cannot > > > update the parameters. In this case it MUST set the=20 > > > tunneled-parameter flag to tell the QNI (or QNR) that the > > > information contained in the read-write parameter is=20 > most likely > > > incorrect (or a lower bound)." > > >=20 > > > The egress QNE (end of tunnel) sets the flag accordingly. Do you > > > think this is inconsistent? >=20 > > The tunneled QSPEC is never interpreted in the way how the QoS NSLP > > works and hence interior QoS nodes will never see the flag. >=20 > What you say is correct. Interior QNEs will not see the flag, and > nothing is stated in the QSPEC that contradicts that. Who is going to interpret it?=20 Ciao Hannes >=20 > Thanks, > Jerry >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 10:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBAm-0002JF-A4; Mon, 22 May 2006 10:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBAk-0002JA-Mn for nsis@ietf.org; Mon, 22 May 2006 10:14:14 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiBAj-0002PF-6a for nsis@ietf.org; Mon, 22 May 2006 10:14:14 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id AAF761BAC4D; Mon, 22 May 2006 16:05:52 +0200 (CEST) In-Reply-To: <446AEB90.9060609@uni-tuebingen.de> References: <4443F69F.9000708@uni-tuebingen.de> <4D167603-348A-48BA-AB2E-634153ACF4F6@netlab.nec.de> <446AEB90.9060609@uni-tuebingen.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B9952D5-3530-4954-9BDC-638B879D9824@netlab.nec.de> Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NATFW NSLP; using REA mode for blocking data flows Date: Mon, 22 May 2006 16:14:11 +0200 To: Ali Fessi X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Ali, Thanks for the suggestion. I am in dislike about UCREATE, because the current REA and CREATE have basically two very different semantics. CREATE is creating a path from the sender to the receiver, where REA is solely reserving the resources for a CREATE. The "upstream" part sounds reasonable for a new name, but Robert has pointed out that this term might be confusing for the reader. The direction might not be obvious... So we still need a new name :-) Any other suggestions? Martin Am 17.05.2006 um 11:23 schrieb Ali Fessi: > Hi Martin, > > just a suggestion for the name of the REA message: > > in some earlier versions of the draft you had a UCREATE message > (Upstream Create). > > I think UCREATE would fit better, since: > > - in case the data receiver (DR) is behind a firewall, UCREATE > creates a firewall pinhole to receive the data > > - in case DR is behind a NAT it creates a NAT binding with a > external address > > - in case DR want to block some unwanted traffic UCREATE creates a > firewall rule to block this data traffic > > So the naming UCREATE fits well in all cases. > > My concerns with REA is that in few years any historical reasons > for choosing this name will not be obvious and the name will be > rather inappropriate. > > Especially using REA for blocking incoming data traffic is confusing. > > cheers, > ali > > > > Martin Stiemerling wrote: >> Hi Ali, >> I have been away on vacation and now catching up with the emails. >> The name REA (RESERVE-EXTERNAL-ADDRESS) has its roots in the time >> of reserving a public reachable IP address at a NAT. The >> semantics of this REA message has changed over time and does now >> include firewalls as well. >> We have had some proposals for a new name of REA, but none of >> them could ultimately convince. My current reading for REA is, >> that in any case (NAT or firewall) you do reserve the external >> reachable IP address. For the NAT case, this is the public >> reachable IP address; for the firewall case this is the globally >> routable IP address of the host (or one of these addresses). Both >> "types" of addresses are external addresses. >> However, if somebody has a good proposal for another name >> describing the semantics in a better way -- send it NOW. (yet >> another naming contest :-) >> Martin >> Am 17.04.2006 um 22:12 schrieb Ali Fessi: >>> Hi all, >>> >>> the REA mode (Reserving External Address) was originally called >>> REA mode because it is used by hosts behind a NAT to reserve a >>> publicly reachable IP address (and port number). >>> >>> Now, the REA mode is also used by hosts behind a firewall to >>> signal to a firewall for blocking data traffic. >>> >>> Although from functionality point of view, it might be fine to >>> use the same name for these two similar functionalities; but >>> from terminology point of view, this is rather confusing to >>> signal for blocking data traffic and call it "REA mode". >>> >>> So, why not use a different name that matches more the >>> functionality, something like "BLOCK mode" for example?! This >>> would make it easier for the readers to understand. >>> >>> Cheers, >>> Ali >>> -- >>> Ali Fessi >>> University of Tuebingen, Germany >>> >>> _______________________________________________ >>> nsis mailing list >>> nsis@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nsis > > > -- > Ali Fessi > Computer Networks and Internet > Wilhelm Schickard Institute for Computer Science > University of Tuebingen, Germany > Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220 > EMail: ali.fessi@uni-tuebingen.de > Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 10:21:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBHa-0004lh-Ge; Mon, 22 May 2006 10:21:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiBHY-0004lb-Nd for nsis@ietf.org; Mon, 22 May 2006 10:21:16 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiBHX-0002kG-Fj for nsis@ietf.org; Mon, 22 May 2006 10:21:16 -0400 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-10.tower-121.messagelabs.com!1148307514!10375917!47 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 18357 invoked from network); 22 May 2006 14:21:11 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-10.tower-121.messagelabs.com with SMTP; 22 May 2006 14:21:11 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.89) by attrh3i.attrh.att.com (7.2.052) id 444BA5FE00396DA8; Mon, 22 May 2006 10:21:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [NSIS] QSPEC Comments Date: Mon, 22 May 2006 09:21:06 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC77A7@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QSPEC Comments Thread-Index: AcZ1odRCtn6HIQz5SteZEa5CaDorswH9wAAQAAMJbcAAAEPqIAAAhfyQAABYmZA= From: "Ash, Gerald R \(Jerry\), ALABS" To: "Tschofenig, Hannes" , "nsis" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Ash, Gerald R \(Jerry\), ALABS" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Hannes, Further comments. > I see where we have a disagreement.=20 >=20 > You can create a registry in the QSPEC template for later usage by the > QOSMs but you cannot request IANA to already allocate values for QOSMs > that are described in separate specifications.=20 >=20 > Hence, you create a registry at the QSPEC template document and you > provide information about the allocation strategy but you do=20 > not request IANA to allocate even a single value.=20 OK. > > > > > - Why do you need information of the type of QoS signaling in=20 > > > > > the QSPEC template (e.g., sender-initiated, receiver-oriented > > > > > QoS signaling)? > > > > Section 6 specifies procedures for using QSPEC in the RMF, for > > > > various scenarios. For example, the "RSVP-style" scenario > > > > specified in Section 6.2 was specifically requested at one of > > > > the Interim NSIS meetings. It ensures backward compatibility > > > > with RSVP. > > > But you have this information already in the QoS NSLP and it > > > would be trivial to indicate this info when the QoS NSLP > > > interacts with the RMF. I think it is duplicate info.=20 > > I don't see any such info in the QoS-NSLP document. Where are you > > looking? In any case, since these procedures relate to the RMF, > > they belong in the QSPEC rather than QoS-NSLP. > When the QoS NSLP starts an interaction then it needs to know=20 > whether it is doing a sender-initiated or a receiver-initiated QoS > signaling exchange. >=20 > Section 4, for example, shows the different message exchanges. Section 4 of QoS-NSLP doesn't contain the same info as in Section 6 in the QSPEC. The latter is oriented toward RMF procedures, which properly belongs in the QSPEC. I don't see much overlap between the two documents with respect to these procedures. =20 > > > The tunneled QSPEC is never interpreted in the way how the QoS > > > NSLP works and hence interior QoS nodes will never see the flag. > > What you say is correct. Interior QNEs will not see the flag, and > > nothing is stated in the QSPEC that contradicts that. > Who is going to interpret it?=20 As stated in the QSPEC, the flag is interpreted by the QNI, ingress QNE (start of tunnel in a domain), egress QNE (end of tunnel in a domain), or QNR. Thanks, Jerry _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 22 11:12:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiC4N-0004BS-2D; Mon, 22 May 2006 11:11:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiC4L-0004BN-JW for nsis@ietf.org; Mon, 22 May 2006 11:11:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FiC4J-0005Mz-4g for nsis@ietf.org; Mon, 22 May 2006 11:11:41 -0400 Received: (qmail invoked by alias); 22 May 2006 15:11:37 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp034) with SMTP; 22 May 2006 17:11:37 +0200 X-Authenticated: #29516787 Message-ID: <4471D4A7.6030703@gmx.net> Date: Mon, 22 May 2006 17:11:35 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QSPEC Comments References: <9473683187ADC049A855ED2DA739ABCA0DDC77A7@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC77A7@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nsis , "Tschofenig, Hannes" X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, I guess that these two issues are largely a matter of the worksplit between the QoS NSLP and the QSPEC template draft. I thought that the QoS NSLP deals with signaling aspects but I seem to be wrong. > Section 4 of QoS-NSLP doesn't contain the same info as in Section 6 in > the QSPEC. The latter is oriented toward RMF procedures, which properly > belongs in the QSPEC. I don't see much overlap between the two > documents with respect to these procedures. > > >>>>The tunneled QSPEC is never interpreted in the way how the QoS >>>>NSLP works and hence interior QoS nodes will never see the flag. > > >>>What you say is correct. Interior QNEs will not see the flag, and >>>nothing is stated in the QSPEC that contradicts that. > > >>Who is going to interpret it? > > > As stated in the QSPEC, the flag is interpreted by the QNI, ingress QNE > (start of tunnel in a domain), egress QNE (end of tunnel in a domain), > or QNR. Ciao Hannes > > Thanks, > Jerry > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 23 07:17:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUtF-0003ht-Mv; Tue, 23 May 2006 07:17:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUtE-0003hj-LX for nsis@ietf.org; Tue, 23 May 2006 07:17:28 -0400 Received: from wr-out-0506.google.com ([64.233.184.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiUtC-0001qb-Cx for nsis@ietf.org; Tue, 23 May 2006 07:17:28 -0400 Received: by wr-out-0506.google.com with SMTP id 57so1230279wri for ; Tue, 23 May 2006 04:17:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SJUycFgici54zxE6Yrq4E5L2s17An89EZlOPaQvjn1+7rK3wulxnFXe3iY7OL0nr0jLPDRenbeAu5hJrn8ZN91qBgK0IZ9amKezTMi/xsZtlsMo2rH4Lu3htwlCe19CAsJ6vzO5Xv88yCfGDJKQSpieL+RxcJG3gOOqz/JPZfL4= Received: by 10.65.43.20 with SMTP id v20mr1654981qbj; Tue, 23 May 2006 04:17:26 -0700 (PDT) Received: by 10.65.152.11 with HTTP; Tue, 23 May 2006 04:17:25 -0700 (PDT) Message-ID: <5a26be460605230417o7784d27bo31fa42361c1f56a5@mail.gmail.com> Date: Tue, 23 May 2006 19:17:25 +0800 From: "=?GB2312?B?sfOx8831?=" To: nsis@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [NSIS] NSIS run on MIPL ? X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2007936433==" Errors-To: nsis-bounces@ietf.org --===============2007936433== Content-Type: multipart/alternative; boundary="----=_Part_121517_16128485.1148383045699" ------=_Part_121517_16128485.1148383045699 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi All: I am a student of Beijing University of Posts and Telecommunications, China= . I have studied NSIS for several months. As is knowen to all that NSIS is run on IP like the figure below. NSLP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NTLP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +--------------------------------------------------------------+ IP v4/v6 For our lab have done some research on MIPL (Mobile IPv6 for Linux. http://chasey.mobile-ipv6.org/software/). And now I want to combine NSIS an= d MIPL ---- run NSIS on MIPL. NSLP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NTLP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +------------------------------------------------------------+ MIPL I don't know whether this idea is rational and doable .I need some suggestions. Thank you, everyone who read this mail. Bestwishes! Binbin Wang 2006-5-23 --=20 *i*memo*ce* journey ------=_Part_121517_16128485.1148383045699 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi All:

I am a student of Beijing University of Posts and Telecommunications, Ch= ina. I have studied  NSIS for several months. As is knowen to all that= NSIS is run on IP like the figure below.

            =             &nb= sp;       NSLP
    &nb= sp;       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 &n= bsp;            = ;            &n= bsp;     NTLP
      &n= bsp;     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
   &n= bsp;       +---------------------------------= -----------------------------+
            = ;            &n= bsp;      IP v4/v6     &n= bsp;

For our lab have done some research on MIPL (Mobile IPv6 for Linux. &nbs= p;http://chasey.mobile-= ipv6.org/software/). And now I want to combine NSIS and MIPL ---- run N= SIS on MIPL.=20

           &nbs= p;            &= nbsp;       NSLP
    &= nbsp;       =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 &n= bsp;            = ;            &n= bsp;     NTLP
      &n= bsp;     =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  &n= bsp;         +----------------= --------------------------------------------+
            = ;            &n= bsp;       MIPL    
&= nbsp;
I don't know whether this idea is rational and doable .I need some= suggestions. Thank you, everyone who read this mail.
   =
Bestwishes!
 
           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Binbin Wang
           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     2006-5-23
     &n= bsp;            = ;            &n= bsp;            = ;    
 


--
*i*m= emo*ce* journey=20 ------=_Part_121517_16128485.1148383045699-- --===============2007936433== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============2007936433==-- From nsis-bounces@ietf.org Tue May 23 08:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWM5-0005sE-6D; Tue, 23 May 2006 08:51:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWM3-0005s4-2O for nsis@ietf.org; Tue, 23 May 2006 08:51:19 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWM2-0006A8-Bl for nsis@ietf.org; Tue, 23 May 2006 08:51:19 -0400 Received: from [10.1.1.109] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 0DAD81BAC4D; Tue, 23 May 2006 14:42:51 +0200 (CEST) In-Reply-To: <446C8D60.2080706@math.uni-goettingen.de> References: <0B8F805F-DB4A-49D4-81A9-F29724C34AF7@netlab.nec.de> <53037.24.199.92.165.1147370184.squirrel@mail.piranho.net> <939CD3F7-D2B0-4AE2-9F0B-58A888AC19A4@netlab.nec.de> <446C8D60.2080706@math.uni-goettingen.de> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Martin Stiemerling Subject: Re: [NSIS] NAT/Firewall NSLP LE-MRM/DTINFO concerns Date: Tue, 23 May 2006 14:51:17 +0200 To: Henning Peters X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 Cc: nsis X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Henning, Am 18.05.2006 um 17:06 schrieb Henning Peters: > Hi Martin, > > see inline: > > >> 1) I might want to configure my local NAT (fitted with an NSIS ALG) > >> manually, but do not have access to a hierarchical remote NAT > (e.g., > >> located at ISP). Therefore, I want to have a mechanism that works > >> seemlessly. Future application might support NSIS + NAT/FW NSLP > >> out-of-the-box, without being able to "talk to the edge" > creating a NAT > >> reservation at ISP level is impossible. > > > > > > A question ahead: Why should NAT be equipped with an NSIS ALG but > > not with an NATFW NSLP? When the NAT vendor is already providing > > an NSIS ALG (I assume a GIST ALG) the way to the NATFW NSLP is > > not that long anymore. This seems to be a very constructed case. > > Sorry, surely a GIST ALG. I think it's just practical, i.e., one might > extend iptables with such a functionality without much trouble, but > iptables guys probably don't want to support a full NSIS stack. > Iptables Here I see a strong disagreement and some issues on predicting future. I believe that the iptables folks wouldn't care about a GIST ALG but rely on somebody else to program the NSIS stack. However, that's trying to tell the future. > has a very high coverage of deployed NATs, including non-PC > devices. Of > course, this should not drive our thinking as it's focus is on a > short-term scale, but I think we should have an idea how reality looks > like beyond IETF documents. Thus, I think my scenario is very real and > far away from being constructed. > > > However, even the local NAT is configured manually to let GIST > messages > > traverse and the NAT bindings for the data flow are statically > configured, > > how is the correlation at the edge-NAT made between the the inbound > > external port and the port at the local NAT? This would require > that the > > NI sets the IP address and port information to the external > parameters at > > the local NAT? This isn't anymore the NATFW NSLP as it is right now. > > I don't understand this paragraph, could you explain it to me > again, please. Sorry for being so fuzzy; I assume it would need paper to sketch it in a good way. Anyway, since we some miles apart, I will try to write it down. Two cases to distinguish a) GIST unaware NAT traversal and b) GIST aware NAT traversal, i.e., the NAT has a GIST ALG. The topology is given as NI+ ~~~~~ home-NAT ~~~~~ edge-NAT ~~~~~ the Internet NATFW sig. ========|=========>| data direction <----------<-----------------<--------------- The home-NAT is either case a) or b) For a): The NATFW signalling (on top of GIST) may pass through the home NAT, even though this can be tricky. [Try sending IP datagrams with IP option set to router alert through your home-NAT. Typically, the home-NAT will not forward these packets.] (Here it is assumed to run with PC-MRM, i.e. ports are included) The NATFW signalling will reach the edge-NAT and the NI+ can exchange signalling messages with the edge-NAT, either via D-MODE or C-MODE, latter would be preferable, because of the NAT. The data flow information stored in the MRI is not usable by the edge-NAT, since the data flow receiver's IP address is set to a private IP address the respective private port number (if applicable). The edge-NAT could obtain an external IP address and port number, but it cannot make the mapping between external IP address/port and the inbound IP address/port at the home-NAT. The NI+ would be required to foresee this situation and to obtain the IP/port at the home-NAT in advance, add this in the MRI as destination address and send the message. However, this looks rather odd. For b) Here, the home-NAT would intercept the signalling and modify the MRI according to the NAT traversal needs (i.e. port translation, etc). This would work, since the GIST-ALG can modify the MRI and set the mapping entries in the NAT accordingly. (see also the question later!) The edge-NAT would get an MRI with destination address set to the external IP/port at the home-NAT. It works fine for the assumption PC-MRM, with LE-MRM it would not work. PC-MRM is anyway used when the data sender is known in advanced, but there are many cases where the data sender is not known. For instance, but not limiting to, SIP early media and a server behind a NAT. Question: Would the GIST-ALG just intercept the messages and modify them on the fly or would it act as a peering GIST node, i.e., your messaging association is done between NI+ and the home-NAT? Coming to a conclusion: As you have said, having ports included in the LE-MRM MRI would allow case b), semantically, they do not belong there, because they are not needed to route the message. This leads more to a global question: How is the NAT traversal of NSIS seen? I do not see consensus about this issue in the WG, i.e., how to deal with GIST-enabled NATs that do not have the NSLP installed. > > >> Also, the local NAT can be later replaced transparently with > real NSIS > >> machine to cope more functionality (e.g. QoS NSLP). I see this as a > >> deployment advantage. Otherwise we have to believe that within all > >> domains > >> deployment switches to NSIS at once - this would be nice (i.e., > >> IPv6), but > >> hard to believe (i.e., IPv6)... ;) > > > The assumption is NOT that NSIS is deployed at once in all domains > > (whatever > > domains means here). The assumption is that at least one side of the > > network > > is NSIS-aware. The case you have mentioned could be already seen as > > two domains (you and the operator ;-) > > ok. But then GIST NAT traversal is bogus anyway...!? If you have > deployed GIST, adding NAT/FW NSLP is not the issue. Having support for > GIST is a much harder deployment constraint. I wouldn't say that GIST NAT traversal is bogus anyway, but I there some constraints that need to be considered first. There is a draft on GIST NAT traversal which can be a good start. (see also my thoughts above on whether this type of NAT traversal is accepted within the WG. > > >> 2) I don't care about semantics if it does not work in reality. My > >> view is > >> that NAT/Firewall NSLP should avoid any type of probing, > otherwise we > >> are > >> not much better off than BEHAVE folks doing hole-punching or > praying for > >> hairpin-translation. > > > Well, semantics are usually derived from real life. > > Every derivation includes errors. If there would occur no errors in > the > derivation process I would assume that semantics must perfectly match > reality. This does not seem always the case. I argue that the > semantics > of LE-MRM look clean, but might not match "real life" as good as > possible. > > > However, there are > > cases where you need to obtain a public IP address even you do not > > know from where your later data traffic is coming, e.g., SIP > early media. > > Sure, most prominently all symmetric NAT issues are concerned with > that > problem. I don't see a reason why PC-MRM should not disallow DTInfo > object. Also, GIST MRI supports wildcarding in a similar way as DTInfo > supports it. > > > There is possibly not much probing. When you are NAT'ed, use the > > LE-MRM; if not use the PC-MRM. Still you could argue about the NI > > being unable to find out if it is NAT'ed our not. However, this > could be > > either a configuration or some other mechanisms. > > NAT is not a problem (-> STUN), firewalls are: What about being NAT'ed > _and_ firewall'ed? How do you detect the firewalls? I only know > non-deterministic approaches to do that. With NATFW enabled firewalls you are on the right side. All others will require heavy probing. > > >> Thus, an application (aka NI+) that wants to receive incoming > traffic > >> should not worry about the difficulties about this operation. > This means > >> that it should not need to probe anything. The decision whether > to use > >> PC-MRM or LE-MRM requires knowledge about the network structure: Is > >> there > >> a firewall in the administrative domain or not. Honestly, I > would not > >> miss > >> LE-MRM if we would drop it. > > > There is no knowledge about the network structure needed, i.e., > you do > > not care about topology and order of devices in the topology. You > need > > to know wether you are NAT'ed or not. This is indeed difficulty > in some > > environments but in many it is quite obvious. > > see above. > > >> In case we stay with LE-MRM in the spec (whether it will be used > >> might be > >> a different question), I think that we should design it with > maximum > >> deployment support in mind - in this sense I believe that we > should not > >> equip the semantical aspect with the highest priority, > >> > >> So let me pose the question the other way around: What is the use > >> case for > >> NAT-only operation (aka LE-MRM)? Aren't our networks already fitted > >> with a > >> multitude of both: NATs and firewalls?! Can we really be sure > that the > >> network does not change or that endpoints attach to new networks > at any > >> time? Those changes should be handled transparently... and LE- > MRM is not > >> able to do this for firewalls, but only for NATs... > > > Right, the LE-MRM is "only" used for NAT'ed hosts that do not > know the > > other > > side, i.e., the data sender. In this case, the PC-MRM cannot be > used. > > You mean: NAT'ed _and_ not firewall'ed. How would you use > wildcarding in > a NAT+firewall environment using PC-MRM. The same way it could be done > for NAT-only case with marginal effort and complexity (from both, > development and standardization perspective). No, I mean whatever combination of NAT'ed and firewalled (or not). There is a semantically difference between sender address wildcarded PC-MRM and the LE-MRM. Using a wildcarded PC-MRM will lead you nowhere when you are in a network with multiple inbound NATs. GIST cannot know to which point it should forward the signalling message and the forwarding is very likely to be stopped half-way without reaching the edge. With LE-MRM, GIST can always forward the signalling message to some edge-NAT. For inbound data flows is does not matter (only to some degree of course) which NAT you hit, since the data flow is anchored at the external IP address at the NAT. However, by choosing a good signalling destination address (SDA), you can get the better edge-NAT, e.g., the one topology-wise closest to the possible data sender. Martin _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Tue May 23 14:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fic55-0001gZ-Bd; Tue, 23 May 2006 14:58:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fic54-0001gU-3F for nsis@ietf.org; Tue, 23 May 2006 14:58:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fic52-0005I0-Lm for nsis@ietf.org; Tue, 23 May 2006 14:58:10 -0400 Received: (qmail invoked by alias); 23 May 2006 18:58:07 -0000 Received: from p54984D7B.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.77.123] by mail.gmx.net (mp031) with SMTP; 23 May 2006 20:58:07 +0200 X-Authenticated: #29516787 Message-ID: <44735B3E.9020406@gmx.net> Date: Tue, 23 May 2006 20:58:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?wrHDs8Kxw7PDjcO1?= Subject: Re: [NSIS] NSIS run on MIPL ? References: <5a26be460605230417o7784d27bo31fa42361c1f56a5@mail.gmail.com> In-Reply-To: <5a26be460605230417o7784d27bo31fa42361c1f56a5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Binbin, running NSIS in combination of MIPv6 is certainly possible. http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobility-signaling-04.txt talks about the problems and explains how gist/nslps work together with MIPv6. From layering point of view the MIPv6 stuff runs below NSIS. Hence, your figure is correct from this point of view. Is this your question? Ciao Hannes 斌斌王 wrote: > Hi All: > > I am a student of Beijing University of Posts and Telecommunications, > China. I have studied NSIS for several months. As is knowen to all that > NSIS is run on IP like the figure below. > > NSLP > ================================ > NTLP > ================================ > +--------------------------------------------------------------+ > IP v4/v6 > > For our lab have done some research on MIPL (Mobile IPv6 for Linux. > http://chasey.mobile-ipv6.org/software/). And now I want to combine > NSIS and MIPL ---- run NSIS on MIPL. > > NSLP > ================================ > NTLP > ================================ > +------------------------------------------------------------+ > MIPL > > I don't know whether this idea is rational and doable .I need some > suggestions. Thank you, everyone who read this mail. > > Bestwishes! > > Binbin Wang > 2006-5-23 > > > > > -- > *i*memo*ce* journey > > > ------------------------------------------------------------------------ > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Wed May 24 05:07:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FipL3-0006qN-JB; Wed, 24 May 2006 05:07:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FipL3-0006qI-5g for nsis@ietf.org; Wed, 24 May 2006 05:07:33 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FipL1-0003Vw-OC for nsis@ietf.org; Wed, 24 May 2006 05:07:33 -0400 Received: from [84.163.73.149] (helo=alanis.mafr.de) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1FipKt09nm-0000j7; Wed, 24 May 2006 11:07:23 +0200 Received: by alanis.mafr.de (Postfix, from userid 1000) id D44735E8653; Wed, 24 May 2006 11:07:02 +0200 (CEST) Date: Wed, 24 May 2006 11:07:02 +0200 From: Matthias Friedrich To: nsis@ietf.org Message-ID: <20060524090702.GA18262@mafr.de> Mail-Followup-To: nsis@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-Provags-ID: kundenserver.de abuse@kundenserver.de login:b369618fd1a3462119ba5a921f6f235b X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [NSIS] NATFW state machine draft X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi, I've got a few questions about version 02 of the NATFW state machine draft. * Section 7 ("State machines for the NAT/FW NF"), state IDLE: What's the tx_CREATE in the last action good for? * Section 7 ("State machines for the NAT/FW NF"), state NONEDGE_REA: Is there a rx_RESPONSE(SUCCESS, REA) condition missing? The response could be coming from an upstream NF and should be passed on. The state would stay NONEDGE_REA. * Section 7 ("State machines for the NAT/FW NF"), state EDGE_REA: The first condition looks like a copy and paste mistake. I think a tx_RESPONSE(SUCCESS, REA) should be sent and the state should stay EDGE_REA. An edge NF shouldn't send REAs any further. I also wonder where the tx_RESPONSE(ERROR, REA) in the second condition could be coming from. The node is on the edge of the network after all. * Section 8 ("State machine for the NAT/FW NR"), state SESSION: The tg_TEARDOWN looks unnecessary to me, the session should be terminated by a rx_CREATE && CREATE(Lifetime) > 0 condition. * What about changing all those rx_CREATE && CREATE(Lifetime) > 0 style conditions to a more concise syntax, maybe like rx_CREATE(lifetime > 0)? Or, maybe I should stop drawing with a pencil. Since CREATE and REA sessions are different things (as I learned recently), it would IMHO make sense to split the NF and NR state machines into CREATE and REA parts. That way they'll be easier to understand and look nicer on paper (I tested it), especially when more conditions will be added later. The NR would be split into NR and NR-REA (or NI+) parts. The NR would consist of IDLE and SESSION states, while the NR-REA would consist of IDLE, WAITRESP (formerly REA_WAITRESP), and REA. The NF would consist of IDLE, WAITRESP, and SESSION states, while NF-REA consists of IDLE, EDGE_REA, and NONEDGE_REA. Thanks, Matthias, who hopes he didn't overlook something :-) _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Fri May 26 05:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjYW5-00027e-Dq; Fri, 26 May 2006 05:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjYW3-00027Y-Mm for nsis@ietf.org; Fri, 26 May 2006 05:21:55 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjYVy-0000IH-7Y for nsis@ietf.org; Fri, 26 May 2006 05:21:55 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4Q9KYCT001803; Fri, 26 May 2006 10:20:38 +0100 Received: from [193.118.197.86] ([193.118.197.86]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 10:20:34 +0100 Message-ID: <4476C862.8010701@roke.co.uk> Date: Fri, 26 May 2006 10:20:34 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Nsis (E-mail)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 09:20:34.0520 (UTC) FILETIME=[A48B7580:01C680A5] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Georgios Karagiannis , Jukka MJ Manner Subject: [NSIS] QoS NSLP - MRM identification in PACKET_CLASSIFIER X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, In one reviewer's comments of the QoS NSLP, it was pointed out that the 'Message-Routing-Method' component of the PACKET_CLASSIFIER (the first two bytes) is redundant, since it will always be the same as the MRM at the GIST layer. This is currently logged as issue 93 in the QoS NSLP issue tracker: http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue93 I propose to remove this part of the PACKET_CLASSIFIER. Not only is it duplication of information already available over the GIST API, it also gives us some extra error cases to handle (e.g. where it doesn't match the GIST MRM). If we don't remove it, then we will need to work out what additional error codes are needed. Any opposition to this change? (Or agreement with it?) regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat May 27 05:51:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjvRB-0002Uz-8z; Sat, 27 May 2006 05:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjvRA-0002Uu-Rc for nsis@ietf.org; Sat, 27 May 2006 05:50:24 -0400 Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjvR9-0007dT-HC for nsis@ietf.org; Sat, 27 May 2006 05:50:24 -0400 Received: from sbz-31.cs.helsinki.fi (sbz-31.cs.helsinki.fi [128.214.9.99]) (TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Sat, 27 May 2006 12:50:20 +0300 id 00070141.447820DC.0000398C Date: Sat, 27 May 2006 12:50:20 +0300 (EEST) From: Jukka MJ Manner To: Andrew McDonald In-Reply-To: <4476C862.8010701@roke.co.uk> Message-ID: References: <4476C862.8010701@roke.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Georgios Karagiannis , "Nsis \(E-mail\)" Subject: [NSIS] Re: QoS NSLP - MRM identification in PACKET_CLASSIFIER X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Fine with me. Still, with the current path-coupled MRM of 2 bytes, we probably should add 2 bytes of padding (or reserved bits) to make the object a multiple of 32 bits, e.g., From +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message-Routing-Method | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + // Method-specific classifier data (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ to +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Method-specific classifier data (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|Y|P|T|F|S|A|B| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Jukka On Fri, 26 May 2006, Andrew McDonald wrote: > Hi all, > > In one reviewer's comments of the QoS NSLP, it was pointed out that the > 'Message-Routing-Method' component of the PACKET_CLASSIFIER (the first two > bytes) is redundant, since it will always be the same as the MRM at the GIST > layer. > > This is currently logged as issue 93 in the QoS NSLP issue tracker: > http://nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-qos-nslp-issues/issue93 > > I propose to remove this part of the PACKET_CLASSIFIER. Not only is it > duplication of information already available over the GIST API, it also gives > us some extra error cases to handle (e.g. where it doesn't match the GIST > MRM). If we don't remove it, then we will need to work out what additional > error codes are needed. > > Any opposition to this change? (Or agreement with it?) > > regards, > > Andrew > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sat May 27 10:13:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjzXo-000228-Qs; Sat, 27 May 2006 10:13:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjzXn-000223-Sn for nsis@ietf.org; Sat, 27 May 2006 10:13:31 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjzXi-00021v-CS for nsis@ietf.org; Sat, 27 May 2006 10:13:31 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k4RED9Gk011986; Sat, 27 May 2006 15:13:09 +0100 Received: from [193.118.197.86] ([193.118.197.86]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 May 2006 15:13:09 +0100 Message-ID: <44785E74.40800@roke.co.uk> Date: Sat, 27 May 2006 15:13:08 +0100 From: Andrew McDonald User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Ash, Gerald R \(Jerry\), ALABS" Subject: Re: [NSIS] QoS NSLP INFO_SPEC and error codes References: <9473683187ADC049A855ED2DA739ABCA0DDC774C@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <9473683187ADC049A855ED2DA739ABCA0DDC774C@KCCLUST06EVS1.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2006 14:13:09.0203 (UTC) FILETIME=[AE5D4230:01C68197] X-MailScanner-roke.co.uk: Found to be clean X-MailScanner-roke.co.uk-SpamCheck: X-MailScanner-From: andrew.mcdonald@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: attila.bader@ericsson.com, nsis@ietf.org, cornelia.kappler@siemens.com X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi Jerry, Some comments below. Ash, Gerald R (Jerry), ALABS wrote: > What is now specified in the QSPEC I-D (Section 4.5.1 in > http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt) is as > follows: > > "When an RMF cannot interpret the QSPEC because the coding is > erroneous, it raises corresponding flags in the QSPEC. The 'error > flags' are located in each QSPEC Object and in each parameter. If > such a flag is set, at least one QNE along the data transmission path > between the QNI and QNR cannot interpret a mandatory or optional > QSPEC parameter or the QSPEC object for any reason, such as a > protocol error, QNE fault, etc. In this case, more detailed error > information may be given in the QoS NSLP error message. That is, if > possible the RMF must communicate error details to the QoS NSLP > processing. QoS NSLP [QoS-SIG] describes how the erroneous message > is handled further. > > As stated in Section 5.1.3.6 (INFO_SPEC) of [QoS-SIG]: > "Values in the error subcode field are defined in each QOSM > specification separately. The default value for the subcode is 0x00. > A default value means that the QoS model does not want or does not > need to give more information about the error/result, anything else > in the subcode must be defined in the QoS model specification." > > That is, any additional error codes beyond those defined in [QoS-SIG] > MUST be defined in individual QOSM specifications." > > I suggest this be modified along the lines of your suggestion so that > QSPEC/RMF-specific codes are identified in the QSPEC I-D. That is, for > example, the 4-bit error class is defined in QoS-NSLP as follows: > > "0x06 - QSPEC/RMF-specific Error" > This error is set by QoS-NSLP if QSPEC/RMF sets an 8-bit > QSPEC/RMF-specific error subcode, specified below. Perhaps other > QSPEC/RMF-specific error codes can be defined in QoS-NSLP based on > QSPEC/RMF specific failure conditions. > > Within the 4-bit error class "0x06 - QSPEC/RMF-specific Error", the > "8-bit QSPEC/RMF-specific error subcodes" are defined and set by > QSPEC/RMF; for example: > > 0x02 - cannot be met > 0x03 - cannot be met > 0xab - cannot be met > 0xcd - cannot be met > 0xef - cannot be met > etc. > > These '8-bit QSPEC/RMF-specific error subcodes' pertain to QSPEC > parameters and are defined within the QSPEC I-D. Additional '8-bit > QSPEC/RMF-specific error subcodes' pertaining to QSPEC parameters > defined in QOSM-specific I-Ds (e.g., RMD-QOSM, Y1541-QOSM, etc.) should > also be defined in the QOSM-specific I-Ds. > > Does this sound OK? If not, please make a counter proposal. > >> Does the 'E' flag in the QSPEC parameters already provide the >> necessary QSpec information? (not clear if 'error' covers >> 'reservation could not be satisfied') > > As above, the 'E flag' would be set by QSPEC/RMF if some error condition > arises wrt a QSPEC parameter. The '8-bit QSPEC/RMF-specific error > subcode' is set by QSPEC/RMF to a specific value if additional > information on the error is to be conveyed to the QNI. That doesn't really fit with what I was trying to say, obviously my explanation was somewhat unclear. I'll try to clarify this. As a starting point, I don't think the proposal above fully holds together. For example, what happens if both Bandwidth *and* Latency can't be met? My main problem with the QSpec/RMF-related error handling is that I am still unclear what the requirements are. The two things that I can see at the moment are both about signalling errors about particular QSPEC parameters: - parameter can't be met (e.g. can't provide the requested bandwidth) - malformed parameter Are there any problems other than these two that need to be signalled? The next question is whether the 'E' flag indicate one or both of these? My recommendation would be to get rid of the "Error subcode" in the INFO_SPEC entirely. At the moment, it only seems to fulfil a role in the special case of the QSpec/RMF errors. If something is needed there then this could be done in other ways; for example, by providing "error-specific information" (in the space provided by the INFO_SPEC). I would suggest that the 'E' flag identifies parameters that failed to be met. The INFO_SPEC would simply say "Partial Success" (or "Total Failure") and the QSPEC would carry sufficient information (in the E flags) to identify where the problem was. Where there are malformed parameters, I would suggest that this is signalled back by a "Malformed object" error (an additional code that is a bit more generic than the "Bad length", etc currently available). This error would also carry error specific information in the form of the 'object value info' (p45 of qos-nslp draft -11). This means that the entire QSPEC would be returned with the error. This proposal for indicating malformed QSPEC contents does lack the ability to identify which parameter was malformed. If this is an issue we could probably address it, still with a design roughly along the same lines. best regards, Andrew _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Sun May 28 04:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkGZJ-00074X-PW; Sun, 28 May 2006 04:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkGZI-00074S-GX for nsis@ietf.org; Sun, 28 May 2006 04:24:12 -0400 Received: from m12-14.163.com ([220.181.12.14]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FkGZA-0000O3-Bg for nsis@ietf.org; Sun, 28 May 2006 04:24:12 -0400 Received: from bupt-0758506b88 (unknown [59.64.154.142]) by smtp11 (Coremail) with SMTP id wKjADipAzxwFXnlEVmFAHA==.49126S2; Sun, 28 May 2006 16:23:42 +0800 (CST) Date: Sun, 28 May 2006 16:27:01 +0800 From: "=?gb2312?B?wc7F5dXq?=" To: "nsis" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <44795E19.193083.18497> X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [NSIS] QoS NSLP software implement X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953316844==" Errors-To: nsis-bounces@ietf.org --===============0953316844== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KICAgICBJIGFtIGEgc3R1ZGVudCBvZiBCZWlqaW5nIFVuaXZlcnNpdHkgb2YgUG9z dCBhbmQgVGVsZWNvbW11bmljYXRpb24uSSBoYXZlIGZvbGxvd2VkIHRoZSB0ZWNobm9sb2d5IG9m IE5TSVMgZGlzY3Vzc2VkIGluIHRoaXMgbWFpbGxpc3QgZm9yIGEgbG9uZyB0aW1lLk5vdyB0aGVy ZSdzIHNvbWUgcHJvYmxlbXMgaW4gdGhlIHNvZnR3YXJlIHBsYXRmb3JtIG5hbWVkIE5TSVNfMC4z LjAuDQoxLldoZW4gd2UgdGV4dGVkIHRoZSBRb1MtTlNMUCB1c2luZyB0aGUgY29tbWFuZCAiIyBi aW4vcW9zX3NlcnZlciIgIiMgYmluL3Fvc19jbGllbnQiLGl0IGNhbid0IGVzdGFibGlzaCBhIHN1 Y2Nlc3NmdWwgY29ubmVjdGlvbi5XZSBjYW4ndCBnZXQgYW55IG1lc3NhZ2UgZnJvbSB0aGUgc2Ny ZWVuIGV4Y2VwdCBzb21lIGluZm9ybWF0aW9uIHBhcnNlZCB0aGUgY29tbWFuZCAuSXMgdGhlcmUg YW55b25lIHdobyBoYXZlIHRleHRlZCB0aGUgUU9TLU5TTFA/IE5vIHByb2JsZW0/IEkgd29uZGVy IGlmIHRoZXJlJ3MgYW55IG1pc3Rha2VzIGluIHRoZSBzb3VkZSBjb2RlPw0KMi5XaWxsIHRoZXJl IGJlIGFueSBpbXByb3ZlbWVudHMgaW4gdGhlIHNvZnR3YXJlICxhbmQgYSBuZXcgdmVyc2lvbiB0 aGF0IGltcGxlbWVudCBzb21lIFFvU01zPyANCg0KVGhhbmtzIHZlcnkgbXVjaCENCg0KDQpsaWFv cGVpemhlbkAxNjMuY29tDQqhoTIwMDYtMDUtMjgNCg== --===============0953316844== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis --===============0953316844==-- From nsis-bounces@ietf.org Mon May 29 04:05:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkck8-0001gl-QW; Mon, 29 May 2006 04:04:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkck7-0001cc-8E for nsis@ietf.org; Mon, 29 May 2006 04:04:51 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkck7-00078L-6e for nsis@ietf.org; Mon, 29 May 2006 04:04:51 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fkck5-00016u-9q for nsis@ietf.org; Mon, 29 May 2006 04:04:51 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k4T84cdY025824; Mon, 29 May 2006 10:04:38 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k4T84bp1003684; Mon, 29 May 2006 10:04:38 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 10:04:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Subject: AW: [NSIS] QoS NSLP software implement Date: Mon, 29 May 2006 10:04:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [NSIS] QoS NSLP software implement Thread-Index: AcaCMHRx03qeb9k/TfOWyLxYEYeAdQAxAZLg From: "Tschofenig, Hannes" To: =?gb2312?B?wc7F5dXq?= , "nsis" X-OriginalArrivalTime: 29 May 2006 08:04:37.0885 (UTC) FILETIME=[87D162D0:01C682F6] X-Spam-Score: -2.6 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi,=20 You might want to post your question to the NSIS-imp mailing list = (i.e., a list for implementation questions for NSIS protocols). You can = subscribe here:=20 https://www1.ietf.org/mailman/listinfo/nsis-imp A small hint: It might be good to know which implementation you are = using.=20 Ciao Hannes > -----Urspr=A8=B9ngliche Nachricht----- > Von: =C1=CE=C5=E5=D5=EA [mailto:liaopeizhen@163.com]=20 > Gesendet: Sonntag, 28. Mai 2006 10:27 > An: nsis > Betreff: [NSIS] QoS NSLP software implement >=20 > Hi all, > I am a student of Beijing University of Post and=20 > Telecommunication.I have followed the technology of NSIS=20 > discussed in this maillist for a long time.Now there's some=20 > problems in the software platform named NSIS_0.3.0. > 1.When we texted the QoS-NSLP using the command "#=20 > bin/qos_server" "# bin/qos_client",it can't establish a=20 > successful connection.We can't get any message from the=20 > screen except some information parsed the command .Is there=20 > anyone who have texted the QOS-NSLP? No problem? I wonder if=20 > there's any mistakes in the soude code? > 2.Will there be any improvements in the software ,and a new=20 > version that implement some QoSMs?=20 >=20 > Thanks very much! >=20 >=20 > liaopeizhen@163.com > =A1=A12006-05-28 >=20 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis From nsis-bounces@ietf.org Mon May 29 05:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkdgA-0006yW-Ap; Mon, 29 May 2006 05:04:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkdg8-0006yR-WE for nsis@ietf.org; Mon, 29 May 2006 05:04:49 -0400 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkdg4-0005qz-Jw for nsis@ietf.org; Mon, 29 May 2006 05:04:48 -0400 Received: from elena1 (unknown [10.0.12.115]) by mailing.unile.it (Postfix) with SMTP id 902C4104B36; Mon, 29 May 2006 11:04:34 +0200 (CEST) Message-ID: <008d01c682fe$ea423770$730c000a@elena1> From: "Elena Scialpi" To: "Hannes Tschofenig" , =?UTF-8?B?wrHDs8Kxw7PDjcO1?= References: <5a26be460605230417o7784d27bo31fa42361c1f56a5@mail.gmail.com> <44735B3E.9020406@gmx.net> Subject: Re: [NSIS] NSIS run on MIPL ? Date: Mon, 29 May 2006 11:04:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Antivirus: avast! (VPS 0621-4, 26/05/2006), Outbound message X-Antivirus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nsis-bounces@ietf.org Hi all, I have proposed a solution to resolve some problems of NSIS/MIP interacti= on=20 . You can read it at: http://www.ietf.org/internet-drafts/draft-tommasi-nsis-semipro-00.txt I'm very happy to answer your questions! Elena > Hi Binbin, > > running NSIS in combination of MIPv6 is certainly possible. > http://www.ietf.org/internet-drafts/draft-ietf-nsis-applicability-mobil= ity-signaling-04.txt > talks about the problems and explains how gist/nslps work together with= =20 > MIPv6. > > From layering point of view the MIPv6 stuff runs below NSIS. Hence, you= r=20 > figure is correct from this point of view. Is this your question? > > Ciao > Hannes > > > =E6=96=8C=E6=96=8C=E7=8E=8B wrote: >> Hi All: >> >> I am a student of Beijing University of Posts and Telecommunications,=20 >> China. I have studied NSIS for several months. As is knowen to all th= at=20 >> NSIS is run on IP like the figure below. >> >> NSLP >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> NTLP >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> +--------------------------------------------------------------+ >> IP v4/v6 For our lab have done som= e=20 >> research on MIPL (Mobile IPv6 for Linux.=20 >> http://chasey.mobile-ipv6.org/software/). And now I want to combine NS= IS=20 >> and MIPL ---- run NSIS on MIPL. >> >> NSLP >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> NTLP >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> +------------------------------------------------------------+ >> MIPL I don't know whether this idea= is=20 >> rational and doable .I need some suggestions. Thank you, everyone who=20 >> read this mail. >> Bestwishes! >> Binbin Wang >> 2006-5-23 >> --=20 >> *i*memo*ce* journey >> >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> nsis mailing list >> nsis@ietf.org >> https://www1.ietf.org/mailman/listinfo/nsis > > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > ------------=20 LIIS Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi http://liis.unile.it http://www.campusdelsalento.it Office: (+39) 0832-297310 c/o Palazzo di Ingegneria Via per Monteroni I-73100 Lecce LE, Italy _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis