From owner-nat@livingston.com Wed Dec 1 05:44:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08526 for ; Wed, 1 Dec 1999 05:44:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id CAA27432; Wed, 1 Dec 1999 02:39:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA05635 for nat-outgoing; Wed, 1 Dec 1999 02:39:16 -0800 (PST) Message-ID: <002101bf3be8$783e1810$4190d0d4@logicplus.fr> From: "Fred CLAVAUD" To: Subject: (NAT) How to do nat with an OR ST Date: Wed, 1 Dec 1999 11:40:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01BF3BF0.D9F64B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Fred CLAVAUD" This is a multi-part message in MIME format. ------=_NextPart_000_001E_01BF3BF0.D9F64B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i have an office router ISDN (OR ST) with ComOS 3.7.2Lc5 and a PM 3 with = ComOS 3.9b24 for the moment the NAT is done with the PM3 but i would like to do it = with the office router because i can't open a telnet or PMVision session = on the OR when I'am on the PM3 side. the packet may turn round when i = try to log on the OR. ComOS 3.7.2Lc5 can't translate the IP addresse. Where can i find a = version with can do it (NAT or Single User Account (SUA))). ------=_NextPart_000_001E_01BF3BF0.D9F64B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

i have an office router ISDN (OR ST) = with ComOS=20 3.7.2Lc5 and a PM 3 with ComOS 3.9b24

for the moment the NAT is done with the = PM3 but i=20 would like to do it with the office router because i can't open a telnet = or=20 PMVision session on the OR when I'am on the PM3 side. the packet may = turn round=20 when i try to log on the OR.

ComOS 3.7.2Lc5 can't translate the IP = addresse.=20 Where can i find a version with can do it (NAT or Single User Account=20 (SUA))).

