From owner-nat@livingston.com Thu Aug 3 11:00:14 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02635 for ; Thu, 3 Aug 2000 11:00:13 -0400 (EDT) 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 HAA18648; Thu, 3 Aug 2000 07:47:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id HAA00396 for nat-outgoing; Thu, 3 Aug 2000 07:47:58 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <4.3.1.2.20000803064720.00c3eef0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 03 Aug 2000 07:41:34 -0700 To: nat@livingston.com From: Matt Holdrege Subject: (NAT) RSIP issues Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege In today's NAT Working Group meeting, we discussed the idea of creating a new working group focused entirely on RSIP. We also discussed the possibility of moving RSIP from Standards Track to Experimental Track. The key people involved in RSIP have agreed that the documents could best move forward as RFC's if they are on the Experimental Track. This by no means prevents RSIP from moving back to Standards Track at a later date if there is consensus to do so. If anyone objects or has comments, please let us know. Forming new working groups and managing existing working groups is the responsibility of the IESG. But if you have any feelings one way or the other regarding the formation of a new RSIP working group, please let us and/or the IESG know. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Aug 3 11:47:51 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23753 for ; Thu, 3 Aug 2000 11:47:50 -0400 (EDT) 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 IAA19495; Thu, 3 Aug 2000 08:39:28 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id IAA03114 for nat-outgoing; Thu, 3 Aug 2000 08:41:33 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <4.3.2.7.2.20000803112457.00b4b120@airborne.cisco.com> X-Sender: sbrim@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 03 Aug 2000 11:36:38 -0400 To: Matt Holdrege From: Scott Brim Subject: Re: (NAT) RSIP issues Cc: nat@livingston.com, iesg@ietf.org, foglamps@lists.panix.com In-Reply-To: <4.3.1.2.20000803064720.00c3eef0@pop3.ipverse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Scott Brim At 07:41 AM 08/03/2000 -0700, Matt Holdrege wrote: >In today's NAT Working Group meeting, we discussed the idea of creating >a new working group focused entirely on RSIP. We also discussed the >possibility of moving RSIP from Standards Track to Experimental Track. I see an overlap between RSIP and the proposed CAVITI WG. Below are a couple excerpts about CAVITI. ...Scott At 08:01 AM 08/02/2000 -0700, Matt Holdrege wrote: >CAVITI assumes that the modern Internet topology is varied in many ways. >We have IPv4 nets and IPv6 nets. We also have NAT's and Firewalls to >deal with. We have people trying to communicate across such networks, >sometimes using private addresses at the edge and even sometimes in the >middle. Communicating across these mixed topologies is problematic for >many protocols and applications (see >draft-ietf-nat-protocol-complications-04.txt). > >Notable difficulties occur with realtime multimedia protocols and their >related signalling protocols. Especially, urgent solutions are needed >for IP Telephony. Therefore CAVITI will work on documenting their >requirements for such communications, aiming ultimately at a solution >set which may involve control protocols and actions to aid >mixed-topology communications. At 11:23 AM 08/02/2000 -0400, Melinda Shore wrote: >2) while there is overlap with existing working groups, there > is no appropriate home in any of them for this work >4) in scoping the work, we need to focus on control of > packet filters, and location/topology problems are out > of scope >The ADs would like to see us broaden our scope just a bit to >include more generalized control of packet filters. Two >examples that were raised are buffer control (allocation, >not shaping), and v4<->v6 address translation. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Aug 7 14:58:44 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25581 for ; Mon, 7 Aug 2000 14:58:43 -0400 (EDT) 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 LAA17033; Mon, 7 Aug 2000 11:46:40 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id LAA11430 for nat-outgoing; Mon, 7 Aug 2000 11:42:45 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <200008032308.TAA11514@pzero.sandelman.ottawa.on.ca> To: nat@livingston.com, iesg@ietf.org, ipsp@vpnc.org cc: Matt Holdrege , foglamps@lists.panix.com Subject: Re: (NAT) RSIP issues In-reply-to: Your message of "Thu, 03 Aug 2000 11:36:38 EDT." <4.3.2.7.2.20000803112457.00b4b120@airborne.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Thu, 03 Aug 2000 19:08:04 -0400 From: Michael Richardson Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Michael Richardson -----BEGIN PGP SIGNED MESSAGE----- {please double check the ipsp address before you blindly reply. I'm offline, and I keep forgetting to record it} >>>>> "Scott" == Scott Brim writes: Scott> At 07:41 AM 08/03/2000 -0700, Matt Holdrege wrote: >> In today's NAT Working Group meeting, we discussed the idea of creating >> a new working group focused entirely on RSIP. We also discussed the >> possibility of moving RSIP from Standards Track to Experimental Track. Scott> I see an overlap between RSIP and the proposed CAVITI WG. Below are a Scott> couple excerpts about CAVITI. There is some serious overlap with IPSP's SPP protocol as well. RSIP, SPP, RSVP and I think MEGACO, involve sending out messages to determine and/or provision services prior to actually making a "call" In the case of RSIP and SPP, one actually has to modify the parameters of one's call slightly (changing source addresses, SPIs, port numbers, or adding AH/ESP) based upon the response. RSVP does not typically involve modifying any parameters, but one might decide not to make the "call" if one can't get the bandwidth. This is an entirely different paradigm than we are used to. While attempting not to reinvent the ISDN control protocol, I think that some consideration should be given to how one might be able to unify some of these setup protocols. Perhaps this should go like it does in Cosmology/Particle Physics: attempt unification of two, and then three, etc... Did CAVITI meet? Melinda> The ADs would like to see us broaden our scope just a bit to Melinda> include more generalized control of packet filters. Two Melinda> examples that were raised are buffer control (allocation, Melinda> not shaping), and v4<->v6 address translation. Interesting. ] Train travel features AC outlets with no take-off restrictions|gigabit is no[ ] Michael Richardson, Solidum Systems, in transit from PIT |problem with[ ] mcr@solidum.com www.solidum.com to PHL |PAX.port 1100[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.5.5, an Emacs/PGP interface iQB1AwUBOYn7TY5hrHmwwFrtAQHBtQL/fRN3LqQDvv7k6tOr5epdSAvjJ2Gj0Diz pYWP3Oun1TnQQ08l3UOFIJfOGqzUVUUvEIoyP9d2IRwNvmEq+FRBqwDrxJeqE2VS pAepFBufP7yXnWu/q3CBnaT996/8f6XP =Eu2a -----END PGP SIGNATURE----- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Thu Aug 10 13:46:40 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06522 for ; Thu, 10 Aug 2000 13:46:39 -0400 (EDT) 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 KAA13747; Thu, 10 Aug 2000 10:37:37 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id KAA28526 for nat-outgoing; Thu, 10 Aug 2000 10:37:48 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB08A1694D@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Tony Hain Cc: Randy Bush , Scott Bradner , Allison Mankin , nat@livingston.com Subject: (NAT) nat implications doc Date: Thu, 10 Aug 2000 19:36:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Wijnen, Bert (Bert)" On page 10 (end of Sect 5) you talk about "IP based authentication in SNMPv3" Not sure where you get that from, but SNMPv3 does not do such things. The SNMP architecture allows SNMPv1/v2c to be included and RFC2576, coexistence document, does talk about possible "authentication" using IP addressses. But not for SNMPv3. If the "SNMPv3" gets changed in just "SNMP" I can live with it... although I still wonder why SNMP would be singled out... are there other examples that can be added, so as to not make SNMP stand out so "badly" Also, on page 11 (sect 6) you list that NAT does invalidate SNMPv3 authentication. I don't think that NAT itself does that. The ALG that has been presented raised lots of security issues. But if there is no ALG that needs to fiddle with the packets, then I do not think that NAT itself invalidates the authentication necessarily. Thanks, Bert - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Aug 11 07:13:27 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09331 for ; Fri, 11 Aug 2000 07:13:26 -0400 (EDT) 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 EAA24830; Fri, 11 Aug 2000 04:05:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id EAA15252 for nat-outgoing; Fri, 11 Aug 2000 04:01:55 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-ID: From: "Fredrik Thernelius (UAB)" To: "'nat@livingston.com'" , "'foglamps@lists.panix.com'" Subject: (NAT) New mailing list Date: Fri, 11 Aug 2000 13:01:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 11 Aug 2000 11:01:42.0778 (UTC) FILETIME=[883EA5A0:01C00383] Sender: owner-nat@livingston.com Precedence: bulk Reply-To: "Fredrik Thernelius (UAB)" Greetings everyone! In order to get some discussion started regarding taking SIP through NAT enabled firewalls I've started a new mailing list. The list is available at http://www.egroups.com/group/sip-nat-firewall I've said on on that site that the main issue is to discuss the proposal me and Bertil had: http://www.cs.columbia.edu/~hgs/sip/drafts_firewall.html http://search.ietf.org/internet-drafts/draft-thernelius-sip-firewall-solution-00.txt You're all welcomed to get the ball rolling! Kind Regards, Fredrik Thernelius - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Fri Aug 11 09:49:15 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15821 for ; Fri, 11 Aug 2000 09:49:15 -0400 (EDT) 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 GAA25968; Fri, 11 Aug 2000 06:40:42 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id GAA19310 for nat-outgoing; Fri, 11 Aug 2000 06:42:40 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Date: Fri, 11 Aug 2000 09:37:58 -0400 (EDT) From: Scott Bradner Message-Id: <200008111337.JAA08737@newdev.harvard.edu> To: nat@livingston.com Subject: (NAT) draft-iab-nat-implications-09.txt Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Scott Bradner The IAB has published a new version of the Architectural Implications of NAT ID. The ADs would like to use this document to fill the NAT working group's milestone for a document detailing the limitations of NAT. The IAB document is now in front of the IESG for our consideration and the ADs would like to issues an informal working group last call on the ID (draft-iab-nat-implications-09.txt). Note that this document has gone through a lot of revisions in response to input from the NAT working group chairs and others - so we are mostly looking for significant tecnical issues rather than wording preferences. This informal WG last-call will end August 22 - this will give us time to evaluate the responses before the next IETF teleconferenmce on August 24th. please send comemnts to the nat working group list. thanks Scott & Allison - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Aug 21 02:34:30 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27717 for ; Mon, 21 Aug 2000 02:34:29 -0400 (EDT) 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 XAA27415; Sun, 20 Aug 2000 23:23:58 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id XAA15242 for nat-outgoing; Sun, 20 Aug 2000 23:27:35 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <4.3.1.2.20000820232011.00bbe510@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 20 Aug 2000 23:24:31 -0700 To: nat@livingston.com From: Matt Holdrege Subject: (NAT) WG last call for the Protocol Complications draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege The NAT Working Group is issuing a Last Call for http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-04.txt This draft has been updated following the IETF-wide last call earlier this year. Since it's summer holiday time, we'll wait til September 11th to see if we get significant comments. Please send comments to the authors or this email list. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. From owner-nat@livingston.com Mon Aug 21 02:39:12 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27716 for ; Mon, 21 Aug 2000 02:34:29 -0400 (EDT) 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 XAA27389; Sun, 20 Aug 2000 23:22:52 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id XAA15164 for nat-outgoing; Sun, 20 Aug 2000 23:19:53 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-nat@livingston.com using -f Message-Id: <4.3.1.2.20000820231207.00bbe120@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 20 Aug 2000 23:16:57 -0700 To: nat@livingston.com From: Matt Holdrege Subject: (NAT) Pittsburgh minutes Cc: minutes@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-nat@livingston.com Precedence: bulk Reply-To: Matt Holdrege NAT WG Minutes Scribed by Daniel Senie Matt Holdrege and Pyda Srisuresh WG Chairs Thursday, August 2, 2000, 9AM Agenda: - NAT Implications - Tony Hain - NAT Protocol Complications - Matt & Suresh - NAT traditional - Suresh - RSIP drafts - Gabriel - App Guide - Daniel - Interface Framework - Suresh - NAT WG Revised milestones - Aboba-NAT-IPSec - William Dixon - ipsec-nat-traversal - Steinberg -- Matt: Introductions. RSIP -> Experimental path being considered. Proposal stage only at this point, will be taken to the mailing list. Tony Hain: IAB Draft. Current revision -08. Minor comments received from Suresh. Send Tony additional comments. Status: almost done, needs cleanup then publication. Suresh: The draft does seem closer to being done - awaiting response to the comments sent. Matt, Protocol Complications draft: IETF last call did the trick in getting comments. Comments incorporated. Draft will be sent to WG last call. Suresh: reviewed changes made in most recent draft: Added a section on common characteristics of protocols broken by NAT. Draft redone to ensure there were no "pro-NAT" wording, or understatement of the problem. New text for lack of support of Kerberos, X Windows issues (FQDN can't be used). Send comments. Suresh: Traditional NAT draft. WG last call and review complete long time back. Any additional comments, feedback still OK. Awaiting IESG review pending other base NAT drafts. Publication of all base NAT documents (IAB draft, NAT complications draft and traditional NAT draft) must happen together. Gabriel: RSIP drafts. Revised framework specification and support for end-to-end IPSec. Framework document: Mike Borella lead, introduction rewritten, replaced implementation considerations with requirements section. Added sections in multi-party applications and scalability. Toned down mobile IP interaction. Added reference to the SLP-RSIP draft, and added a table of contents. Protocol specification document: registrations have lease times. Management of lease times discussed. Most packet and field diagrams documented in canonical form. RSIP gateway can redirect a host to a particular tunnel endpoint not necessarily itself. IPSec support document: put message time before overall length to align protocol with protocol draft 5 added message counter parameter. Suresh: Comments: Discussion on IETF list about administrative / manageability of RSIP stack. Has this been added? Gabriel: yes. Suresh: Concern RSIP is significant effort to manage. Concern there's issues with how the control channel interacts with applications. There are many applications that are affected by the way RSIP control and application data paths interact, but haven't been addressed. Gabriel: expects there are holes, needs a summary or to do some research in this area. Multi-party case, is a good example, the RSIP folks don't know how to address these. Action item: Gabriel will research updates to deal with the issues. Suresh will try to get some summary information from the discussion on the IETF list to Gabriel. Mike Handley (sp?): Blanket statement that there's no need for ALGs in RSIP. Believes there could be more explanation. Suresh: Assumption is that with RSIP replacing NAT, this obviates the need for ALG (end host will do the work). Protocol draft: last message buffer discussion could use clarification. Is it per-host? Matt: Yes. Daniel: draft-ietf-nat-app-guide-03.txt received few comments. Suresh suggested adding a section on peer networking, mirroring the protocol complications draft, and suggested verifying similar content match-up with other areas. Suresh: Interface Framework document. Foglamps mailing list discussion of mechanism to control firewalls and NATs and control resources. Very similar to what's in this draft, which has added interest to this draft. Now interest in building a protocol for interfacing with NAT/Firewall. This document could be the basis for such work. Interfacing with ALG both internal and external, administrative agents, RSIP clients, multihomed-NATs, and so forth. Addresses foglamps issues relating to NATs (not firewalls), but could be used in that area. Would like to move this document along within the WG. Milestones: Matt: we're late. Milestones not met. Base documents are about ready. the IAB draft also a gating factor. Suresh: By early next year, WG milestones should be completed, provided the base NAT drafts are cleared with IESG. Brian Carpenter: should RSIP be split out to a separate WG to get it completed? Matt: not clear it'd get more attention as a separate WG. In any case, it's an IESG issue. Alison: IESG will discuss as a part of the charter discussion. Gabriel: RSIP really separate from NAT, and would prefer if it were split off. Suresh: 9 months ago, ADs thought the NAT WG be the place to put it, but in the mean time, the NAT drafts haven't progressed so quickly. Matt/Alison: take hum of the room. Seems to be rough interest in splitting RSIP off into separate WG. Alison will take input to IESG and see what consensus is. Bernard Aboba: NAT and IPSec discussion: draft-aboba-nat-ipsec-02.txt. Will talk about the problem here, not solutions. Solutions will be discussed at IPSec group. Goals and objectives: Describe the scenarios and issues. Usage scenarios: Telecommuters with IPSec and NAT because of DSL/Cable modems. Tunnel scenario. Transport mode is seen as extremely difficult at this point. Compulsory tunneling cases exist with ISPs and other upstream cases. Various discussion from the floor about DSL, cable modems and STSN/hotel system. Suresh: Can it work with IPSec running in the NAT box? Bernard's experience is customers don't handle it. Bob Moskowitz: Providers forcing IP address changes often via DHCP as a way to limit servers on cable modems and such. Makes matters even worse. Known Nat/IPSec incompatibilities: AH, checksums (pseudoheader issue). UDP checksum is optional, providing a way around. Alison comment that they should be used, however. Tunneling discussion: if inner packet is unaffected. IKE allows other identifiers, not necessarily just IP addresses. Issues with embedded IP addresses within NAT (in payload). Incompatability between IKE destination ports and NAPT. Source ports will be changed. Re-key can occur on either side. Re-key coming from server looks like unsolicited packet, and NAT will drop it. NAT Port timeouts a big problem here, as the mapping would have to keep the association alive. In transport mode, Incompatibility between overlapping security policy and NAT policy. Makes for difficulty in deciding where to send information. Without client-nat communication this is a problem. Suresh: request quick mode vs. main mode issues be isolated. Incompatability between SPI selection and NAT: issue is SPI of packets incoming to NAT with out client-nat communication NAT must depend on timing. A problem nearly all the time. Summary: NAT compatability critical to key uses to Ipv6. Incompatibilities substantial and intricate. Goal is to find a solution sooner than Ipv6. Brian Carpenter: 6-to4 has the same problem. Floor question: how about tunneling IPSec over L2TP. Marcus Stenberg: Short talk about his draft. Only requires changes in end station. Marcus Leech (AD): IPSec WG will be chartered to deal with the interoperability issues. End Of Meeting - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message.