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