------=_NextPart_000_001E_01BF3BF0.D9F64B10-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Dec 1 10:44:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03187 for ; Wed, 1 Dec 1999 10:44:04 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id HAA00165; Wed, 1 Dec 1999 07:39:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA12868 for nat-outgoing; Wed, 1 Dec 1999 07:40:23 -0800 (PST) Message-ID: <38453F6E.B05BF1EF@lucentradius.com> Date: Wed, 01 Dec 1999 07:31:58 -0800 From: Thomas C Kinnen Organization: Lucent INS X-Mailer: Mozilla 4.61 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Fred CLAVAUD CC: nat@livingston.com Subject: Re: (NAT) How to do nat with an OR ST References: <002101bf3be8$783e1810$4190d0d4@logicplus.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Thomas C Kinnen Content-Transfer-Encoding: 7bit > Fred CLAVAUD wrote: > > i have an office router ISDN (OR ST) with ComOS 3.7.2Lc5 and a PM 3 with > ComOS 3.9b24 This is the IETF NAT mail list. You should direct your question to portmaster-users@livingston.com -- Thomas C Kinnen - [RADIUS Engineer] - LUCENT Technologies INS "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 2 12:35:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15019 for ; Thu, 2 Dec 1999 12:35:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA26201; Thu, 2 Dec 1999 09:25:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA15289 for nat-outgoing; Thu, 2 Dec 1999 09:25:08 -0800 (PST) From: "Bernard Aboba" To: Subject: (NAT) RSIP and IKE rekey Date: Thu, 2 Dec 1999 09:25:49 -0800 Message-ID: <011801bf3cea$48c754e0$298939cc@internaut.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <86256839.0072061E.00@mwgate02.mw.3com.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit There are some issues that arise in the case of a responder rekey of an existing SA. In this case, the responder will send an IKE packet that may have a new initiator cookie. The RSIP gateway will be unable to determine who this should be forwarded to, since it does not have any state relating to that cookie. Some ideas on how to deal with this: 1. Try to set the RSIP lease time so that the client will initiate rekey rather than the responder. Not clear this can work because rekeys can be undertaken for reasons other than just expiration of the SA, and therefore the time at which this can occur is unpredictable. 2. Use the IPSEC non-port specific method. This would send *all* IKE traffic from a given destination to the registering client. This is somewhat ugly since it prohibits multiplexing of IKE to the same destination. Hope we don't have to go here. Any ideas? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 2 15:34:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13429 for ; Thu, 2 Dec 1999 15:34:35 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA01458; Thu, 2 Dec 1999 12:29:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA27754 for nat-outgoing; Thu, 2 Dec 1999 12:30:22 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Pyda Srisuresh cc: "Tang, Tom J" , nat@livingston.com Message-ID: <8625683B.00713E4D.00@mwgate02.mw.3com.com> Date: Thu, 2 Dec 1999 14:25:34 -0600 Subject: Re: (NAT) IP Protocol Value Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" Such a section has been in the draft, but it hasn't been modelled after 2434. Another checklist items for -05... -Mike Pyda Srisuresh on 11/30/99 03:06:21 PM Sent by: Pyda Srisuresh To: Mike Borella/MW/US/3Com, "Tang, Tom J" cc: nat@livingston.com Subject: Re: (NAT) IP Protocol Value Mike, you should have an "IANA considerations" section in the draft detailing the range of port requirements (TCP/UDP), so the IANA can assign the port(s) after the draft is reviwed by theIESG. Take a look at RFC 2434 for guidelines on how to formulate the "IANA considerations" section. cheers, suresh --- Mike Borella wrote: > > > Since RSIP is an application, it doesn't need such a value. > Perhaps you're thinking about a port number. We've been > using 4455 for testing, but from what I understand approval > for IANA for such numbers comes later in the process. > > -Mike > > > > > > "Tang, Tom J" on 11/29/99 04:42:58 PM > > Please respond to "Tang, Tom J" > > Sent by: "Tang, Tom J" > > > To: nat@livingston.com > cc: (Mike Borella/MW/US/3Com) > Subject: (NAT) IP Protocol Value > > > > > > Hello : > > There does not seem to be a IP protocol value defined for RSIP. Any > thoughts out there about whether or not such a value is necessary ? > Cheers... > > Tom J. Tang > Intel Corporation > Email : tom.j.tang@intel.com > Phone : (503) 712-1791 > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > ===== __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 2 17:56:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23019 for ; Thu, 2 Dec 1999 17:56:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id OAA04355; Thu, 2 Dec 1999 14:50:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA06549 for nat-outgoing; Thu, 2 Dec 1999 14:52:00 -0800 (PST) Message-ID: <51C0AF25889FD211AC3F00A0C984090D02D30B33@orsmsx50.jf.intel.com> From: "Saint-Hilaire, Ylian" To: "'Bernard Aboba'" , nat@livingston.com Subject: RE: (NAT) RSIP and IKE rekey Date: Thu, 2 Dec 1999 14:50:13 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Saint-Hilaire, Ylian" We figured the same problems and are working gathering information on this. Within the current scope of RSIP, I don't believe we should hold the documents back because of this. It is clear that multiplexing multiple IPsec traffic to a single destination will cause problems. Ylian Saint-Hilaire INTEL - Communication Architecture Labs -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, December 02, 1999 9:26 AM To: nat@livingston.com Subject: (NAT) RSIP and IKE rekey There are some issues that arise in the case of a responder rekey of an existing SA. In this case, the responder will send an IKE packet that may have a new initiator cookie. The RSIP gateway will be unable to determine who this should be forwarded to, since it does not have any state relating to that cookie. Some ideas on how to deal with this: 1. Try to set the RSIP lease time so that the client will initiate rekey rather than the responder. Not clear this can work because rekeys can be undertaken for reasons other than just expiration of the SA, and therefore the time at which this can occur is unpredictable. 2. Use the IPSEC non-port specific method. This would send *all* IKE traffic from a given destination to the registering client. This is somewhat ugly since it prohibits multiplexing of IKE to the same destination. Hope we don't have to go here. Any ideas? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 2 18:54:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22196 for ; Thu, 2 Dec 1999 18:54:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id PAA05588; Thu, 2 Dec 1999 15:47:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA09953 for nat-outgoing; Thu, 2 Dec 1999 15:49:51 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: "Saint-Hilaire, Ylian" cc: "'Bernard Aboba'" , nat@livingston.com Message-ID: <8625683B.00832F38.00@mwgate02.mw.3com.com> Date: Thu, 2 Dec 1999 17:41:35 -0600 Subject: RE: (NAT) RSIP and IKE rekey Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" I think these issues are slightly different. Bernard has brought up the case of an external host rekeying by choosing a new isakmp SA, which the RSIP gateway doesn't know what to do with. This may be alleviated if IKE is not fixed at source port 500, and therefore we don't have to muck with cookies. On the other hand, Ylian is referring to the case in which an external host talking to multiple RSIP clients doesn't know which isakmp SA to use because it is basing the identity of its peer on the shared IP address. Here, IMO, the external implementation is not making the right assumption. Hope I'm not putting words in anyone's mouth. The important thing is to document exactly how and why these issues come up and what can be done about them. We need reach consensus on that soon. -Mike "Saint-Hilaire, Ylian" on 12/02/99 04:50:13 PM Please respond to "Saint-Hilaire, Ylian" Sent by: "Saint-Hilaire, Ylian" To: "'Bernard Aboba'" , nat@livingston.com cc: (Mike Borella/MW/US/3Com) Subject: RE: (NAT) RSIP and IKE rekey We figured the same problems and are working gathering information on this. Within the current scope of RSIP, I don't believe we should hold the documents back because of this. It is clear that multiplexing multiple IPsec traffic to a single destination will cause problems. Ylian Saint-Hilaire INTEL - Communication Architecture Labs -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, December 02, 1999 9:26 AM To: nat@livingston.com Subject: (NAT) RSIP and IKE rekey There are some issues that arise in the case of a responder rekey of an existing SA. In this case, the responder will send an IKE packet that may have a new initiator cookie. The RSIP gateway will be unable to determine who this should be forwarded to, since it does not have any state relating to that cookie. Some ideas on how to deal with this: 1. Try to set the RSIP lease time so that the client will initiate rekey rather than the responder. Not clear this can work because rekeys can be undertaken for reasons other than just expiration of the SA, and therefore the time at which this can occur is unpredictable. 2. Use the IPSEC non-port specific method. This would send *all* IKE traffic from a given destination to the registering client. This is somewhat ugly since it prohibits multiplexing of IKE to the same destination. Hope we don't have to go here. Any ideas? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 2 20:52:40 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17466 for ; Thu, 2 Dec 1999 20:52:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id RAA07810; Thu, 2 Dec 1999 17:47:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA16702 for nat-outgoing; Thu, 2 Dec 1999 17:49:34 -0800 (PST) Date: Thu, 2 Dec 1999 17:49:14 -0800 (PST) From: Gabriel Montenegro Subject: RE: (NAT) RSIP and IKE rekey To: Mike Borella Cc: "Saint-Hilaire, Ylian" , "'Bernard Aboba'" , nat@livingston.com In-Reply-To: "Your message with ID" <8625683B.00832F38.00@mwgate02.mw.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Gabriel Montenegro > Bernard has brought up the case of an external host rekeying > by choosing a new isakmp SA, which the RSIP gateway doesn't > know what to do with. This may be alleviated if IKE is not fixed > at source port 500, and therefore we don't have to muck with cookies. that would do it. the re-keying draft draft-jenkins-ipsec-rekeying-02.txt talks about a "continuous model" which would help when re-keying phase 2 sa's. but you're right, re-keying a phase 1 sa is problematic. it is the same problem as accepting incoming phase 1 sa's, which we already know we have a problem with (except when we can use a port other than 500 to accept those incoming connections). > On the other hand, Ylian is referring to the case in which an external > host talking to multiple RSIP clients doesn't know which isakmp SA > to use because it is basing the identity of its peer on the shared > IP address. Here, IMO, the external implementation is not making the > right assumption. agreed, i thought this was already put to rest by this message (which did not make it to nat@livingston.com, so i'm sending it here): >----- Begin Included Message -----< Date: Mon, 15 Nov 1999 18:24:44 -0800 From: "Scott G. Kelly" Subject: (NAT) Re: IKE negotiation/rekeying problem with RSIP To: "Saint-Hilaire, Ylian" Cc: "'Mike Borella'" , ipsec@lists.tislabs.com, "'gab@sun.com'" , nat@livingston.com, "David Grabelsky" "Saint-Hilaire, Ylian" wrote: > > Even if we get out of using pre-shared keys and start using certs, there is > no requirement in the IKE standard to choose one phase 1 over another. For > example, IKE standards don't require that a re-key of a phase 2 MUST be done > over the same phase 1 as the original SA. Even if we use certs, I would > guess that no IKE implementations will currently look at the cert of a phase > 1 before selecting it for a phase 2. > > Ylian Saint-Hilaire Actually, I think this may be incorrect. Ostensibly, the 2 users behind the rsip server would use separate authenticators (not the same preshared key or cert). If this is true, then the phase 2 SAs are bound to the respective phase 1 SAs by the authentication materials used in each case. If the kernel (or whatever you want to call the ipsec portion of the stack) requests a phase 2 negotiation from IKE, it must provide IKE with identifying information (and authentication requirements) with which IKE can determine whether an existing phase 1 SA is appropriate. If the IKE implementation does not verify that the phase 1 SA meets the authentication requirements before using it, I think the IKE implementation is badly broken. Scott - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. >----- End Included Message -----< - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Dec 3 03:38:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19681 for ; Fri, 3 Dec 1999 03:38:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id XAA12166; Thu, 2 Dec 1999 23:28:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA26981 for nat-outgoing; Thu, 2 Dec 1999 23:20:19 -0800 (PST) From: "Bernard Aboba" To: "'Gabriel Montenegro'" , "'Mike Borella'" Cc: "'Saint-Hilaire, Ylian'" , Subject: RE: (NAT) RSIP and IKE rekey Date: Thu, 2 Dec 1999 23:14:37 -0800 Message-ID: <012f01bf3d5e$0fdc9e00$298939cc@internaut.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit > This may be alleviated if IKE is not fixed > at source port 500, and therefore we don't have to muck with cookies. Yup. Who wants to raise this issue on the IPSEC list? (I suggest donning an asbestos suit). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Dec 3 03:45:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23038 for ; Fri, 3 Dec 1999 03:45:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id AAA13112; Fri, 3 Dec 1999 00:31:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA29250 for nat-outgoing; Fri, 3 Dec 1999 00:31:22 -0800 (PST) Message-ID: <38477F33.2670AEBA@slab.ntt.co.jp> Date: Fri, 03 Dec 1999 17:28:35 +0900 From: Paul Francis Organization: NTT Software Labs X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: nat@livingston.com Subject: Re: (NAT) RSIP and IKE rekey References: <012f01bf3d5e$0fdc9e00$298939cc@internaut.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Paul Francis Content-Transfer-Encoding: 7bit > > Yup. Who wants to raise this issue on the IPSEC list? (I suggest > donning an asbestos suit). > - I don't think you'll need an asbestos suit, just a good firewall :-) PF - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Dec 3 06:54:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26772 for ; Fri, 3 Dec 1999 06:54:09 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id DAA14832; Fri, 3 Dec 1999 03:48:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA03983 for nat-outgoing; Fri, 3 Dec 1999 03:48:50 -0800 (PST) Message-ID: <3847ADE6.5993C74C@redcreek.com> Date: Fri, 03 Dec 1999 03:47:50 -0800 From: "Scott G. Kelly" X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba CC: "'Gabriel Montenegro'" , "'Mike Borella'" , "'Saint-Hilaire, Ylian'" , nat@livingston.com Subject: Re: (NAT) RSIP and IKE rekey References: <012f01bf3d5e$0fdc9e00$298939cc@internaut.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Scott G. Kelly" Content-Transfer-Encoding: 7bit Hi Bernard, Bernard Aboba wrote: > > > This may be alleviated if IKE is not fixed > > at source port 500, and therefore we don't have to muck with cookies. > > Yup. Who wants to raise this issue on the IPSEC list? (I suggest > donning an asbestos suit). I'm sort of peripherally following this conversation, so forgive me if I say something which proves I don't fully understand the issues. I *think* what I'm hearing is that if the remote ipsec peer tries to rekey an existing IKE SA, the nat gw won't know who to send the traffic to since the cookie is unrecognized. IKE is already permitted on ports other than 500 - support for 500 is required of compliant implementations, but there is no reason why a different port can't be used. The (interoperability) trick would be in the remote implementation's configurability in this regard. Alternatively, remote peers could "remember" what port the rsip-enabled peer initiated from, and rekey on that port, but I'm not sure how many implementations work this way now. Our next release will... I don't think these ideas are controversial, though the mention of "continuous model" in this vein is likely to get people's attention. As you know, there's not much agreement on that at this point. However, since this model simply entails always keeping a phase 1 SA up (as opposed to deferring rekeying under some circumstances), I don't think it's particularly relevant. The real problem here is with who initiates the rekey, and this problem remains whether the rekey is deferred or not - the problem seems to be with who initiates the rekey. As an interim workaround, the rsip-enabled end could be configured with a shorter phase 1 lifetime than the remote peer, which should insure that the rekey is initiated from the rsip end. Just a thought. Scott - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Dec 3 08:44:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25098 for ; Fri, 3 Dec 1999 08:44:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id FAA15651; Fri, 3 Dec 1999 05:38:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA06467 for nat-outgoing; Fri, 3 Dec 1999 05:39:34 -0800 (PST) From: "Bernard Aboba" To: "'Mike Borella'" , "'Saint-Hilaire, Ylian'" Cc: Subject: RE: (NAT) RSIP and IKE rekey Date: Fri, 3 Dec 1999 05:39:38 -0800 Message-ID: <013301bf3d93$d8c5ed00$298939cc@internaut.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8625683B.00832F38.00@mwgate02.mw.3com.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit >This may be alleviated if IKE is not fixed >at source port 500, and therefore we don't have to muck with cookies. Are you suggesting that we move toward a conventional port allocation approach for IKE? For those implementations that can float the source port, this would be desirable. However, for those that cannot, this would result in only a single client being able to use IPSEC at a time. In contrast, if you also support cookies, at worst your restriction will be that only a single client will be able to open an IKE SA to a given destination at a time. Therefore I think that we will need to continue to support cookie-based demultiplexing even if we also provide a source port alternative. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Dec 6 14:03:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05021 for ; Mon, 6 Dec 1999 14:03:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id KAA28081; Mon, 6 Dec 1999 10:48:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA05396 for nat-outgoing; Mon, 6 Dec 1999 10:46:18 -0800 (PST) Message-ID: <19991206184308.29872.qmail@web1402.mail.yahoo.com> Date: Mon, 6 Dec 1999 10:43:08 -0800 (PST) From: Pyda Srisuresh Subject: RE: (NAT) RSIP and IKE rekey To: Mike Borella , "Saint-Hilaire, Ylian" Cc: "'Bernard Aboba'" , nat@livingston.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Pyda Srisuresh --- Mike Borella wrote: > > > I think these issues are slightly different. I agree. > > Bernard has brought up the case of an external host rekeying > by choosing a new isakmp SA, which the RSIP gateway doesn't > know what to do with. This may be alleviated if IKE is not fixed > at source port 500, and therefore we don't have to muck with cookies. > Yes. Rekeying phase-I SA can be tricky. The "Continuous phase-I model" that is being discussed in IPsec in the context of remote access users might help the RSIP case as well. I believe, the rekeying discussion in the context of RSIP parallels the same rekeying discussion going on in the IPsec mailing list (or IPSRA mailing list) vis-a-vis Secure-remote-access. More on this below. Independent of the outcome of "continuous model", one way to get around this issue would be for the RSIP client to take ownership of rekeying. I think, using a port other than 500 is bound to run into interoperability issues and as such may not be a good idea to go down that path. > On the other hand, Ylian is referring to the case in which an external > host talking to multiple RSIP clients doesn't know which isakmp SA > to use because it is basing the identity of its peer on the shared > IP address. Here, IMO, the external implementation is not making the > right assumption. > This is a valid concern as well - Being able to securely contact an RSIP client from external realm. But, this wont work with RSIP (i.e., RSA-IP or RSAP-IP), generally speaking. This can work with RSA-IP only if a static mapping exists between private adress(of RSA-IP client) and external address on the RSA-IP server. The reason inbound IKE does not work with RSIP is principally because of an inherent problem with IKE. Today, multiple users on a single multi-user system (like a SUN UNIX system or a Remote Access Server) can establish IKE session with an external node. But, the external node cannot selectively contact the individual user on the multi-user system to setup an IKE session. Please note the analogy between RSIP server and multi-user system. IKE works best when the responder node has a uniquely identifiable address and no two responder nodes share the same address. When an external node initiates an IKE session to a user on multi-user system, there is no way for the responder node (as opposed to the responder user) to determine who to direct the message to. Both rekeying and inbound session initiation are tied to the same inherent problem. Even in the aggressive mode, the first IKE message contains the ID of the initiator, but does not contain the ID of the responder the initiator is trying to contact. > Hope I'm not putting words in anyone's mouth. > > The important thing is to document exactly how and why these issues > come up and what can be done about them. We need reach consensus > on that soon. > I agree, the limitation is worth noting in the framework/protocol documents. > -Mike > > cheers, suresh > > > > "Saint-Hilaire, Ylian" on 12/02/99 04:50:13 > PM > > Please respond to "Saint-Hilaire, Ylian" > > Sent by: "Saint-Hilaire, Ylian" > > > To: "'Bernard Aboba'" , nat@livingston.com > cc: (Mike Borella/MW/US/3Com) > Subject: RE: (NAT) RSIP and IKE rekey > > > > > > We figured the same problems and are working gathering information on this. > Within the current scope of RSIP, I don't believe we should hold the > documents back because of this. It is clear that multiplexing multiple IPsec > traffic to a single destination will cause problems. > > Ylian Saint-Hilaire > INTEL - Communication Architecture Labs > > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, December 02, 1999 9:26 AM > To: nat@livingston.com > Subject: (NAT) RSIP and IKE rekey > > > There are some issues that arise in the case of a responder > rekey of an existing SA. > > In this case, the responder will send an IKE packet that > may have a new initiator cookie. The RSIP gateway will > be unable to determine who this should be forwarded to, > since it does not have any state relating to that > cookie. > > Some ideas on how to deal with this: > > 1. Try to set the RSIP lease time so that the client > will initiate rekey rather than the responder. Not > clear this can work because rekeys can be undertaken > for reasons other than just expiration of the SA, > and therefore the time at which this can occur is > unpredictable. > > 2. Use the IPSEC non-port specific method. This would > send *all* IKE traffic from a given destination to the > registering client. This is somewhat ugly since it > prohibits multiplexing of IKE to the same destination. > Hope we don't have to go here. > > Any ideas? > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > __________________________________________________ Do You Yahoo!? Thousands of Stores. Millions of Products. All in one place. Yahoo! Shopping: http://shopping.yahoo.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Dec 7 08:57:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23999 for ; Tue, 7 Dec 1999 08:57:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id FAA13643; Tue, 7 Dec 1999 05:47:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA00413 for nat-outgoing; Tue, 7 Dec 1999 05:46:23 -0800 (PST) From: "Bernard Aboba" To: "'Mike Borella'" , "'Saint-Hilaire, Ylian'" Cc: Subject: RE: (NAT) RSIP and IKE rekey Date: Tue, 7 Dec 1999 05:48:47 -0800 Message-ID: <005501bf40b9$c9b6efc0$298939cc@internaut.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <8625683B.00832F38.00@mwgate02.mw.3com.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit >On the other hand, Ylian is referring to the case in which an external >host talking to multiple RSIP clients doesn't know which isakmp SA >to use because it is basing the identity of its peer on the shared >IP address. Here, IMO, the external implementation is not making the >right assumption. I think that the solution to this one is for the IKE initiator to negotiate *very* specific filters for the IPSEC SA so that the destination will not be confused. For example, if the RSIP client were to dynamically plumb a filter corresponding to the RSIP port/address that it was allocated, this would guarantee uniqueness. Example filter: From: To: destination address Source Port: Dest Port: destination port - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Dec 8 18:15:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22333 for ; Wed, 8 Dec 1999 18:15:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id PAA16273; Wed, 8 Dec 1999 15:09:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA00362 for nat-outgoing; Wed, 8 Dec 1999 15:08:44 -0800 (PST) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Date: Wed, 8 Dec 1999 15:08:40 -0800 (PST) From: Thomas Kinnen X-Sender: tkinnen@server To: nat@livingston.com Subject: (NAT) Mailing List nat@livingston.com fixed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Thomas Kinnen The mail lists were off line for a brief period of time last night after a sendmail upgrade. They should be working fine again at this time. If you still encounter problems or have questions please contact majordomo-owner@livingston.com Thanks, Tom -- Thomas C Kinnen - [RADIUS Engineer] - LUCENT Technologies INS "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 9 09:46:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22278 for ; Thu, 9 Dec 1999 09:46:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA28863; Thu, 9 Dec 1999 06:40:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA05866 for nat-outgoing; Thu, 9 Dec 1999 06:41:28 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: aboba@internaut.com cc: "'Saint-Hilaire, Ylian'" , nat@livingston.com Message-ID: <86256842.00510026.00@mwgate02.mw.3com.com> Date: Thu, 9 Dec 1999 08:33:27 -0600 Subject: RE: (NAT) RSIP and IKE rekey Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" Yes, I'm suggesting that IKE act like a "normal" protocol. :-) I still don't understand why the fixation with port 500, and it seems like it is a point of confusion. If there is no benefit to forcing source and dest to use 500, then why bother? And yes, we'll still have to support the cookie mechanism for implementations that need it. -Mike "Bernard Aboba" on 12/03/99 07:39:38 AM Please respond to aboba@internaut.com Sent by: "Bernard Aboba" To: Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'" cc: nat@livingston.com Subject: RE: (NAT) RSIP and IKE rekey >This may be alleviated if IKE is not fixed >at source port 500, and therefore we don't have to muck with cookies. Are you suggesting that we move toward a conventional port allocation approach for IKE? For those implementations that can float the source port, this would be desirable. However, for those that cannot, this would result in only a single client being able to use IPSEC at a time. In contrast, if you also support cookies, at worst your restriction will be that only a single client will be able to open an IKE SA to a given destination at a time. Therefore I think that we will need to continue to support cookie-based demultiplexing even if we also provide a source port alternative. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 9 09:50:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24041 for ; Thu, 9 Dec 1999 09:50:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA28978; Thu, 9 Dec 1999 06:42:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA06004 for nat-outgoing; Thu, 9 Dec 1999 06:44:58 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: aboba@internaut.com cc: "'Saint-Hilaire, Ylian'" , nat@livingston.com Message-ID: <86256842.00515565.00@mwgate02.mw.3com.com> Date: Thu, 9 Dec 1999 08:37:06 -0600 Subject: RE: (NAT) RSIP and IKE rekey Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" Yes, this is what I've had in mind the whole time, though I may have never made it explicit - since RSIP shares IP addresses, IPSEC SAs MUST have address/port filters. Furthermore, endpoint authentication MUST use something other than source IP. -Mike "Bernard Aboba" on 12/07/99 07:48:47 AM Please respond to aboba@internaut.com Sent by: "Bernard Aboba" To: Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'" cc: nat@livingston.com Subject: RE: (NAT) RSIP and IKE rekey >On the other hand, Ylian is referring to the case in which an external >host talking to multiple RSIP clients doesn't know which isakmp SA >to use because it is basing the identity of its peer on the shared >IP address. Here, IMO, the external implementation is not making the >right assumption. I think that the solution to this one is for the IKE initiator to negotiate *very* specific filters for the IPSEC SA so that the destination will not be confused. For example, if the RSIP client were to dynamically plumb a filter corresponding to the RSIP port/address that it was allocated, this would guarantee uniqueness. Example filter: From: To: destination address Source Port: Dest Port: destination port - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 9 15:42:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29862 for ; Thu, 9 Dec 1999 15:42:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA08990; Thu, 9 Dec 1999 12:36:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA25967 for nat-outgoing; Thu, 9 Dec 1999 12:36:45 -0800 (PST) X-Spoof-Warning: ccrl.sj.nec.com [131.241.79.5] does not match with monet.ccrl.sj.nec.com [131.241.79.5] Date: Thu, 9 Dec 1999 12:31:23 -0800 (PST) From: Jeffrey Lo To: Mike Borella cc: nat@livingston.com Subject: (NAT) RSIP Optional Messages In-Reply-To: <86256842.00515565.00@mwgate02.mw.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jeffrey Lo Hi, Pertaining to protocol draft -04. We came across the question of what minimal set of message type to implement and could still claim RSIP protocol conformance. For this reason, I propose stating explicitly in the draft what message types to be optional vs compulsory. Example of modifications to Appendix B of draft-ietf-nat-rsip-protocol-04.txt is as follow: Sent by Sent by Type RSIP client RSIP server 1 ERROR_RESPONSE X Compulsory 2 REGISTER_REQUEST X Compulsory 3 REGISTER_RESPONSE X Compulsory 4 DE-REGISTER_REQUEST X Compulsory 5 DE-REGISTER_RESPONSE X Compulsory 6 ASSIGN_REQUEST_RSA-IP X see 1 7 ASSIGN_RESPONSE_RSA-IP X see 1 8 ASSIGN_REQUEST_RSAP-IP X see 1 9 ASSIGN_RESPONSE_RSAP-IP X see 1 10 EXTEND_REQUEST X option 11 EXTEND_RESPONSE X option 12 FREE_REQUEST X option 13 FREE_RESPONSE X option 14 QUERY_REQUEST X option 15 QUERY_RESPONSE X option 16 DEALLOCATE X option 17 OK X compulsory 18 LISTEN_REQUEST X option 19 LISTEN_RESPOSNE X option Note : 1. We propose making ASSIGN family of messages optional with the condition that at least either RSA-IP or RSAP-IP has to be implemented. 2. Under this, it will be possible to introduce the asychronous subnet update message that was proposed some time back as an option. (Point of further study and discussion) 3. Some error fields may have to be introduced accordingly. ---- Jeffrey Lo C&C Research Labs, NEC USA, Inc. Tel : (408) 943 3033 Fax : (408) 943 3099 On Thu, 9 Dec 1999, Mike Borella wrote: > > > Yes, this is what I've had in mind the whole time, though I may have > never made it explicit - since RSIP shares IP addresses, IPSEC SAs > MUST have address/port filters. > > Furthermore, endpoint authentication MUST use something other than > source IP. > > -Mike > > > > > > "Bernard Aboba" on 12/07/99 07:48:47 AM > > Please respond to aboba@internaut.com > > Sent by: "Bernard Aboba" > > > To: Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'" > > cc: nat@livingston.com > Subject: RE: (NAT) RSIP and IKE rekey > > > > > >On the other hand, Ylian is referring to the case in which an external > >host talking to multiple RSIP clients doesn't know which isakmp SA > >to use because it is basing the identity of its peer on the shared > >IP address. Here, IMO, the external implementation is not making the > >right assumption. > > I think that the solution to this one is for the IKE initiator to > negotiate *very* specific filters for the IPSEC SA so that the > destination will not be confused. For example, if the RSIP > client were to dynamically plumb a filter corresponding > to the RSIP port/address that it was allocated, this would guarantee > uniqueness. > > Example filter: > From: To: destination address > Source Port: Dest Port: destination port > > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 9 21:27:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17922 for ; Thu, 9 Dec 1999 21:27:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id SAA16768; Thu, 9 Dec 1999 18:22:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id SAA15428 for nat-outgoing; Thu, 9 Dec 1999 18:22:31 -0800 (PST) X-Spoof-Warning: ccrl.sj.nec.com [131.241.79.5] does not match with monet.ccrl.sj.nec.com [131.241.79.5] Date: Thu, 9 Dec 1999 18:13:46 -0800 (PST) From: Jeffrey Lo To: rsvp@isi.edu cc: nat@livingston.com Subject: (NAT) RSIP QoS interaction Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jeffrey Lo Hi, In an attempt to write up a section for the RSIP framework draft on RSIP interaction with Intserv QoS signalling model using RSVP, I would like to hear more about your opinion on how the RSVP model would fit into the RSIP scenario. In particular, we are interested in the more general case of having a unicast receiver on the private network contacting a sender on the internet, as follows : Tunnel Internet Receiver ============= RSIP gateway ------------- Sender There are a number of scenarios to consider and it seems that some of the ideas mentioned in draft-ietf-rsvp-tunnel-04.txt are relevant. Any thoughts of how RSIP implementation on the RSIP gateway would complicate RSVP or vice versa? What's the status of draft-ietf-rsvp-tunnel-04.txt? ---- Jeffrey Lo C&C Research Labs, NEC USA, Inc. Tel : (408) 943 3033 Fax : (408) 943 3099 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Dec 10 11:53:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27288 for ; Fri, 10 Dec 1999 11:53:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA28447; Fri, 10 Dec 1999 08:48:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA09307 for nat-outgoing; Fri, 10 Dec 1999 08:50:21 -0800 (PST) Message-ID: <4148FEAAD879D311AC5700A0C969E8901CBBCC@orsmsx35.jf.intel.com> From: "Iyer, Prakash" To: nat@livingston.com Subject: (NAT) Hosting RSIP interoperability workshop Date: Fri, 10 Dec 1999 08:48:50 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Iyer, Prakash" On behalf of Intel, I'd like to explore the possibility of hosting the first RSIP interoperability bakeoff. The focus would be on consumer (home, small to medium business) networks. The time frame I had in mind was middle to end of March 2000 and the location will be Hillsboro, Oregon. NIC, client OS and small business interconnect device (routers, gateways etc.) vendors are welcome to participate. It would be an excellent opportunity to get early hands-on experience dealing with interoperabilityissues. I'd like to get some feedback from vendors on: - Overall focus for the bakeoff. - Their interest and willingness to participate in the bakeoff. - If the timeline is agreeable (too early, too late etc.) - What applications / protocols would they be interested in testing with RSIP - e.g. IPSec, H.323 IP Telephony etc. If there is interest, we can work out a more detailed agenda. Regards. Prakash Iyer Intel Corp.; Intel Architecture Labs prakash.iyer@intel.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Dec 13 14:32:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17069 for ; Mon, 13 Dec 1999 14:32:52 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id LAA29257; Mon, 13 Dec 1999 11:27:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA20982 for nat-outgoing; Mon, 13 Dec 1999 11:28:06 -0800 (PST) Date: Mon, 13 Dec 1999 11:22:05 -0800 (PST) From: Jeffrey Lo To: Andreas Terzis cc: rsvp@isi.edu, nat@livingston.com Subject: (NAT) Re: RSIP QoS interaction In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jeffrey Lo Andreas, I have attached the "Architecture" section of the RSIP framework doc. For more information, kindly refer to the draft . There are a few cases to consider. 1. RSVP unaware cloud within private realm and on RSIP server. I think this case is the simplest and will work. 2. RSVP aware cloud within private realm and on RSIP server. This case requires usage of technologies mentioned in the RSVP tunnel draft, be it type1, type 2 or type3 tunnels between the RSIP client and RSIP server. However, as soon as a RSVP daemon is run on the RSIP server, I think it raises the following possible complications: a. The RSVP daemon on RSIP server may not see the RSVP messages. In the case of RSA-IP, the RSIP module may encapsulate the RSVP path messages coming from the public side within a private IP header before handling over to IP layer. Hence, the packet will get routed using the encapsulated header and not be de-multiplex to RSVP daemon. b. Even if the RSVP daemon gets the messages, the destination address within the session object is actually addressed to one of the RSIP router's interface (Conceptually, RSIP essentially enables the RSIP client a temporal presence on the RSIP server), RSVP signalling may just terminates there. Jeffrey Lo ------------------------------------------------------------------------- In a typical scenario where RSIP is deployed, there are some number of hosts within one addressing realm connected to another addressing realm by the RSIP server. This model is diagrammatically represented as follows: RSIP Client RSIP Server Host Xa Na Nb Yb [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y] ( Network ) ( Network ) Hosts X and Y belong to different addressing realms A and B, respectively, and N is an RSIP server (which may also act as a NAT router). N has two interfaces: Na on address space A, and Nb on address space B. N may have a pool of addresses in address space B which it can assign to or lend to X and other hosts in address space A. These addresses are not shown above, but they can be denoted as Nb1, Nb2, Nb3 and so on. As is often the case, the hosts within address space A are likely to use private addresses while the RSIP server is multi-homed with one or more private addresses from address space A in addition to it's public addresses from address space B. Host X wishing to establish an end-to-end connection to a network entity Y situated within address space B first negotiates and obtains assignment of the resources (e.g. addresses and other routing parameters of address space B) from the RSIP server. Upon assignment of these parameters, the RSIP server creates a mapping, known as a bind, of X's addressing information and the assigned resources. This binding enables the RSIP server to correctly de-multiplex and forward inbound traffic generated by Y for X. If permitted by the RSIP server, X may create multiple such bindings on the same RSIP server. A lease time SHOULD be associated with each bind. Using the public parameters assigned by the RSIP server, RSIP clients route (usually tunnel) data packets to the RSIP server within address space A. If tunneling is used, the RSIP server acts as the end point of such tunnels, stripping off the outer headers and routing the inner packets onto the public realm. As mentioned above, an RSIP server maintains a mapping of the assigned public parameters as demultiplexing tuples for uniquely mapping them to RSIP client private addresses. When a packet from the public realm arrives at the RSIP server and it matches a given set of demultiplexing tuples, then the RSIP server will tunnel it to the appropriate RSIP client. A disadvantage of RSIP is that it requires modification of RSIP clients to enable RSIP client-server negotiation, usage of the assigned resources and in the case when tunneling is used, to tunnel the data packets to the RSIP server. On Thu, 9 Dec 1999, Andreas Terzis wrote: > > On Thu, 9 Dec 1999, Jeffrey Lo wrote: > > > > > Hi, > > > > In an attempt to write up a section for the RSIP framework draft > > on RSIP interaction with Intserv > > QoS signalling model using RSVP, I would like to hear more about your > > opinion on how the RSVP model would fit into the RSIP scenario. In > > particular, we are interested in the more general case of having a > > unicast receiver on the private network contacting a sender on the > > internet, as follows : > > > > Tunnel Internet > > Receiver ============= RSIP gateway ------------- Sender > > > > There are a number of scenarios to consider and it seems that some of the > > ideas mentioned in draft-ietf-rsvp-tunnel-04.txt are relevant. Any > > thoughts of how RSIP implementation on the RSIP gateway would complicate > > RSVP or vice versa? > > > > What's the status of draft-ietf-rsvp-tunnel-04.txt? > > Well, I can at least answer this question :-) > > draft-ietf-rsvp-tunnel-04.txt is waiting in the RFC Editor's queue to > become a draft standard. > > Unfortunately I cannot help you with the other questions, since I don't > have a clue about RSIP. If you could explain a little bit... > > regards, > > -andreas > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Andreas A. Terzis, | UCLA Computer Science Department > terzis@cs.ucla.edu | Internet Research Lab > http://irl.cs.ucla.edu/~terzis | > PGP Signature available at http://www.cs.ucla.edu/~terzis/pub_key.asc > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Dec 13 17:05:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19818 for ; Mon, 13 Dec 1999 17:05:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id OAA02751; Mon, 13 Dec 1999 14:01:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id OAA01738 for nat-outgoing; Mon, 13 Dec 1999 14:02:51 -0800 (PST) Message-ID: <3855690C.94939FC2@hursley.ibm.com> Date: Mon, 13 Dec 1999 15:45:48 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Jeffrey Lo CC: Andreas Terzis , rsvp@isi.edu, nat@livingston.com Subject: Re: (NAT) Re: RSIP QoS interaction References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Brian E Carpenter Content-Transfer-Encoding: 7bit BTW, RSIP also has to interact with the diffserv QOS model. This just seems to be a special case of "diffserv and tunnels" which is a current diffserv WG item. Brian Jeffrey Lo wrote: > > Andreas, > > I have attached the "Architecture" section of the RSIP framework doc. For > more information, kindly refer to the draft > . There are a few cases to consider. > > 1. RSVP unaware cloud within private realm and on RSIP server. > I think this case is the simplest and will work. > > 2. RSVP aware cloud within private realm and on RSIP server. > This case requires usage of technologies mentioned in the RSVP tunnel > draft, be it type1, type 2 or type3 tunnels between the RSIP client and > RSIP server. However, as soon as a RSVP daemon is run on the RSIP server, > I think it raises the following possible complications: > > a. The RSVP daemon on RSIP server may not see the RSVP messages. In the > case of RSA-IP, the RSIP module may encapsulate the RSVP path messages > coming from the public side within a private IP header before handling > over to IP layer. Hence, the packet will get routed using the encapsulated > header and not be de-multiplex to RSVP daemon. > > b. Even if the RSVP daemon gets the messages, the destination address > within the session object is actually addressed to one of the RSIP > router's interface (Conceptually, RSIP essentially enables the RSIP client > a temporal presence on the RSIP server), RSVP signalling may just > terminates there. > > Jeffrey Lo > > ------------------------------------------------------------------------- > > In a typical scenario where RSIP is deployed, there are some number > of hosts within one addressing realm connected to another addressing > realm by the RSIP server. This model is diagrammatically represented > as follows: > > RSIP Client RSIP Server Host > Xa Na Nb Yb > [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y] > ( Network ) ( Network ) > > Hosts X and Y belong to different addressing realms A and B, > respectively, and N is an RSIP server (which may also act as a NAT > router). N has two interfaces: Na on address space A, and Nb on > address space B. N may have a pool of addresses in address space B > which it can assign to or lend to X and other hosts in address space > A. These addresses are not shown above, but they can be denoted as > Nb1, Nb2, Nb3 and so on. As is often the case, the hosts within > address space A are likely to use private addresses while the RSIP > server is multi-homed with one or more private addresses from address > space A in addition to it's public addresses from address space B. > Host X wishing to establish an end-to-end connection to a network > entity Y situated within address space B first negotiates and obtains > assignment of the resources (e.g. addresses and other routing > parameters of address space B) from the RSIP server. Upon assignment > of these parameters, the RSIP server creates a mapping, known as a > bind, of X's addressing information and the assigned resources. This > binding enables the RSIP server to correctly de-multiplex and forward > inbound traffic generated by Y for X. If permitted by the RSIP > server, X may create multiple such bindings on the same RSIP server. > A lease time SHOULD be associated with each bind. > Using the public parameters assigned by the RSIP server, RSIP clients > route (usually tunnel) data packets to the RSIP server within address > space A. If tunneling is used, the RSIP server acts as the end point > of such tunnels, stripping off the outer headers and routing the > inner packets onto the public realm. As mentioned above, an RSIP > server maintains a mapping of the assigned public parameters as > demultiplexing tuples for uniquely mapping them to RSIP client > private addresses. When a packet from the public realm arrives at > the RSIP server and it matches a given set of demultiplexing tuples, > then the RSIP server will tunnel it to the appropriate RSIP client. > A disadvantage of RSIP is that it requires modification of RSIP > clients to enable RSIP client-server negotiation, usage of the > assigned resources and in the case when tunneling is used, to tunnel > the data packets to the RSIP server. > > On Thu, 9 Dec 1999, Andreas Terzis wrote: > > > > > On Thu, 9 Dec 1999, Jeffrey Lo wrote: > > > > > > > > Hi, > > > > > > In an attempt to write up a section for the RSIP framework draft > > > on RSIP interaction with Intserv > > > QoS signalling model using RSVP, I would like to hear more about your > > > opinion on how the RSVP model would fit into the RSIP scenario. In > > > particular, we are interested in the more general case of having a > > > unicast receiver on the private network contacting a sender on the > > > internet, as follows : > > > > > > Tunnel Internet > > > Receiver ============= RSIP gateway ------------- Sender > > > > > > There are a number of scenarios to consider and it seems that some of the > > > ideas mentioned in draft-ietf-rsvp-tunnel-04.txt are relevant. Any > > > thoughts of how RSIP implementation on the RSIP gateway would complicate > > > RSVP or vice versa? > > > > > > What's the status of draft-ietf-rsvp-tunnel-04.txt? > > > > Well, I can at least answer this question :-) > > > > draft-ietf-rsvp-tunnel-04.txt is waiting in the RFC Editor's queue to > > become a draft standard. > > > > Unfortunately I cannot help you with the other questions, since I don't > > have a clue about RSIP. If you could explain a little bit... > > > > regards, > > > > -andreas > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Andreas A. Terzis, | UCLA Computer Science Department > > terzis@cs.ucla.edu | Internet Research Lab > > http://irl.cs.ucla.edu/~terzis | > > PGP Signature available at http://www.cs.ucla.edu/~terzis/pub_key.asc > > > > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Dec 14 01:27:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28670 for ; Tue, 14 Dec 1999 01:27:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id WAA12405; Mon, 13 Dec 1999 22:23:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id WAA24255 for nat-outgoing; Mon, 13 Dec 1999 22:25:09 -0800 (PST) Date: Mon, 13 Dec 1999 22:20:09 -0800 (PST) From: Jeffrey Lo To: Brian E Carpenter cc: rsvp@isi.edu, nat@livingston.com Subject: Re: (NAT) Re: RSIP QoS interaction In-Reply-To: <3855690C.94939FC2@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jeffrey Lo Brian, There will be a section in the framework draft discussing this. Thanks ---- Jeffrey Lo C&C Research Labs, NEC USA, Inc. Tel : (408) 943 3033 Fax : (408) 943 3099 On Mon, 13 Dec 1999, Brian E Carpenter wrote: > BTW, RSIP also has to interact with the diffserv QOS model. This just seems > to be a special case of "diffserv and tunnels" which is a current diffserv > WG item. > > Brian > > Jeffrey Lo wrote: > > > > Andreas, > > > > I have attached the "Architecture" section of the RSIP framework doc. For > > more information, kindly refer to the draft > > . There are a few cases to consider. > > > > 1. RSVP unaware cloud within private realm and on RSIP server. > > I think this case is the simplest and will work. > > > > 2. RSVP aware cloud within private realm and on RSIP server. > > This case requires usage of technologies mentioned in the RSVP tunnel > > draft, be it type1, type 2 or type3 tunnels between the RSIP client and > > RSIP server. However, as soon as a RSVP daemon is run on the RSIP server, > > I think it raises the following possible complications: > > > > a. The RSVP daemon on RSIP server may not see the RSVP messages. In the > > case of RSA-IP, the RSIP module may encapsulate the RSVP path messages > > coming from the public side within a private IP header before handling > > over to IP layer. Hence, the packet will get routed using the encapsulated > > header and not be de-multiplex to RSVP daemon. > > > > b. Even if the RSVP daemon gets the messages, the destination address > > within the session object is actually addressed to one of the RSIP > > router's interface (Conceptually, RSIP essentially enables the RSIP client > > a temporal presence on the RSIP server), RSVP signalling may just > > terminates there. > > > > Jeffrey Lo > > > > ------------------------------------------------------------------------- > > > > In a typical scenario where RSIP is deployed, there are some number > > of hosts within one addressing realm connected to another addressing > > realm by the RSIP server. This model is diagrammatically represented > > as follows: > > > > RSIP Client RSIP Server Host > > Xa Na Nb Yb > > [X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y] > > ( Network ) ( Network ) > > > > Hosts X and Y belong to different addressing realms A and B, > > respectively, and N is an RSIP server (which may also act as a NAT > > router). N has two interfaces: Na on address space A, and Nb on > > address space B. N may have a pool of addresses in address space B > > which it can assign to or lend to X and other hosts in address space > > A. These addresses are not shown above, but they can be denoted as > > Nb1, Nb2, Nb3 and so on. As is often the case, the hosts within > > address space A are likely to use private addresses while the RSIP > > server is multi-homed with one or more private addresses from address > > space A in addition to it's public addresses from address space B. > > Host X wishing to establish an end-to-end connection to a network > > entity Y situated within address space B first negotiates and obtains > > assignment of the resources (e.g. addresses and other routing > > parameters of address space B) from the RSIP server. Upon assignment > > of these parameters, the RSIP server creates a mapping, known as a > > bind, of X's addressing information and the assigned resources. This > > binding enables the RSIP server to correctly de-multiplex and forward > > inbound traffic generated by Y for X. If permitted by the RSIP > > server, X may create multiple such bindings on the same RSIP server. > > A lease time SHOULD be associated with each bind. > > Using the public parameters assigned by the RSIP server, RSIP clients > > route (usually tunnel) data packets to the RSIP server within address > > space A. If tunneling is used, the RSIP server acts as the end point > > of such tunnels, stripping off the outer headers and routing the > > inner packets onto the public realm. As mentioned above, an RSIP > > server maintains a mapping of the assigned public parameters as > > demultiplexing tuples for uniquely mapping them to RSIP client > > private addresses. When a packet from the public realm arrives at > > the RSIP server and it matches a given set of demultiplexing tuples, > > then the RSIP server will tunnel it to the appropriate RSIP client. > > A disadvantage of RSIP is that it requires modification of RSIP > > clients to enable RSIP client-server negotiation, usage of the > > assigned resources and in the case when tunneling is used, to tunnel > > the data packets to the RSIP server. > > > > On Thu, 9 Dec 1999, Andreas Terzis wrote: > > > > > > > > On Thu, 9 Dec 1999, Jeffrey Lo wrote: > > > > > > > > > > > Hi, > > > > > > > > In an attempt to write up a section for the RSIP framework draft > > > > on RSIP interaction with Intserv > > > > QoS signalling model using RSVP, I would like to hear more about your > > > > opinion on how the RSVP model would fit into the RSIP scenario. In > > > > particular, we are interested in the more general case of having a > > > > unicast receiver on the private network contacting a sender on the > > > > internet, as follows : > > > > > > > > Tunnel Internet > > > > Receiver ============= RSIP gateway ------------- Sender > > > > > > > > There are a number of scenarios to consider and it seems that some of the > > > > ideas mentioned in draft-ietf-rsvp-tunnel-04.txt are relevant. Any > > > > thoughts of how RSIP implementation on the RSIP gateway would complicate > > > > RSVP or vice versa? > > > > > > > > What's the status of draft-ietf-rsvp-tunnel-04.txt? > > > > > > Well, I can at least answer this question :-) > > > > > > draft-ietf-rsvp-tunnel-04.txt is waiting in the RFC Editor's queue to > > > become a draft standard. > > > > > > Unfortunately I cannot help you with the other questions, since I don't > > > have a clue about RSIP. If you could explain a little bit... > > > > > > regards, > > > > > > -andreas > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Andreas A. Terzis, | UCLA Computer Science Department > > > terzis@cs.ucla.edu | Internet Research Lab > > > http://irl.cs.ucla.edu/~terzis | > > > PGP Signature available at http://www.cs.ucla.edu/~terzis/pub_key.asc > > > > > > > > > > > > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Dec 15 15:21:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28797 for ; Wed, 15 Dec 1999 15:21:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA17706; Wed, 15 Dec 1999 12:16:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA29544 for nat-outgoing; Wed, 15 Dec 1999 12:15:00 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Jeffrey Lo cc: nat@livingston.com Message-ID: <86256848.006FDBE3.00@mwgate02.mw.3com.com> Date: Wed, 15 Dec 1999 14:10:30 -0600 Subject: Re: (NAT) RSIP Optional Messages Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" I've had a chance to step back from the protocol draft for a while and look at it with a fresh perspective. As a result of re-examining some sections and some off-line feedback that I've received, I'd like to propose the following changes. - With respect to the types of messages (mandorty or option): - EXTEND_REQUEST and EXTEND RESPONSE: mandatory since some RSIP server may use short lease times to manage resources. - ASSIGN_REQUEST_RSAP-IP and ASSIGN_RESPONSE_RSAP_IP: mandatory default for interop. The RSA-IP mode should be optional because it is much less likely to be used. - FREE_REUEST and FREE_RESPONSE: mandatory (see below) - QUERY_REQUEST: optional - QUERY_RESPONSE: mandatory - FREE_REQUEST and FREE_RESPONSE should be able to indicate more than one binding. - Likewise, the DEREGISTER_RESPONSE should be used as an asynchronous message to deregister a client (deleteion of all binds implied). - DEALLOCATE is exactly the same as FREE_RESPONSE right now. It should be removed from the spec and FREE_RESPONSE used in its place as an asynchronous method for deallocating one or more bindings. - OK message is not necessary and should be removed. - A disposition byte should be added in the ADDRESS and PORT parameters to indicate the client's willingness to either (1) only be allocated the specific parameter values that it indicates or (2) accept other values that the server may assigned, but that it prefers the values suggested. All in all, these changes would make the expected behavior of both clients and servers more clear, which would make interpretation and use of error messages simpler. Thoughts? -Mike Jeffrey Lo on 12/09/99 02:31:23 PM Please respond to Jeffrey Lo Sent by: Jeffrey Lo To: Mike Borella/MW/US/3Com cc: nat@livingston.com Subject: (NAT) RSIP Optional Messages Hi, Pertaining to protocol draft -04. We came across the question of what minimal set of message type to implement and could still claim RSIP protocol conformance. For this reason, I propose stating explicitly in the draft what message types to be optional vs compulsory. Example of modifications to Appendix B of draft-ietf-nat-rsip-protocol-04.txt is as follow: Sent by Sent by Type RSIP client RSIP server 1 ERROR_RESPONSE X Compulsory 2 REGISTER_REQUEST X Compulsory 3 REGISTER_RESPONSE X Compulsory 4 DE-REGISTER_REQUEST X Compulsory 5 DE-REGISTER_RESPONSE X Compulsory 6 ASSIGN_REQUEST_RSA-IP X see 1 7 ASSIGN_RESPONSE_RSA-IP X see 1 8 ASSIGN_REQUEST_RSAP-IP X see 1 9 ASSIGN_RESPONSE_RSAP-IP X see 1 10 EXTEND_REQUEST X option 11 EXTEND_RESPONSE X option 12 FREE_REQUEST X option 13 FREE_RESPONSE X option 14 QUERY_REQUEST X option 15 QUERY_RESPONSE X option 16 DEALLOCATE X option 17 OK X compulsory 18 LISTEN_REQUEST X option 19 LISTEN_RESPOSNE X option Note : 1. We propose making ASSIGN family of messages optional with the condition that at least either RSA-IP or RSAP-IP has to be implemented. 2. Under this, it will be possible to introduce the asychronous subnet update message that was proposed some time back as an option. (Point of further study and discussion) 3. Some error fields may have to be introduced accordingly. ---- Jeffrey Lo C&C Research Labs, NEC USA, Inc. Tel : (408) 943 3033 Fax : (408) 943 3099 On Thu, 9 Dec 1999, Mike Borella wrote: > > > Yes, this is what I've had in mind the whole time, though I may have > never made it explicit - since RSIP shares IP addresses, IPSEC SAs > MUST have address/port filters. > > Furthermore, endpoint authentication MUST use something other than > source IP. > > -Mike > > > > > > "Bernard Aboba" on 12/07/99 07:48:47 AM > > Please respond to aboba@internaut.com > > Sent by: "Bernard Aboba" > > > To: Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'" > > cc: nat@livingston.com > Subject: RE: (NAT) RSIP and IKE rekey > > > > > >On the other hand, Ylian is referring to the case in which an external > >host talking to multiple RSIP clients doesn't know which isakmp SA > >to use because it is basing the identity of its peer on the shared > >IP address. Here, IMO, the external implementation is not making the > >right assumption. > > I think that the solution to this one is for the IKE initiator to > negotiate *very* specific filters for the IPSEC SA so that the > destination will not be confused. For example, if the RSIP > client were to dynamically plumb a filter corresponding > to the RSIP port/address that it was allocated, this would guarantee > uniqueness. > > Example filter: > From: To: destination address > Source Port: Dest Port: destination port > > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 16 00:28:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25640 for ; Thu, 16 Dec 1999 00:28:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA26789; Wed, 15 Dec 1999 21:23:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA27217 for nat-outgoing; Wed, 15 Dec 1999 21:23:43 -0800 (PST) Message-Id: <01BF47B3.BBCF3420@irun.future.futsoft.com> From: Ramasamy To: "'nat@livingston.com'" Subject: (NAT) doubt in checksum calculation algo of NAT. Date: Thu, 16 Dec 1999 10:53:00 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.livingston.com id VAA27213 Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Ramasamy Content-Transfer-Encoding: 8bit Hi I have a doubt in checksum caluclation module of NAT. Actually, the checksum calculation algo. given in draft-ietf-nat-traditional-01.txt will work only if the optr( pointer to the old data ) is at an even offset from the start of the header. suppose if optr starts from the odd offset, can we change optr to optr-1, so that it will point to the byte which is immediately before the actual start of the old data and now the optr points to an even offset from the start of the header. after this modification ,can we apply the same algo. will there be any problem? or do we have to compute the checksum byte by byte in the usual way, if the conditions given in the draft are not satisfied?. please clarify my doubts. bye rams. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 16 15:41:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09484 for ; Thu, 16 Dec 1999 15:41:04 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA09672; Thu, 16 Dec 1999 12:36:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA02839 for nat-outgoing; Thu, 16 Dec 1999 12:36:30 -0800 (PST) Date: Thu, 16 Dec 1999 12:28:47 -0800 (PST) From: Jeffrey Lo To: Mike Borella cc: nat@livingston.com Subject: Re: (NAT) RSIP Optional Messages In-Reply-To: <86256848.006FDBE3.00@mwgate02.mw.3com.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Jeffrey Lo See my comments attached. Jeffrey Lo > I've had a chance to step back from the protocol draft for a while and look > at it with a fresh perspective. As a result of re-examining some sections and > some off-line feedback that I've received, I'd like to propose the following > changes. > > - With respect to the types of messages (mandorty or option): > - EXTEND_REQUEST and EXTEND RESPONSE: mandatory since > some RSIP server may use short lease times to manage resources. > - ASSIGN_REQUEST_RSAP-IP and ASSIGN_RESPONSE_RSAP_IP: > mandatory default for interop. The RSA-IP mode should be optional > because it is much less likely to be used. > - FREE_REUEST and FREE_RESPONSE: mandatory (see below) > - QUERY_REQUEST: optional > - QUERY_RESPONSE: mandatory An error message has to be introduce to handle the case when no subnet information has been configured on the server. In anycase, having a generic METHOD_NOT_SUPPORTED error message will be essential for rejecting optional messages not supported. > - FREE_REQUEST and FREE_RESPONSE should be able to indicate > more than one binding. Is there any significant performance improvement introducing this? I don't see any one client having more than a couple of binds. If all binds need to be release in on short, the client can just deregister. On the other hand, it complicates the protocol a great deal. What's the response of the server if one of the binds is invalid? Does it ignore the request or free all valid binds and keep the invalid on intact? Client may receive multiple replies in response to a free request. Error messages may have to support multiple binds too. > - Likewise, the DEREGISTER_RESPONSE should be used as an asynchronous > message to deregister a client (deleteion of all binds implied). Good point. > - DEALLOCATE is exactly the same as FREE_RESPONSE right now. It > should be removed from the spec and FREE_RESPONSE used in > its place as an asynchronous method for deallocating one or more bindings. > - OK message is not necessary and should be removed. > - A disposition byte should be added in the ADDRESS and PORT parameters > to indicate the client's willingness to either (1) only be allocated the > specific parameter values that it indicates or (2) accept other values that > the server may assigned, but that it prefers the values suggested. > > All in all, these changes would make the expected behavior of both clients and > servers more clear, which would make interpretation and use of error messages > simpler. > > Thoughts? > > -Mike > > > > > > Jeffrey Lo on 12/09/99 02:31:23 PM > > Please respond to Jeffrey Lo > > Sent by: Jeffrey Lo > > > To: Mike Borella/MW/US/3Com > cc: nat@livingston.com > Subject: (NAT) RSIP Optional Messages > > > > > > Hi, > > Pertaining to protocol draft -04. We came across the question of what > minimal set of message type to implement and could still claim RSIP > protocol conformance. For this reason, I propose stating explicitly in > the draft what message types to be optional vs compulsory. Example of > modifications to Appendix B of draft-ietf-nat-rsip-protocol-04.txt is as > follow: > > Sent by Sent by Type > RSIP client RSIP server > 1 ERROR_RESPONSE X Compulsory > 2 REGISTER_REQUEST X Compulsory > 3 REGISTER_RESPONSE X Compulsory > 4 DE-REGISTER_REQUEST X Compulsory > 5 DE-REGISTER_RESPONSE X Compulsory > 6 ASSIGN_REQUEST_RSA-IP X see 1 > 7 ASSIGN_RESPONSE_RSA-IP X see 1 > 8 ASSIGN_REQUEST_RSAP-IP X see 1 > 9 ASSIGN_RESPONSE_RSAP-IP X see 1 > 10 EXTEND_REQUEST X option > 11 EXTEND_RESPONSE X option > 12 FREE_REQUEST X option > 13 FREE_RESPONSE X option > 14 QUERY_REQUEST X option > 15 QUERY_RESPONSE X option > 16 DEALLOCATE X option > 17 OK X compulsory > 18 LISTEN_REQUEST X option > 19 LISTEN_RESPOSNE X option > > Note : > 1. We propose making ASSIGN family of messages optional with the condition > that at least either RSA-IP or RSAP-IP has to be implemented. > 2. Under this, it will be possible to introduce the asychronous subnet > update message that was proposed some time back as an option. (Point of > further study and discussion) > 3. Some error fields may have to be introduced accordingly. > > > > ---- > > Jeffrey Lo > C&C Research Labs, > NEC USA, Inc. > Tel : (408) 943 3033 > Fax : (408) 943 3099 > > On Thu, 9 Dec 1999, Mike Borella wrote: > > > > > > > Yes, this is what I've had in mind the whole time, though I may have > > never made it explicit - since RSIP shares IP addresses, IPSEC SAs > > MUST have address/port filters. > > > > Furthermore, endpoint authentication MUST use something other than > > source IP. > > > > -Mike > > > > > > > > > > > > "Bernard Aboba" on 12/07/99 07:48:47 AM > > > > Please respond to aboba@internaut.com > > > > Sent by: "Bernard Aboba" > > > > > > To: Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'" > > > > cc: nat@livingston.com > > Subject: RE: (NAT) RSIP and IKE rekey > > > > > > > > > > >On the other hand, Ylian is referring to the case in which an external > > >host talking to multiple RSIP clients doesn't know which isakmp SA > > >to use because it is basing the identity of its peer on the shared > > >IP address. Here, IMO, the external implementation is not making the > > >right assumption. > > > > I think that the solution to this one is for the IKE initiator to > > negotiate *very* specific filters for the IPSEC SA so that the > > destination will not be confused. For example, if the RSIP > > client were to dynamically plumb a filter corresponding > > to the RSIP port/address that it was allocated, this would guarantee > > uniqueness. > > > > Example filter: > > From: To: destination address > > Source Port: Dest Port: destination port > > > > > > > > > > > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe nat' in the body of the message. > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Dec 17 11:03:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07160 for ; Fri, 17 Dec 1999 11:03:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id HAA27782; Fri, 17 Dec 1999 07:56:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA15452 for nat-outgoing; Fri, 17 Dec 1999 07:58:15 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Mike Borella" To: Jeffrey Lo cc: nat@livingston.com Message-ID: <8625684A.00584B35.00@mwgate02.mw.3com.com> Date: Fri, 17 Dec 1999 09:53:03 -0600 Subject: Re: (NAT) RSIP Optional Messages Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Mike Borella" I'll address you comments in the order in which they appear. - Agreed about the error message. I'm in the processing of refining the error conditions for the -05 draft. - If a client says something like "free binds 1, 2, 3" but 2 is not valid, then the server can safely ignore the request to free 2, but it can free 1 and 3 and indicate that it did so. An error message isn't really necessary, and if the client is confused, it can send a "free bind 2" to which the server will send an error message. However, I do see your point about the number of binds being small in some cases. On the other hand, if strict flow policy is used, then there is a separate bind per socket (addr/port, addr/port 4-tuple) and for multiple-session protocols there may be say, 3-4 binds per, in addition to whatever else the client is doing. In these cases, it is important that when the client closes the socket, it frees each bind. So, if these actions are atomic, I can see each bind being freed separately. Occam's Razor of Protocol Design suggests that we keep it the way it is, then. :-) -Mike PS: The goal of all this is to clarify which error messages should be sent in response to what conditions. I'm trying to make all conditions have a well-defined error behavior because if there is anything that it open to interpretation, n people will interpret it in n different ways. Jeffrey Lo on 12/16/99 02:28:47 PM Sent by: Jeffrey Lo To: Mike Borella/MW/US/3Com cc: nat@livingston.com Subject: Re: (NAT) RSIP Optional Messages See my comments attached. Jeffrey Lo > I've had a chance to step back from the protocol draft for a while and look > at it with a fresh perspective. As a result of re-examining some sections and > some off-line feedback that I've received, I'd like to propose the following > changes. > > - With respect to the types of messages (mandorty or option): > - EXTEND_REQUEST and EXTEND RESPONSE: mandatory since > some RSIP server may use short lease times to manage resources. > - ASSIGN_REQUEST_RSAP-IP and ASSIGN_RESPONSE_RSAP_IP: > mandatory default for interop. The RSA-IP mode should be optional > because it is much less likely to be used. > - FREE_REUEST and FREE_RESPONSE: mandatory (see below) > - QUERY_REQUEST: optional > - QUERY_RESPONSE: mandatory An error message has to be introduce to handle the case when no subnet information has been configured on the server. In anycase, having a generic METHOD_NOT_SUPPORTED error message will be essential for rejecting optional messages not supported. > - FREE_REQUEST and FREE_RESPONSE should be able to indicate > more than one binding. Is there any significant performance improvement introducing this? I don't see any one client having more than a couple of binds. If all binds need to be release in on short, the client can just deregister. On the other hand, it complicates the protocol a great deal. What's the response of the server if one of the binds is invalid? Does it ignore the request or free all valid binds and keep the invalid on intact? Client may receive multiple replies in response to a free request. Error messages may have to support multiple binds too. > - Likewise, the DEREGISTER_RESPONSE should be used as an asynchronous > message to deregister a client (deleteion of all binds implied). Good point. > - DEALLOCATE is exactly the same as FREE_RESPONSE right now. It > should be removed from the spec and FREE_RESPONSE used in > its place as an asynchronous method for deallocating one or more bindings. > - OK message is not necessary and should be removed. > - A disposition byte should be added in the ADDRESS and PORT parameters > to indicate the client's willingness to either (1) only be allocated the > specific parameter values that it indicates or (2) accept other values that > the server may assigned, but that it prefers the values suggested. > > All in all, these changes would make the expected behavior of both clients and > servers more clear, which would make interpretation and use of error messages > simpler. > > Thoughts? > > -Mike > > > > > > Jeffrey Lo on 12/09/99 02:31:23 PM > > Please respond to Jeffrey Lo > > Sent by: Jeffrey Lo > > > To: Mike Borella/MW/US/3Com > cc: nat@livingston.com > Subject: (NAT) RSIP Optional Messages > > > > > > Hi, > > Pertaining to protocol draft -04. We came across the question of what > minimal set of message type to implement and could still claim RSIP > protocol conformance. For this reason, I propose stating explicitly in > the draft what message types to be optional vs compulsory. Example of > modifications to Appendix B of draft-ietf-nat-rsip-protocol-04.txt is as > follow: > > Sent by Sent by Type > RSIP client RSIP server > 1 ERROR_RESPONSE X Compulsory > 2 REGISTER_REQUEST X Compulsory > 3 REGISTER_RESPONSE X Compulsory > 4 DE-REGISTER_REQUEST X Compulsory > 5 DE-REGISTER_RESPONSE X Compulsory > 6 ASSIGN_REQUEST_RSA-IP X see 1 > 7 ASSIGN_RESPONSE_RSA-IP X see 1 > 8 ASSIGN_REQUEST_RSAP-IP X see 1 > 9 ASSIGN_RESPONSE_RSAP-IP X see 1 > 10 EXTEND_REQUEST X option > 11 EXTEND_RESPONSE X option > 12 FREE_REQUEST X option > 13 FREE_RESPONSE X option > 14 QUERY_REQUEST X option > 15 QUERY_RESPONSE X option > 16 DEALLOCATE X option > 17 OK X compulsory > 18 LISTEN_REQUEST X option > 19 LISTEN_RESPOSNE X option > > Note : > 1. We propose making ASSIGN family of messages optional with the condition > that at least either RSA-IP or RSAP-IP has to be implemented. > 2. Under this, it will be possible to introduce the asychronous subnet > update message that was proposed some time back as an option. (Point of > further study and discussion) > 3. Some error fields may have to be introduced accordingly. > > > > ---- > > Jeffrey Lo > C&C Research Labs, > NEC USA, Inc. > Tel : (408) 943 3033 > Fax : (408) 943 3099 > > On Thu, 9 Dec 1999, Mike Borella wrote: > > > > > > > Yes, this is what I've had in mind the whole time, though I may have > > never made it explicit - since RSIP shares IP addresses, IPSEC SAs > > MUST have address/port filters. > > > > Furthermore, endpoint authentication MUST use something other than > > source IP. > > > > -Mike > > > > > > > > > > > > "Bernard Aboba" on 12/07/99 07:48:47 AM > > > > Please respond to aboba@internaut.com > > > > Sent by: "Bernard Aboba" > > > > > > To: Mike Borella/MW/US/3Com, "'Saint-Hilaire, Ylian'" > > > > cc: nat@livingston.com > > Subject: RE: (NAT) RSIP and IKE rekey > > > > > > > > > > >On the other hand, Ylian is referring to the case in which an external > > >host talking to multiple RSIP clients doesn't know which isakmp SA > > >to use because it is basing the identity of its peer on the shared > > >IP address. Here, IMO, the external implementation is not making the > > >right assumption. > > > > I think that the solution to this one is for the IKE initiator to > > negotiate *very* specific filters for the IPSEC SA so that the > > destination will not be confused. For example, if the RSIP > > client were to dynamically plumb a filter corresponding > > to the RSIP port/address that it was allocated, this would guarantee > > uniqueness. > > > > Example filter: > > From: To: destination address > > Source Port: Dest Port: destination port > > > > > > > > > > > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe nat' in the body of the message. > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Tue Dec 21 04:29:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08154 for ; Tue, 21 Dec 1999 04:29:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id BAA13433; Tue, 21 Dec 1999 01:24:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id BAA18530 for nat-outgoing; Tue, 21 Dec 1999 01:25:54 -0800 (PST) Message-ID: From: "Egevang, Kjeld" To: "'nat@livingston.com'" Subject: RE: (NAT) doubt in checksum calculation algo of NAT. Date: Tue, 21 Dec 1999 01:25:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Egevang, Kjeld" Hi. It will work fine if you set optr and nptr to point at the previous byte and increment olen and nlen. Note that it is not advisable to just redo the checksum calculation unless you check the checksum first and discard packets with bad checksums. /Kjeld > -----Original Message----- > From: Ramasamy [mailto:ramsrm@future.futsoft.com] > Sent: 16. december 1999 06:23 > To: 'nat@livingston.com' > Subject: (NAT) doubt in checksum calculation algo of NAT. > > > > Hi > I have a doubt in checksum caluclation module of NAT. > Actually, the checksum calculation algo. given in > draft-ietf-nat-traditional-01.txt will work only if the optr( > pointer to the old data ) is at an even offset from the start > of the header. > suppose if optr starts from the odd offset, can we change > optr to optr-1, so that it will point to the byte which is > immediately before the actual start of the old data and now > the optr points to an even offset from the start of the > header. after this modification ,can we apply the same algo. > will there be any problem? > > or do we have to compute the checksum byte by byte in the > usual way, if the conditions given in the draft are not satisfied?. > > please clarify my doubts. > > bye > rams. > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Wed Dec 29 18:34:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05186 for ; Wed, 29 Dec 1999 18:34:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id PAA00354; Wed, 29 Dec 1999 15:29:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id PAA06282 for nat-outgoing; Wed, 29 Dec 1999 15:30:00 -0800 (PST) From: "Bernard Aboba" To: Subject: (NAT) Some thoughts on PPTP and RSIP Date: Wed, 29 Dec 1999 15:30:11 -0800 Message-ID: <005901bf5254$a8e23230$2d8939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit Back a while ago, there was a question on how PPTP might be supported in RSIP. As noted in RFC 2637, PPTP uses a well known port of TCP 1723 for the control channel and a (modified) RFC 1701 GRE header for encapsulated data. The TCP 1723 control channel should just work with RSIP as currently specified. Within the GRE v1 header (protocol 47), two octets of the RFC 1701 Key field is used to encode the Call ID, which (along with the source IP address) can be used to de-multiplex incoming data packets. For those interested in the details, some packet formats are included at the end of this message. RFC 2637 (PPTP) has further details. To support this, the RSIP gateway would need to make sure that no two clients speaking to the same destination would be using the same call ID. This could be accomplished by having the client suggest a call ID which the RSIP gateway could check for conflicts, suggesting an alternative if necessary. The question arose as to whether support for PPTP might be added in such a way that it might apply to other protocols as well. I think that this is possible. This case closely resembles allocation of UDP and TCP ports in that it involves allocation of a two octet field for a IP protocol number. This might be accomplished by including an RSIP primitive ALLOCATE_PROTOCOL that would supply the DEST_IPADDR and PROTOCOL_ID as well as the OFFSET & LENGTH for the field to be allocated, and as usual, a SUGGESTION for the value. For the case of PPTP, the PROTOCOL_ID would be set to 47, the OFFSET to HEX 18 (see protocol diagram below) and the LENGTH to 2. Such a primitive, if supplied, would apply to any protocol that can be specified by an IP protocol number and has a single field that needs to be multi-plexed. The primitive would therefore apply to UDP and TCP as well as modified GRE. The question arose as to whether PPTP support in RSIP could be leveraged to apply to GRE proper, as defined in RFC 1701 (and now being updated). As far as I can determine, I think the answer is no because GRE proper does not have the equivalent of a "port" field. Thus, only one client can be talking to GRE v0 destination at a time. MODIFIED GRE HEADER rfc2637.txt 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (HW) Payload Length | Key (LW) Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: C = checksum present. Set to zero (0). R = routing present. Set to zero (0). K = Key Present. Set to one (1). S = Sequence no. present. Set to 1 for payload, 0 for ACK. s = strict source route present. Set to zero (0). Recur = recursion control. Set to zero (0). A = Acknowledgement seq. no. present. Set to 1 if packet contains acknowledgement no. Flags. Must be set to zero (0). Ver = Must contain 1 (enhanced GRE). Protocol Type = Set to hex 880B. Key Payload length: size of payload, not including GRE header. Call ID: Peer's Call ID for the session to which this packet belongs. Sequence Number: sequence number of the payload. Present if S = 1. Acknowledgment Number = Present if A =1. GRE Header Format http://www.ietf.org/internet-drafts/draft-meyer-gre-update-01.txt 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here: C = 1 if Checksum is present, 0 otherwise Ver = 0 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Dec 30 08:49:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26599 for ; Thu, 30 Dec 1999 08:49:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id FAA06633; Thu, 30 Dec 1999 05:44:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id FAA24098 for nat-outgoing; Thu, 30 Dec 1999 05:45:57 -0800 (PST) Message-ID: <6A8039E06136D31180140060B01B3B84AD2C2C@ma07exm2.corp.isg.mot.com> From: Oliveira Paul-LPO117 To: "'nat@livingston.com'" Subject: (NAT) RE: IETF NAT Digest V2 #170 Date: Thu, 30 Dec 1999 08:44:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Oliveira Paul-LPO117 Bernard Good work! This should solve our pptp problems and other similar problems as they arise. Thanks for your response and thanks for addressing all of my issues. My only comment with regards to what you have spelled out here is that the RSIP Server needs an error code to return to the client if it gets an ALLOCATE_PROTOCOL primitive but does not know (no code for) the protocol that the client has asked for. Paul > -----Original Message----- > From: owner-nat-digest@livingston.com@livingston.com > [mailto:owner-nat-digest@livingston.com@livingston.com] > Sent: Wednesday, December 29, 1999 11:00 PM > To: nat-digest@livingston.com > Subject: IETF NAT Digest V2 #170 > > > > IETF NAT Digest Wednesday, December 29 1999 Volume > 02 : Number 170 > > > > (NAT) Some thoughts on PPTP and RSIP > > ---------------------------------------------------------------------- > > Date: Wed, 29 Dec 1999 15:30:11 -0800 > From: "Bernard Aboba" > Subject: (NAT) Some thoughts on PPTP and RSIP > > Back a while ago, there was a question on how PPTP > might be supported in RSIP. > > As noted in RFC 2637, PPTP uses a well known port > of TCP 1723 for the control channel and a > (modified) RFC 1701 GRE header for encapsulated data. > > The TCP 1723 control channel should just work with > RSIP as currently specified. > > Within the GRE v1 header (protocol 47), two octets of > the RFC 1701 Key field is used to encode the Call ID, > which (along with the source IP address) can be used to > de-multiplex incoming data packets. For those interested > in the details, some packet formats are included at > the end of this message. RFC 2637 (PPTP) has further > details. > > To support this, the RSIP gateway would need to make > sure that no two clients speaking to the same destination > would be using the same call ID. This could be accomplished > by having the client suggest a call ID which the RSIP > gateway could check for conflicts, suggesting an > alternative if necessary. > > The question arose as to whether support for PPTP > might be added in such a way that it might apply to > other protocols as well. > > I think that this is possible. This case closely > resembles allocation of UDP and TCP ports in that > it involves allocation of a two octet field for a > IP protocol number. > > This might be accomplished by including an RSIP primitive > ALLOCATE_PROTOCOL that would supply the > DEST_IPADDR and PROTOCOL_ID as well as the > OFFSET & LENGTH for the field to be allocated, > and as usual, a SUGGESTION for the value. > > For the case of PPTP, the PROTOCOL_ID would be > set to 47, the OFFSET to HEX 18 (see protocol > diagram below) and the LENGTH to 2. > > Such a primitive, if supplied, would apply to > any protocol that can be specified by an > IP protocol number and has a single field that > needs to be multi-plexed. The primitive would > therefore apply to UDP and TCP as well as > modified GRE. > > The question arose as to whether PPTP support > in RSIP could be leveraged to apply to GRE > proper, as defined in RFC 1701 (and now being > updated). > > As far as I can determine, I think the answer > is no because GRE proper does not have the > equivalent of a "port" field. Thus, only one > client can be talking to GRE v0 destination > at a time. > > MODIFIED GRE HEADER > rfc2637.txt > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Key (HW) Payload Length | Key (LW) Call ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence Number (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Acknowledgment Number (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Where: > C = checksum present. Set to zero (0). > R = routing present. Set to zero (0). > K = Key Present. Set to one (1). > S = Sequence no. present. Set to 1 for payload, 0 for ACK. > s = strict source route present. Set to zero (0). > Recur = recursion control. Set to zero (0). > A = Acknowledgement seq. no. present. Set to 1 if packet > contains acknowledgement no. > Flags. Must be set to zero (0). > Ver = Must contain 1 (enhanced GRE). > Protocol Type = Set to hex 880B. > Key > Payload length: size of payload, not including GRE header. > Call ID: Peer's Call ID for the session to which this > packet belongs. > Sequence Number: sequence number of the payload. > Present if S = 1. > Acknowledgment Number = Present if A =1. > > > GRE Header Format > http://www.ietf.org/internet-drafts/draft-meyer-gre-update-01.txt > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |C| Reserved0 | Ver | Protocol Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum (optional) | Reserved1 (Optional) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Here: > C = 1 if Checksum is present, 0 otherwise > Ver = 0 > > - - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat' in the body of the message. > > ------------------------------ > > End of IETF NAT Digest V2 #170 > ****************************** > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe nat-digest' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.