NAT WG meeting minutes - 44th IETF - Minneapolis, MN - March 19, 1999 Chairs: Matt Holdrege Pyda Srisuresh Reported by: Ben Rogers Edited by: Matt & Suresh Attachements: 1. RSIP IETF 44.PPT 2. IETF-NAT-SNMP-ALG.PPT ____________________________________________________________________ Mailing list: nat@livingston.com To subscribe: Send e-mail to nat-request@livingston.com with "subscribe" in the body of the message. To unsubscribe: Send e-mail to nat-request@livingston.com with "unsubscribe" in the body of the message. Mailing list: nat-digest@livingston.com (This is nat mailing list, in daily-digest format. To receive the digest, you can subscribe as follows.) To subscribe: Send e-mail to nat-digest-request@livingston.com with "subscribe" in the body of the message. To unsubscribe: Send e-mail to nat-digest-request@livingston.com with "unsubscribe" in the body of the message. All presentations, along with WG meeting minutes will be avilable on-line from the following URL (Within a few days after this posting) http://www.livingston.com/tech/ietf/nat ____________________________________________________________________ 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 - "WG Introduction" Agenda IESG Document Status Architectural Implications of NAT draft-iab-nat-implications-03.txt Protoocl Complications with the IP network Address Translator (NAT) draft-ietf-nat-protocol-complications-00.txt NAT Friendly Applications Design Guidelines draft-ietf-nat-app-guide-01.txt An SNMP Application Level Gateway for Payload Address Translation draft-ietf-nat-nat-snmp-alg-00.txt Realm Specific IP: A framework draft draft-ietf-nat-nat-rsip-framework-00.txt Realm Specific IP: Protocl specification draft-ietf-nat-nat-rsip-protocol-00.txt IP Relocation through twice Network Address Translators (RAT) draft-ietf-nat-nat-rnat-00 Miscellaneous Pyda Srisuresh - "IESG Document Status" Reminded the audience about the Word from the ADs concerning presentation discipline, sent as part of agenda e-mail. Presenters should focus on unresolved/outstanding issues rather than give tutorial of their drafts. We intend to operate this way from this point on, going forward. Further, most of the issues should be debated over the mailing list. For those presenters, who came prepared with some educational viewgraphs, I would be glad to add those slides to the WG minutes, even as they donot get to present these slides. Terminology draft - is intended to encourage the use of same common terms across drafts. This draft is a required reading for all NATWG attendees. As for WG drafts with the IESG - the IESG has close to 4 drafts (The DNS-ALG went through WG last call but not resubmitted with changes folded in). Suresh has been working with the IESG members to remove ambiguities and clarify text in the terminology draft. As soon as the draft clears its way, other should follow right along. Pyda Srisuresh - "Agenda change" Offline meeting with the Tony Hain, the author of the IAB NAT draft will result in Tony making a new revision of this draft. This new copy of the draft will be discussed in the next meeting, if necessary. We hope, issues are discussed over the mailing list and the draft goes through WG last call much before the next IETF, so we dont have to pursue this until the next IETF. [Tony Hain - If anyone has comments, please send them] [Brian Carpenter - Can Tony tell us the date for the 04 draft?] [Tony Hain - April 2] [Brian Carpenter - We'd like to get any gut feelings out of this draft and try to make it more objective. This should become a draft that we all agree on, instead of an IAB or NAT authored draft.] [Pyda Srisuresh - Yes, I fully agree with Brian's comments. We do like to have a single IAB/NAT-WG draft that people could refer.] [Matt Holdrege - There is a significant positive difference in 03. The review was mostly intended to remove some ambiguities, so readings of 03 might bring up problems which have already been solved.] Matt Holdrege - "Protocol Complications" Little input has come back from this group. Matt has sent a note to all WG and BOF chairs requesting input and specific complications. Very little information was returned. This needs to become an RFC [???? - Which protocols have we already heard from?] The draft shows which protocols we have already looked at and found problems with. Matt may look through protocols as he can to find possible problems. Before the next rev of this draft, Matt will be working on reorganizing the draft to make it more organized and readable. [Danny Raz - Can we make a list of protocols which have been known to be working with NATs?] In theory, this is a good idea. In practice, it will be nearly impossible. It is very hard to actually say that something _certainly_ works with NAT, given obscure options, etc. This will be taken under advisement. [Brian Carpenter - We could add a disclaimer to cover liability. Many of the protocols belong to currently dead WGs. Other areas might not even imagine that they might need to respond to such a request, as they might not see how NAT might be used with them. eg: BGP4] Comments? Pyda Srisuresh - "NAT Friendly application design guidelines" Questions? [Dan Raz - Plans for NAT friendly evangelism outside this document?] No. Only to present the guidelines. If anyone feels like this draft does not address any issues that particular protocols might have, we'd like to hear about them. One of the issues might be that Address bindings are not guaranteed to last in NAT after the session that used the binding has terminated. Some applications such as RSVP require that the Binding parameters be kept alive, even after the session that caused the binding to originate has gone away. This could be a sticky problem area - Are there many such applications ?? But for a few nits, the draft does not seem to have any issues left and may be ready to move forward. More comments? [Rhandeev Singh - DNS lookups? Should the application cache these lookups, or always do the lookup?] The application should do the DNS lookups, but not cache the results longer than is advised in the response. DNS-ALG will set the responses to be valid for no longer than a second for dynamic address bindings. Dan Raz - "SNMP-ALG" The problem o Two or more private networks use the same address space. o A single management station is expected to manage both of them. o Occurs during mergers and with network service providers Constraints o Local networks cannot be reconfigured o No changes to NM software o Transparent to both NM application and to network elements o SNMP Proxies require reconfiguration of the local network and possibly NM software changes. These proxies are intended to support elements which do not have an agent. Solution NAT between n-1 overlapping networks and the NM station Issues o Can this be done using only per-packet information Currently everyone has standarized on using UDP under SNMP. TCP is possible, but not currently supported. o Private MIB and non-standard encoding When the variables contain address information, then we need to translate those addresses. IP address type is the standard way to encapsulate IP addresses, but we often see private encapsulations of those addresses. o Performance There is much work that needs to be done to parse the SNMP packets. o IP addresses are used as an index to MIB tables Basic NAT-SNMP-ALG o Translate only PDUs from network elements to manager (they have the data). o Translate only standard IP address type encoding o Does not change packet length and OIDs o May be insufficient for some applications [Thomas Narten - This doesn't work if you dont have the same number of global addresses as the number of machines you need to manage.] Correct. This is meant to be static. [Pyda Srisuresh - I believe, the requirement is simply that Whoever is assigning the mapping addresses for the various private networks needs to ensure that managed address do not overlap. These neednt be globally unique.] [Thomas Narten - I cannot see why a network manager would want this.] [Bernard Aboba - I'm confused as to what you're trying to manage.] The situation at hand is a real world case, and is a real world requirement from network managers. This application reduces cost [Thomas Narten - The information is now hidden and the network is now much more difficult to manage.] This doesn't necessarily help manage, it works for situations where we could do nothing else. [Bernard Aboba - Write an SNMP proxy. It is easier than NAT.] [??? - won't work for SNMPv3] Yes it will. [Others - Explain nature of v3 authentication and hence cite the reason why SNMPv3 wouldnt work with this solution] It will if the ALG has access to SA keys - The ALG can get this from the SNMP application. [Thomas Narten - Same as IPsec end-to-end versus concatenated tunnels.] The keys are still within a single organization. [??? - Assume that all NATs are run by the same organization.] [Matt Holdrege - Since this is a problem specific solution, this should be Informational.] Yes. [Tony Hain - The applicability statement should be very strong to show that it will not work in all situations.] [Steve Deering - Doesn't the proxy provide a better solution?] No, that requires network reconfiguration. [Brian Carpenter - The proxy would take the load off the normal packet processor, thus providing added advantage.] The NM software gets confused with a proxy. [George Tsirtsis - A proxy can always be used in place of an ALG, but the ALG makes more sense in some cases.] [Brian Carpenter - The management station should be reconfigured to become NAT aware. Without this, there is no way to clearly visualize the network.] Manufacturers of this software are looking to NAT to solve this as they don't want to rework their own code. [Matt Holdrege - This discussion should be moved to the list.] Michael Borella - "Realm Specific IP (RSIP) protocol Specification" o Generalization and extension of HostNAT/DNAT How many have read the draft? [more than 10] Not bad Security o As RSIP is currently defined, spoofing can be used for denial of service. o RSIP should eventually include authentication We're looking for feedback on these security isssues. [Pyda Srisuresh - Are these issues you raise different from that of of a DHCP protocol?] No. Same issues exist in DHCP as well. Problems which RSIP doesn't solve TCP TIME-WAIT o Policy fix at RSIP server NAT problems DNS ICMP requires memory External access to local services [Bernard Aboba - This doesn't seem to work for IPsec tunnel mode for more than one host at a time.] [Unless you have a table of SPIs, you wont be able to demux] Yes [Tony Hain - Make sure this is addressed] [Pyda Srisuresh - Why is TCP TIME-WAIT a problem?] [Thomas Narten - Problem with generic NAT, or is it induced by RSIP?] Listed this as an issue because it was mentioned in the IAB draft. [Timothy Shepard - ICMP issue] Need some memory to properly send pings through Feedback needed o Comments on the whole idea o Evaluation of messages and parameters (too few, too many) Is the protocol too complex, or is it lacking in certain areas o End to end security Will be submitting a draft on how to run end to end IPsec through RSIP. [Gabriel Montenegro - Will the SPI be the demuxer?] Yes. [Gabriel Montenegro - I have NAR draft out that addresses this and can be used as a basis for this area. The old draft has already had some scrutiny from IPsec folks in the last IETF meeting.] [Gabriel Montenegro - Why not use SOCKS as the base and add extensions to supports the RSIP protocol?] [Bernard Aboba - Concern about similarity between this and other protocols. How can we evaluate this against other alternatives?] Will be addressed in architecture draft [Brian Carpenter - RSIP is one solution. We could really use Map-and-Encap in order to compare.] IPv6 Transition RSIP could be used for V6 transition such that IPv4 addresses are assigned to IPv6/v4 hosts. This could be explored in future versions of the draft. [Pyda Srisuresh - The main goal of the draft must be to address Private-v4<=>Public-v4 issues adequately. Subsequent to that, you could work on making it extentsible to other areas, including IPv6 transition] [Pyda Srisuresh - Can the server notify the client?] Yes, to invalidate parameters. [Pyda Srisuresh - Doesn't look like unsolicited messages are covered here.] Not explicitly at this time. [Pyda Srisuresh - Why does a node need to ask for multiple addresses at a time?] Basic-NAT environment where we might need a distribution of a sub-pool of addresses. [Pyda Srisuresh - You mean allocation between servers?] Yes. The server should be able to act as a client to get multiple addresses. [Pyda Srisuresh - This seems confusing and can lead to misconfigurations.] [Pyda Srisuresh - On a different note, Address request and port requests should not be separate, when a host is requesting for a tuple of (IP Address, TU port).] Request for address is combined with a request for a block of ports - for extensibility. [Pyda Srisuresh - The protocol does not seem to take into account domains that are supported by Multiple NATs.] Two RSIP routers for the same client? Is this realistic? [Pyda Srisuresh - Yes] [Pyda Srisuresh - Why do we need to consider twice-NAT?] Twice NAT mentioned for completeness sake. Expresses desire to move the draft forward for the common case. Scope can be narrowed to accomplish this [Pyda Srisuresh - You need to include bi-directional NAT.] Yes, we will include that. [Pyda Srisuresh - DNS needs to be discussed as well in conjunction with Bi-directional NAT.] Yes. Jeffrey Lo - "RSIP Framework" Brief discussion of how RSIP actually works. Comments? RSIP Protocol o Lightweight negotiation of arbitrary parameters. o Messages and parameter formats allow extensibility beyond the current specification. RSIP Protocol Phases o Registration RSIP server becomes aware of an RSIP client, and assignes a client ID ant tunnel type. o Assignments o Transport [Pyda Srisuresh - Isnt sequence number you use simply a message ID for message request and response correlation?] Yes. [Pyda Srisuresh - Then, simply call it Message-ID, so it is less confusing] [Pyda Srisuresh - Is the framework document discussing protocol issues?] [Michael Borella - the framework document presents the problem that RSIP is trying to solve.] [Pyda Srisuresh - Framework doc should consist only of requirements, scope and applicability. It may be referenced by the protocol document.] [Pyda Srisuresh - A good area to mention in the framework draft is whether applications would be affected, or only the protocol stack.] [Rhandeev Singh - Are you saying that we can do away with the DNS ALG?] [Michael Borella - Not at this time.] o Freeing [Pyda Srisuresh - Is this something that the application does? It is not clear that the stack can do this.] This needs to be studied. [ed- Further discussion and bickering on location of this protocol (stack vs. application), socks, ...] o Renewing o De-registration Messages and Parameters Parameter List Errors More comments? [Pyda Srisuresh - Security Considerations seems to imply that the server should be a traffic cop for traffic generated by RSIP clients. The original intent was for RSIP clients to be able to take part in end-to-end IPsec. The traffic cop defeats this purpose.] More on the mailing list Rhandeev Singh IP relocation through twice network address trnalators Originally presented at mobileip WG Is intended to be a bootstrap for mobileip. NAT is proposed for a quick-fix for initial deployment. RAT and MobileIP Comparision Relocation (Mobile-IP and RAT) Seamless mobility (Mobile IP) [Thomas Narten - What do you mean by this?] RAT doesn't allow you to keep your connections as your address changes. [Steve Bellovin - Why not use tunnel mode IPsec, which provides seamless mobility?] This is not intended as a replacement for MobileIP, but merely to give people experience with mobility Route Optimization (Mobile IP) E2E Layer 3 Security (Mobile IP) Immediate Utility (RAT) Issues o ALG requirements Needed when applications don't work correctly. Free versions of ALGs are encouraged to be shared. o Application Scenarios When is RAT most applicable? o VPN-like connectivity o FIREWALL traversal RAT-to-RAT tunneling across firewalls? [Pyda Srisuresh - Concerns about using RAT for mobileip. Introductory section should be clear on what the advantage/motive is for using RAT.] o PRIVATE home addresses o RSIP enabling [Pyda Srisuresh - What do you mean by a RAT device, and how does it relate to twice-NAT? We need an architectural description of what goes into a RAT device.] Zero-knowledge will register with registration server. Registration server will the send configuration information to the RAT device (Twice NAT box). [Pyda Srisuresh - How does the HA talk with the RAT device?] RAT box will intercept packets from the Correspondent Node and NAT them on their way to the Zero-knowledge Mobile Node. [Pyda Srisuresh - Is the RAT device doing the equivalent job as the Foreign Agent?] It looks more like a Home Agent than a Foreign agent. [Steve Deering - Traffic from Correspondent to Mobile Node undergoes Twice NAT?] Only for Correspondent -> Mobile Node sessions. Sessions in the other direction are not translated at all. [Brian Carpenter - How did the MobileIP group respond to this?] Pretty much ignored. [Hillary Orman - This seems more comparable to IPsec tunnel mode.] Yes, but nobody is shipping it. [Steve Bellovin - Lots of demand and implementations are emerging soon after the IPsec RFCs have come out.] So, we're seeing a lack of support for RAT because IPsec gives us the functionality? [ed- implied general consensus] [Brian Carpenter - Many large coorporations have already rolled out tunneling solutions.] The purpose of RAT/MobileIP is to provide mobility. [George Tsirtsis - This tries to address something between roaming and mobility.] No changes are required to Mobile Nodes. The RAT box instantly provides all functionality even to legacy hosts. [Steve Deering - This seems ironic, as it uses NAT to help outisders to reach a global address.] [Brian Carpenter - Since the time that MobileIP has started, we have given up on having fixed addresses. Too many hosts are forced to use private addresses. Matt Holdrege Other issues? Adjourned