Chairs: Matt Holdrege Pyda Srisuresh suresh@ra.lucent.com Reported by: Ben Rogers Edited by: Matt & Suresh 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 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. Slide presentations: 1. Agenda, milestones & Draft slides - By Suresh 2. DNS_ALG draft description slides - By George Tsirtsis. 3. DNS_ALG draft illustration slides - By Andy Heffernan 4. Implications of NATs on the TCP/IP architecture - By Yakov Rekhter. All of the slides presented during NAT WG, along with meeting minutes are available on-line from the following URL. http://www.livingston.com/tech/ietf/nat Introduction Agenda: - NAT Terminology & Considerations Draft, by Suresh & Matt - NAT Protocol Issues Draft, by Matt & Suresh - Traditional NAT Draft, by Suresh & Kjeld - DNS extensions to NAT Draft, by Suresh, George, Praveen & Andy - Architectural Implications of NAT Draft, by Tony Hain - Implications of NAT on TCP/IP Architecture, by Yakov Rekhter - Miscellaneous Issues ADs have emphasized that the meeting should be run so as to increase participation from the audience. Draft authors should focus on issues raised about their specific drafts rather than the presentations. Pyda Srisuresh - "Nat terminology and Considerations" NAT Terminology draft has gone through considerable review and should be put forward. From a cursory poll, it seems just a few people have read the draft. This needs to be out of the way quickly because it is used in all other drafts. Issues? [None] The chairs stated that without comments, this draft would go to Working Group last call. Per Tony's request, Tony's draft review was moved ahead in the agenda. Tony Hain - "Architectural Implications of NAT" Some people feel this is an anti-NAT draft, but it is not intended to be. It attempts to address the issues and discourage people from randomly using NAT. Ducking the hard issues as out-of-scope is inconsistent with the group charter. Comments? [Pyda Srisuresh - Guidelines are beneficial. Issues with DNS across realms + concerns about fragmenting name space seem to be unfounded.] It is the nature of people to do what they want. A fragmentation of namespace would probably result from this chaotic behavior. [Pyda Srisuresh - Should this be an issue?] This cannot be ignored. We need to warn people to keep away from this sort of behavior. Documents tend to be geared towards a NAT connecting private networks with public networks. We don't have much of an architecture for connecting two private networks. DNS can be an issue here because it likes to work through the public net. [Pyda Srisuresh - NATs will tend to be connected through a VPN type network.] Routing works fine, but DNS resolves don't tend to work without some interaction with the public network. Matt Holdrege - "NAT protocol issues" This is very incomplete at the current time & needs feedback from the community. We need people to come forward with both standard protocols & non-standard protocols (games, multimedia) [George Tsirtsis - Proxy protocols tend to have problems with NAT.] Whether we want to do these things or not, we should document them, so the issues are known to the larger community. Go home, look at the draft and add comments about protocols which have issues. It is preferred that commentators provide specific protocol actions through the NAT device. Please send comments to the list or privately to the authors. Pyda Srisuresh - "Traditional NAT" This has been around for quite some time, but has now been isolated into its own draft. Traditional NAT - External Addresses are valid in private domain, but the reverse is not true. - Permits outbound sessions only from the private domain. (This tends to provide privacy for the private realm.) - Basic NAT * Private to External Address mapping - Network Address Port Translation (NAPT) * Many-to-one Address mapping * TCP/UDP/ICMP transport IDs multiplexed on the resource pool of an assigned address (NAPT is appealing when we don't have enough addresses.) - RFC 1918 recommended private addresses NAT is used so the end-nodes don't have to be aware of routing realms, and can treat all hosts as if they were in the same realm. Packet translations by NAT NAT performs just the header translations, without changing payload. We need ALGs to munge things in the payload. - NAT translates IP header. - NAT translates TCP/UDP headers. - NAT translates ICMP headers & packet headers embedded in ICMP error packets. - NAT does not modify transport payload. - ALGs are needed for protocols which need payload modification. - FTP ALG is used to assist with FTP payload and header translations. NAT considerations - NATs require ALGs to provide transparency for certain applications. (Merely stating that we have a NAT is not good enough. One would need to assess the need for applications on network and select appropriate ALGs to cover them.) - IP addresses are not end-to-end unique. - End-to-end IPsec not attainable with NAT enroute. (Endpoints need to be locatable by their IP addresses as a requirement of IPsec.) - End-to-end Transport level security attainable for certain applications not requiring ALG. - (Since the payload is not modified, we can encrypt the payload without adversely affecting Transport security through a NAT.) - Packet fragmentation could be problematic. (Multiple private nodes sending large packets in fragments. NAT can only identify the fragments by their IP addresses. There is no transport header in fragments after the first fragment.) - NATs can be a target for attack such as SYN flood and ping flood attacks. (This is a direct result of NAT keeping state. A number of packets could be sent to make NAT run out of state storage space. NATs should employ the same protection techniques adapted by Internet servers.) Traditional-NAT limitations - All of the limitations applicable with NATs - Basic NAT is limited by the external addresses available for mapping. - NAPT is limited to TCP/UDP/ICMP based applications. - Typically operates on the borders of the Internet. - Translation of fragmented packets originating from NAPT private domain. [Steve D. - Was the previous slide meant to be a complete list?] No. Full list is in the draft [Steve D. - When address mapping changes, this would cause problems with some protocols over time.] Do you have Specific application in mind? [General property of NAT. This is a change in the normal service model. Often, multiple transport sessions are used in a logical session.] In that case, such an application would need to be tracked by an ALG. [George Tsirtsis - DHCP already does this.] [Daniel Senie - Load sharing might cause problems, such as with nonces.] Load sharing NAT is outside scope. However, there may be some Gaming applications where such a requirement (serial reusability of same address mapping) might exist. [Liam Casey - Voice/Fax over IP H.323 does a register request which is more long standing and you might get called at that address at some later time.] [Radia Perleman - Should we put energy into some aging applications such as FTP?] [Daniel Senie - NAT hasn't been around for too long so the "traditional" moniker is strange. One thing we do is to map one server to a well known port (inside of NAPT). This has yet to be addressed.] Traditional is based on documents we already have. Majority of cases, sessions are outbound. As a special case, you could map specific services to certain private servers. If this is not mentioned in the draft, it should be. Should we move drafts we have discussed so far into next stage? [Daniel Senie - not the issues draft] Okay. This needs help from the WG. We will issue a WG last-call on the mailing list for these drafts. George Tsirtsis - "DNS extensions to NAT" DNS ALG Example Configuration/Terminology Firewall within a private network with some servers between the firewall and a router to external network, in a DMZ. These DMZ servers tend to have global accessibility. We would like to put a NAT router between the DMZ and the public network. Assumes that DNS names for the servers are unique and part of the globally unique DNS tree. Assignment vs Binding - Address assignment * an external address is _reserved_ to be used in place of a private address. - Address binding * an external address is committed to be used in place of a private address. This address will be kept for some time so that sessions may pass based on this DNS record. Address holdout time DNS-ALG DNS payload modifications by DNS-ALG Header - No translation is needed Zone transfers Don't do zone transfers across the DNS-ALG Comments? [Ramen R. - Is address holding concept resistant to denial of service?] The holdout time is meant to ensure that this address is only assigned for a short period of time. Andy Heffernan - "DNS extensions to NAT" DNS lookup sequence Diagram, describing 6 steps involved in the lookup sequence 1. HostA sends request to local Name server, DNSp. 2. Local name server DNSp, sends request to root server, DNSroot. 3. DNSroot refers Local name server DNSp, to remote name server, DNSe. 4. Local Name server DNSp, sends request to Remote Name server DNSe 5. Remote Name server DNSe replies to local Name server DNSp. 6. Local Name server DNSp replies to host HostA. Traditional NAT + DNS-ALG Follow the DNS lookup sequence, on the same diagram, with a (traditional NAT + DNS ALG) box at the edge of private.com domain. 1. Name lookup from A. private.com for X.external.com 2. Reverse name lookup from A. private.com for 171.68.1.1 (Private machine looking up a public address doesn't do anything) Bidirectional NAT + DNS-ALG Follow the DNS lookup sequence, on the same diagram, with a (Bidirectional NAT + DNS ALG) box at the edge of private.com domain. 1. Name lookup from X.external.com for A.private.com. - External Host wants to talk to private host (by assumption, dynamically translated). - A-record (step 5) has the private address for HostA DNS-ALG maps private address to a public address. HostX can then start a session to HostA 2. Reverse name lookup from X.external.com for 131.108.1.1 - DNS-ALG needs to translate request (step 4) before passing onto DNSe. - Possible translation of A-record. PTR needs to be changed as well (step 5) so we can match query with response. Twice NAT + DNS-ALG (1) Follow the DNS lookup sequence, on the same diagram, with a (Twice NAT + DNS ALG) box at the edge of private.com domain. Private network and public network are addressed from the same address space. 1. Name lookup from A.private.com for X.external.com. HostA to start session with HostX - HostA to DNSp - DNSp to DNSroot - DNS-ALG needs to produce an address assignment for DNSe(step 3) - DNSp to DNSe - A-record will need to be processed by DNS-ALG (step 5) - Session can start and bindings can be made 2. Reverse name lookup from A.private.com for 10.1.1.2 (lookup is basically the same.) Twice NAT + DNS-ALG (2) 1. Name lookup from X.external.com for A.private.com 2. Reverse name lookup from X.external.com for 131.108.1.1 This is the same as the bidirectional case. DNS-ALG allows us to do the following: - Outside world can start sessions with dynamically addressed private hosts. - We can now have overlapping domains. Comments? [Tony Hain - What happens if there is a delay and the address HostX gets (and caches) is assigned to a different host.] [George Tsirtsis - 0 TTL is given for all DNS-ALG modified responses.] George Tsirtsis - "DNS extensions to NAT" Discussion DNS-ALG and DNSSEC - The DNS-ALG is modifying DNS payload on transit - Signed DNS responses cannot be altered by DNSALG. How many people have read the draft? [Maybe 10] [??? - DNS request flood?] The timeout is meant to prevent this problem. The attacker can prevent both incoming and outgoing session by soaking up all the addresses with bogus requests. [Still prone to Denial of Service?] Yes. [Eric O. - Change timeout based on how many addresses have been given out?] [Pyda Srisuresh - This doesn't give you much.] We have to grapple with the problem of end-to-end unique names with non-unique addresses. Yakov Rekhter - "Implications of NATs on the TCP/IP architecture" Implications of NAT on TCP/IP Architecture Outline Comments on draft-iab-nat-implications-01.txt draft-ietf-nat-arch-implications-00.txt Last WG meeting - Proposal: take draft-iab-nat-implications-00.txt as input, and revise it to * correct factual errors * remove FUD * clearly separate facts from opinions * provide alternative opinions Comments on draft-iab-nat-implications-01.txt Improvements over the previous version: > NATs and routing realms >> impact on routing scalability >> impacts on Address space consumption > Use of SSL as an option to provide security Comments on draft-iab-nat-implications-01.txt (cont.) Confusion continues > Handling DNS in the presence of NATs >> "mandates multiple name spaces" "hosts would have different names based on inside vs. outside queries" "requires source-specific DNS reply" NOTE: See draft-ietf-nat-dns-alg-00.txt for technical information (reflecting "working code") These statements clearly don't reflect reality. People should look at the above draft before making those types of statements. Comments on draft-iab-nat-implications-01.txt (cont.) Confusion continues > Use of RFC1918 addressed by VPNs >> "VPNs.. increase the likelihood od address collision when traversing NATs" >> Failed to understand that address collision is an implication of using RFC1918 addresses, not an implication of using NATs. >> Failed to explain that NAT is an enabling technology for merging internets that use RFC1918 addresses. Problems with address space collisions caused by merging privately addressed networks. Comments on draft-iab-nat-implications-01.txt (cont.) Anti-NAT rhetoric continues > "necessary evil" > "weed which is destined to choke out continued development" > "equivalent to digging a hole" > "The single greatest threat to a secure Internet" > "NAts are a diversion from forward motion" draft-ietf-nat-arch-00.txt Focus on architectural implications to the TCP/IP architecture We should broaden the focus to look at TCP/IP as a whole. - Identifies open technical issues - Focus on facts, not on opinions. - More technical substance, less passions/emotions. Discuss implications on various components of the TCP/IP architecture. - Implications on routing and addressing. - Implications on DNS. - Implications on transport layer. - Implications on applications. - Implications on security. - Implications on performance. - End-to-end address preservation. Identify open issues - Interconnecting routing realms in an arbitrary (mesh) topology (instead of a CIDR tree format) - Implications on DNS in the presence of DNS security and DNS dynamic updates. - Carrying IP addresses in the application data stream - Is that a good architecture? - End-to-end address preservation - should this be revisited? - (It is probably outside the scope of this WG.) What is next? - Solicit comments on draft-ietf-nat-arch-00.txt - Revise based on the comments received. - Publish as an informational RFC - Comments? [Tony Hain - If you want to address NATs, then there is nothing which is outside the scope. It seems that only the negative opinion comments were quoted in this presentation.] [Steve D. - Aesthetic judgments are an inherent part of architecture. Taking opinions out of documents is not necessarily valid.] Make a document of opinions? [???? - SSL doesn't help if address is in payload.] [Steve Bellovin - Addresses in FTP data stream are needed to setup the data channel. Setup of this type of external data stream cannot be done without addresses. At some point, you have to make a decision about the best way to do things. IPsec is probably close to the correct way to handle this. NAT is a serious problem for this.] You can make a value judgment, but this gets in the way of facts. [Engineering is about making tradeoffs, and the tradeoff here is between security and NAT.] The tradeoffs should be made clear to the customers who can make their own decisions. [Architecture tends to suffer from this.] [Steve D. - Questions about whether something is a good architecture is inherently asking for a value judgment.] The document only brings up the issue. It doesn't say whether this is good or bad. [Tony Hain - We can't stand up and ask whether this is a good architecture and then state that it is outside the scope of the WG.] This issue is broader than NAT. [If this WG doesn't address the problem, then why are we making it worse.] [Pyda Srisuresh - Words such as "NATs are evil" are not appropriate for expressing an opinion.] [Bob Moskovitz - If a WG is making a technological kludge and makes the architecture more difficult than an administrator could manage, then shouldn't we do work to address this complexity. It would be nice if we could simplify our work by using the results of other WGs (such as address space conservation).] [Matt Holdrege - We didn't invent NAT, but are merely documenting it.] [Vern Paxson - Comments about how the architecture might be revised would certainly be within the scope of informational documents, if done in an even-handed manner.] [Ross Callon - Perhaps it is helpful to get addresses out of applications. They cause problems for NAT, and would be a good move to help the migration towards IPv6. There is usually no benefit of keeping the addresses in applications.] [Tony Hain - The problem is the collision of address space. NATs tend to aggravate this problem by making use of the private address spaces more frequently.] suresh - "WG Goals and Milestones" Below are the goals for the WG. While we are on-track so far (Aug'98), we are looking for people to start work on the remaining drafts: Aug98 - What is NAT & NAT terminology draft - Applicability of NATs - Draft on Basic NAT and NAPT - NAT limitations & known problematic protocols Dec98 - NAT friendly application design guidelines draft - Multi-homed NAT applications draft - Security implications of NAT Apr99 - Interaction of NATs with IP switching, DNS, roaming IP, mobile IP, IP multicast, SOCKS, - Integrated services, RSVP etc. Aug99 - MIB for NATs [Shinwe Yeow - Any comments on NAT for IP mobility draft.] [suresh - I will review the draft and send my comments.]