NAT WG - Oslo - Tuesday, July 13th Chair: Matt Holdrege Reported by: Gabriel Montenegro gab@Sun.COM George Tsirtsis agenda bashing - The Agenda was accepted Milestone status The NAT Terminology and Considerations draft was approved by the IESG and will soon receive an RFC number. This is a very important document as it describes the terms that all IETF documents should use when discussing NAT. Other drafts in the works are... dns-alg draft traditional nat nat api security for nat domains nat friendly app designs hnat snmp alg rsip (framework, protocol, ipsec) Each can be found on the IETF NAT WG web page. There is some delay in the milestones due to the extensive review of the NAT terminology draft. Protocol Complications - Matt Holdrege - draft-ietf-protocol-complications-01.txt The updated draft is available on the IETF web site. Matt solicited input from NAT WG and all other WG chairs but has not received a lot of feedback. We need to understand which applications do not work with NAT including non-IETF applications. (vendor specific etc). There is a suggestion to make this Informational RFC shell and put the text on the Web so it can be updated Someone pointed out that Web - RFC links may be unstable so RFC should be stable and self contained The Weird WG is trying to put all RFCs in Web Form, NAT could be a pilot project Matt wants to make the ITU and other external bodies aware of this document so IP technology developed outside the IETF can consider NAT. Matt also is thinking about more than the general usage of NAT. The typical use: home user going out to global internet (1 nat) and back into a corporation (2nd nat). Vern said that the doc should be as self-contained as possible. RSIP - Mike Borella Three RSIP drafts exist. A framework document , the RSIP protocols specification and RSIP interactions with IPSEC document. draft-ietf-nat-rsip-protocol-01.txt draft-ietf-nat-rsip-framework-01.txt draft-ietf-nat-rsip-ipsec-00.txt Framework Document Public Internet to private intranet connections need to be studied further. George Tsirtsis: May want to look at DSTM and NAT-PT in NGTRANS WGs that study a similar problem. . Overview of RSIP operation The draft talks about the context, scoping and philosophy of RSIP and discusses different methods, pros and cons. There is added talk of demultiplexing beyond port numbers, subnet query pros and cons for determining locality of location. Next steps Move TCP TIME_WAIT, ICMP and DNS from protocol draft into framework Add section on external access to internal servers Mike's suggestions for future: make choices and nail down stuff in framework More security considerations Distinguish between client-server application (much easier) and supporting external access to internal servers (more complicated) George Tsirtsis - look at what ngtrans is doing for v6 to v4 mechanisms The RSIP Protocol Local Authentication needs more work/feedback An example has been added in the anex Need to extend error messages Issues Transport for RSIP: now has its own port number but could go over SHOCKs/DHCP/IPCP Brian Carpenter: to clarify this is about transport of RSIP signalling and not data after address allocation. Many people have not used TCP only to realise later that TCP is a good idea after all because of reliability. etc. Mike also agrees. BIND messages for local servers. Needed but not sure how it is going to be implement in different scenarios Client state diagram Someone asked could you dislocate RSIP server from gateway router? This way multihoming will become easier. Mike: Yes but it is too complex. The end of the protocol draft lists the changes: We discussed an appendix with protocol example with negotiation example, and addr and port resource error messages. We are starting to gain implementation experience, and gain in understanding of what's needed. This means there will be changes to this part of the spec We can implement a NAT function as a complement coexisting with rsip server We must decide on transport for the RSIP signalling: socks/dhcp/ipcp/port? reliable/unreliable (TCP/UDP)? Brian Carpenter - TCP is a good choice Mike: yes, TCP and authentication BIND msgs for local servers? not needed for road warrior perhaps for home networks Client state diagram mike's adding this to the draft Someone: why not separating the router from the rsip server box? Gabriel responded later that this separation would benefit from allowing the rsip client to express not only that it needs a tuple (address, port, spi, etc), but also to express what the intended peer of this session will be (a la nar/socks) IPSEC draft This is a combination of 3com work and Gabriel Montenegro's/sun (NAR draft) This extends RSIP to support IPSEC. No change required in IPSEC. Client and server agree on initiator cookie and spi Future issues e2e security model and assumptions Policy integration Host with some policy Plug into a network with policy Mild violation of cookie creation, mild violation of 2408 sec 2.5.3 To avoid socket collisions, clients should/must also allocate port numbers in additions to the SPI. IKE: use initiator cookie as demultiplexer ESP: use incoming spi We are soliciting input as we revise these drafts Discussion on Mobile IP support some drafts that talk about this are: http://search.ietf.org/internet-drafts/draft-ietf-mobileip-privaddr-00.txt http://search.ietf.org/internet-drafts/draft-teoyli-mobileip-mvpn-02.txt General Discussion: Mike: All drafts are being revised. If people have strong opinions now its time to contribute Someone said that RSIP is kernel level and may not work with Raw sockets. Matt: virtual sockets with an abstraction layer could be used to handle raw sockets. Someone asked: What interactions you have with Mobile IP? Mike: a document was written 1.5 years ago but needs to be revisited. Gabriel: RAT may also have interactions; NAR (predecessor of RSIP) studies both mobility and security so, could be used as reference. An other document also exists dealing with private addresses and mobile IP. Brian Carpenter asked: Does RSIP requires other things to be changed (e.g: DNS) Is there a roadmap for the future of this work? Matt: Roadmap will need input from others (IAB?). Gabriel: Need to separate RSIP of the future from RSIP of now that we need for Home Networks etc. Definitely need to work more on Security and already work with Security people. Incoming connections and multiple RSIP gateways are also future work items. Matt: RSIP for now may need to be made more robust to deal with RSIPxN situations. Gabriel: Agree but RSIP may already be too big (according to NITS BOF people) so we need to allow people to implement only parts of it for what they are doing. Matt: RSIP is not specifically in the WG charter but has been worked on here and it may be better to keep it in NAT WG for now until IAB or IESG can give us more directions. Steve Bellovin: No more direction is likely to come out of IAB, further to what was given in the network layer BOF. You should understand what needs to be done for the general case and do it. Do not wait for someone to give you the go ahead. Conclusion: RSIP will remain in the NAT WG for now 5. NAT Transport - Carmelo Zaccone - draft-zaccone-nat-transport-00.txt Access to Multiple ISPs is a problem and the tunneling approach has drawbacks This work attempts to identify ways to do this without tunneling Possible approaches: Turn PC into Router running OSPF (minimum implementation) Use multicast to advertise unicast addresses via trees rooted in the host Reverse path creation with RSVP Discussion: clarification questions on the different mechanisms, scalability etc. Mike: Problem space is valid but solutions seams too complex. Are there any alternatives? Discussion to continue on the mailing list 6. AOB None. Meeting dismissed.