NAT WG meeting minutes - 46th IETF - Washington, DC - Nov 7, 1999 Chairs: Pyda Srisuresh - srisuresh@yahoo.com Matt Holdrege - holdrege@lucent.com Reported by: George Tsirtsis - gtsirt@hotmail.com Gabriel Montenegro - Gabriel.Montenegro@Eng.Sun.COM Prepared by: Suresh & Matt In order to avoid confusion, the following indentation and format legend should be used as a guide to interpreting the minutes. - "" Detailed Slides and/or Comments made by the presenter Questions from the Audience: [ - ] Matt Holdrege - Agenda Daniel Senie - draft-ietf-nat-app-guide-02.txt Dan Raz - draft-ietf-nat-snmp-alg-02.txt Pyda Srisuresh - draft-ietf-nat-interface-framework-00.txt Mike Borella, et al - draft-ietf-nat-rsip-framework-02.txt - draft-ietf-nat-rsip-protocol-03.txt - draft-ietf-nat-rsip-ipsec-00.txt Carmello Zaccone - draft-zaccone-nat-rsip-gen-arch-00.txt - draft-zaccone-nat-transo-fram-00.txt - draft-zaccone-nat-transport-01.txt Matt Holdrege - draft-ietf-nat-protocol-complications-01.txt Vern, Transport Area AD, said that ipr should be disclosed as early as possible. if you can't disclose, you MUST abstain from discussion of the technology. you have a moral obligation to do so. no comments on what would happen if you don't abide by this ietf policy. daniel senie - nat-app-guide-02.txt Comments received from Suresh but not from anyone else. More comment are welcome. Will get a new rev of the draft out shortly. dan raz - nat-snmp-alg-02 defined further problem scope, limitations and alternatives solutions, eliminated snmp discussion - basic: translates only ip addresses only in pdu's from station to manager - no change in pkt length - advanced: xlates non-standard encodings, xlations in pdu's from - station to manager and back. results in change of pkt length. - real need from the nw mgmt service provider industry Juergon: There are technical problems (sorry for not having time to do this on the list). Need to discuss snmpv3 (not just v1), also some conclusions and mechanisms are suspect. answer: we're addressing industry need, and nobody is using v3 today. suresh: what are the issues? answer: main concern - we need to know what snmp alg can do and cannot do and impacts/consequences on snmpv1 versus v3 matt: should discuss v3, but v1 is definitely in order. suresh - nat-interface-framework-00 - framework for interfacing with nat. - predecessor: nat api draft (bad name) There is renewed interest in the draft because of (a) mib spec for nat, (b) requirements on how to interface with a NAT as an alg, etc. so revised and reworded the old draft to address these issues specifically. This draft should also help in identifying RSIP protocol requirements. Also described is how an FTP-ALG would use the interface to influence NAT operation. FTP-ALG registration process expressed in the context of this framework functions exchanged between the ftp-alg and the nat gw working group polled for any comments. Elliot Lear: Is there support for moving this forward as an RFC? No comment from the audience. Suresh: Anyone who doesnt want the draft move forward? No comment from the audience. Elliott: The draft should move forward only if there is explicit request from the work group instead of operating the other way around. No comment from the audience. mike borella - RSIP drafts RSIP framework draft- - major editing and reorganization o client and server reqs o mtu stuff o rsap-ip servers o deployment scenarios o rsip/nat cascades o multi-homed (preliminary) o mobile ip (preliminary) - rsip behind rsip o nat behind rsip o e2e still broken o nat box is rsip client - rsip behind nat: o e2e broken - rsip through nat o need rsip alg in nat box - only rsip behind rsip makes any sense, really - but as you deploy rsip into a natted world, this is a good document Multihoming - more than 1 rsip gw per net for redundancy and failover This can be addressed in different ways from simple mechanisms to heavy weight (transaction processing type of thing) but it is not critical for RSIP at this stage. interaction with mobile ip - how to add rsip stuff to mobile ip - some preliminary discussion, but need to flesh it out and - coordinate with mobile ip working group suresh: it's ok to not finish everything on the first round, as long as you scope clearly what is being solved. Need to finish the framework and basic protocol first. Work on other issues in parallel. Matt: you can always ask the mobile ip list for comments. Brian Carpenter: Need to know if there are show stoppers in mobile IP and any other protocol, details can be worked out later. Mike continue with the presentation. next steps - Still need to work on the following: - rsip and mcast - rsip/rsvp/diffserv - registration of servers via dns servers - locating rsip servers - particularly if you're not on the - same subnet - Use dhcp or SLP? - session authentication must scope rsip to be able to finish it (at least partially) within the near future suresh: is rsip an app specific configuration or host specific on the client? There might be reasons to only use RSIP for a set of applications. matt: It is stack specific. Gab: similar problem to mobile ip and ipsec: it's possible to use it selectively Elliot: Much better than last draft. Still some issues with the draft: - How much routing is required in the client? Does host need Routing info? routing tables in the client can get fairly complex. must clarify. - How does it use SLP? - There are some security implications. what if you use ipsec for the rsip tunneling from the outside? nobody can determine who is actually speaking to whom. this is both good and bad and should be documented. - What if you rap RSIP in IPSEC? Some interesting trust relationships. Danny Raz: UDP packet size might be larger than what the spec says. - udp mtu of 500? where from? suresh: Two points: - A node should be able to select when to use NAT and when to use RSIP. - You may have multiple RSIP instances. RSIP instance ID is needed to select which RSIP instance (i.e., address pool) to use. Elliot lear: Two points. 1. rsip is a remediation. it's got overhead. Applications should be able to do things other than RSIP. Need to discuss on e-mail 2. cascading rsip servers you used public address space, this is the right thing. when you cross realms the recommendation worth restating is that you use public addresses. Brian Carpenter: on point 2 above, clear conclusion from the iab workshop is that the global address space is a requirement - on point 1 above: application must be aware? - no, then just use ipv6. that's the whole point. RSIP protocol draft - Streamlined. One way of doing rsip. Basic primitives to do rsip. Anything else should go in a separate draft (like rsipsec) To be done: - overall length field in msgs - error messages must be fleshed out What should be the trasport medium for RSIP? - tcp vs udp Matt: If there are no objection the best thing is to have only one transport protocol and this is TCP. If later we realise that UDP is needed for a case we can do it later. Mike: I agree suresh: Server could support both and client should be able to choose between the two since the RSIP protocol does not depend on the underlying transport medium. Mike: In fact there might be changes in the protocol. E.g some things are not needed if you do TCP. Eliot: Also agrees that ONE protocol is best but RSIP seams too lightweight for heavy TCP connections. Mike: Other things constrain RSIP resources before TCP state becomes a problem Elliot: What are the benefits of TCP? Mike: better security, reliability Bernard: TCP also helps with state control since the TCP connection will drop if a client crashes. Gabriel: Auto-tuning can solve the large number of TCP connections problem. Matt asked for show of hands: The rough consensus was to use TCP-only as the transport. UDP may be brought in later on. Suresh: Couple of other comments. - After hearing Brian Carpenter's comment about applications not requiring change with RSIP, I agree with him. Now, I do believe, RSIP should be host specific - not application specific. - More examples are needed during protocol specification. - There seems to be an underlying assumption throughout the the document that address assignment is a function of the RSIP server and that address assignment and tunneling are in the same box. (Mike says yes!) - Other than tunnels might also be used to traverse RSIP packets in private realm. Ex: Zaccone drafts, NAT based translation of encapsulating header. Mike: Tunnel is the only mechanism we are sure will work at the moment. RSIP IPsec draft - Just made the cut-off day. Some work is still needed here. Gabriel Montenegro: Need discussion on how to handle incoming SAs Bernard Aboba: There might be an issue with interactions with IPSEC bump-in-the-stack implementations. carmelo zacconi - RSIP transport (within private realm) framework Possible extensions on the RSIP framework on the transport of datagrams in a native way without using tunnels. Enable forwarding of incoming packets without tunneling to the rsip client How to enable these reverse paths? the other drafts explore specific mechanisms with their tradeoffs. Specific mechanisms to build the reverse path are: 1. ospf minimized router daemon on the host 2. multicast - create a tree 3. rsvp - install info on a restricted set of routers RSIP-gen-arch - Aim to make RSIP more reliable De-couple set of functions from RSIP server Support RSIP multihoming Offer policy and accounting Assume multiple ISPs and multiple function blocks building RSIP (Policy Manager, Internet Session Manager and Configuration Manager) Brian Carpenter: 1. The idea of not using tunnels when you can is good. 2. Multihoming needs to be solved but this seams like a very complex solution because it attempts to define an architecture. IETF only defines tools. 3. Reliability is important but having a lot of stateful boxes is against Internet design principles and may damage the stability of the whole system. Gabriel Montenegro(Gab): On the transport alternatives: suggest to have routing ADs look at this, as this is not specific to rsip but may apply in other areas as well, and is hightly routing specific in content. Eliot Lear: Many interesting points in the draft (not agree with all). Not using tunnelling is also good if you try to do things like Diffserv. The separate Policy Manager is also a good idea. Suresh: The draft is interesting and may have wider applicability as the draft is really about RSIP route/policy enforcement on the routers in private realm. Mike Borella: This is interesting for rsip+ but is perhaps not part of rsip first release. matt holdrege - NAT protocol complications. Matt will issue an IETF last call after the next rev is posted. Tony Hain: Scott bradner currently has the pen on the IAB document. Should get a new rev out in a couple of weeks (by the end of 11/99?) james kempf (sun) - Using SLP for RSIP server discovery why not to use DHCP; but use SLP: - dhcp requires configuration on the server (home networks?) - slp requires nothing but the rsip server - slp uses mcast (versus bcast) - dhcp can't specify attributes - slp can find server based on attributes - option number space in dhcp is running out - slp is not a problem, define a url/template, text based - dhcp can't do dynamic updates - slp reflects availability dynamically Template for rsip servers template-type = rsip template-version = 0.0 url-syntax = ;nothing_beyond: host:port ipsec-support = BOOLEAN ike-support = BOOLEAN tunnel-type = STRING L etc.. draft forthcoming suresh: seems applicable Elliot lear: how to handle multiple rsip servers? jim kempf: slp has a semi-reliable mcast called mcast convergence which can aid in this Mike borella: looked at dhcp individual submission draft that defines dhcp option for server redirect suresh: suggests this draft be submitted as working group item. seems like a good idea to have both options - DHCP configuration option as well as SLP.