Behave Working Group Minutes IETF 73, Minneapolis, 16-21 November 2008 Jabber : behave@jabber.ietf.org Audiocast: http://videolab.uoregon.edu/events/ietf/ Chairs : Dave Thaler Dan Wing SESSION ONE WEDNESDAY, 09:00-10:15 ====================================================================== Note takers: Bruce Lowekamp, Ed Jankiewicz Jabber scribe: TJ Evans Agenda, new charter, milestones - Chairs ---------------------------------------- Dan reviewed agendas, showed note well slide Updated charter: * Added work on 4 scenarios for address family translation * January - settle on priority * March - choose specific documents to advance Milestones: SCTP and TURN on track (with slip on TURN) Doc status: 4 in IESG, 2 in WGLC, 1 new adopt as WG doc (turn-uri) Arifumi: Is 464 in scope? A: 46 is in scope and 64 is in scope Q from chairs: can we adopt behave-turn-uri? no opposition to adoption Adam Roach: can we take affirmative hum to adopt? Chairs: affirmative hum? Weak hum in favor of adoption Presented behavior-discovery slide Some discussion of source port selection (randomization) -06 submission is waiting on any more feedback to discussion on list Interim in January in Malta: * Need a minimum for hotel breakeven * Trying to provide remote attendance The chairs polled the room to determine how many people would participate in an interim meeting in Malta. Number planning to attend: 6 Number interested in remote participation: 30-ish TURN - Jonathan Rosenberg ------------------------- Draft: http://tools.ietf.org/html/draft-ietf-behave-turn Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-3.pdf In WGLC, two revisions since Dublin; change log in doc or slides DONT-FRAGMENT attribute in Send indication or Allocate request Q on slide 7/8 from Cullen Jennings: why is the server allowed to restrict addresses and ports? Philip responding via jabber, then moving to email Adam Roach: who plans to implement? at least two hands TURN server names - Lars states IANA can allocate a service name without a new port number Question on whether we need a new port? Lars Eggert: can't now, but will be able to from IANA soon Philip Matthews: went to same port when channels introduced EKR and Cullen: just run on same port Cullen and Lars: believe they can do that without the new draft though Issue 2: TURN loop attack (see pictures) Attacker allocates a transport address on TURN server A, spoofing Server B address. Ditto B spoofing A. This attack requires either seeing the server's responses or guessing the next port number. ChannelBind to both, then sending a message triggers a loop. A lengthy discussion ensued. This is hard to defend against. One possibility is a bandwidth limitation. The proposed solution is to document the attack and recommend servers decrement TTL if at all possible. No objections to proposed solution. TURN-TCP - Jonathan Rosenberg, 20) ---------------------------------- Draft: http://tools.ietf.org/html/draft-ietf-behave-turn-tcp Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-2.pdf Has been on back burner for a while. Starvation issue - exceeding bottleneck Alternative solution Adam Roach: SSH tunneling would work discussion of whether to adopt proposed ftp-like parallel connections, socks solution (unclear what that is), or ssh (share over single connection) very lengthy discussion Any support/objection? Small contingent of support and no strong objection to continuing on this line. Hence rough consensus that this looks like a reasonable approach. SCTP - Michael Tuexen --------------------- Draft: http://tools.ietf.org/html/draft-ietf-behave-sctpnat Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-1.pdf WG document SCTP common header includes a verification tag, random number chosen at setup NAT-NAPT for SCTP uses the verification tag to identify the association Good randomization is assumed, but collision handled Magnus & Remi D: terminology doesn't agree with current use Remi D-C: existing NATs may try to forward, translating IP address only. Does the client need to be ready to handle this case? answer? vtags won't match with two internal clients Brian: vtag mapping good, but... James Woodyatt: ICMP and encapsulated security, have something other than source port to identify. Verification tag is not new or crazy. Conversation evolves to question of whether this prohibits endpoint- independent mapping so inbound connections work Jonathan Lennox: no endpoint independent mapping? Michael: unclear on response, explained in draft, tested Lars: in case NAT vendors are looking to SCTP support; enables the option Dave Thaler: please address hairpinning There are implementations including Linux and FreeBSD? SESSION TWO THURSDAY, 09:00-11:30 ============================================================================ Note takers: Chris Metz, Ed Jankiewicz Jabber scribe: TJ Evans Agenda, new charter, milestones - Chairs ---------------------------------------- Dan reviewed the agenda and revised BEHAVE WG charter which now includes IPv4- IPv6 translation. Chairs asked about potential Malta Interim Meeting attendance, in addition to anyone who responded Wednesday. Results: 8 would attend in person; ~30 would attend remotely. 2 mentioned they bought non-refundable plane tickets. With Wednesday’s numbers, this brought the total so far to 14 physical and ~60 virtual. Randy asked if a small number was a bad thing. Dave responded that more were interested in attending remotely given 4:1 ratio of virtual-to-physical attendance preference. Framework - Fred Baker ---------------------- Draft: http://tools.ietf.org/html/draft-baker-behave-v4v6-framework Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-5.pdf Fred stated transition to IPv6 required a piecemeal/stepwise technology. The Montreal interim consensus was to work on translation technology with basis formed in the framework, SIIT update, NAT64 and DNS64 drafts. Other documents describing additional functions like ALG might be needed. Fred described the basic address translation scenario with IPv4 packets being translated into IPv6 and vice-versa. He also pointed out that the old way of NAT-PT had the DNS rewrite (dns) and Translator (xlate) in the same system; new way says dns and xlate in separate systems. Terminology including stateless vs. stateful and IPv4-mapped vs. unmapped addresses was defined. Iljitsch: Is state per-client or per-server? Fred: Per-Host A diagram was presented describing IPv4/IPv6 translation solution as a temporary co-existence tool that includes the different connectivity scenarios (4-4, 6-6, 1:N IPv6->IPv4 (unmapped) and 1:1 IPv6<-IPv4 (mapped). There is experience with this such as CERNET2 with IVI over the last 2 years and various NAT-PT implementations. Charles Perkins: How long is temporary? Fred: Not permanent. A slide on the IPv4-mapped IPv6 address chosen for use in translation was discusssed. A network-administered prefix is preferred and the embedded IPv4 address can be placed in different portions of the 128-bit IPv6 address range. Regarding the prefix, Fred noted that all zeroes or a well-known prefix could lead to routing problems (e.g., separate IPv4 net 10 networks connected to common IPv6 network are both addressed using [well-known prefix] + net 10). Fred also mentioned this type of address was partially deprecated in RFC4291. Dave Thaler agreed that something other than well-known was preferred but that IPv4-mapped addresses were NOT deprecated. IPv4-compatible addresses were deprecated, but they weren't used by NAT-PT. There is no relationship between deprecating NAT-PT and deprecation of any address range. Fred then discussed 3 x ISP Usage Cases. The first one is designed for large scale connecting of IPv6 and IPv4 hosts thru a CGN-type box. IPv4-mapped IPv6 address with IPv4 prefix positioned in bits 40-72 would be used to address local IPv6 servers using stateless translation from IPv4-only clients. CERNET2 using IVI has been supporting this model. The second case involved dual-stack networks surrounding an IPv6-only network. This would be targeted at residential/smb customers. Address format is /96 ISP prefix plus remaining 32-bits holding IPv4. It does not support the IPv4- client to IPv6-server case. The third case is a stub network with IPv4-only hosts connected to IPv6-only network or other hosts. Address format is /96 prefix plus 32-bit IPv4 address. Fred described routing advertisements generated by xlate. On the IPv6 side, xlate advertises an IPv6 prefix for the entire IPv4 space which will attract IPv4-bound traffic. On the IPv4 side, xlate advertises an IPv4 prefix for stateless translation in ISP case #1 case. Fred showed a slide on 1:N translation (let IPv6-only hosts with general format addresses access IPv4-only servers/peers) noting that IPv4 access to general IPv6 hosts was excluded due to complexity. Charles Perkins: 2nd bullet (ref: IPv4 access to general IPv6 hosts) makes IPv6 hosts 2nd class citizens. Why take the IPv6 host access to IPv4 off the table? Is this a permanent constraint? Fred: Not primary focus at the moment but not off the table Charles Perkins: Big $$ for multi-player gaming between 4 and 6. Need a draft here. Fred: technology has a lifetime Charles: I would say 10-15 years Fred: Don't agree Ed Jankiewicz: There is a time value to the various scenarios. Fred: We will need SP and enterprise IPv6 to consider. Anonymous: You say host is dual-stack but does this involve any 4 thru 6 tunneling? Fred: No, this is dual-stack, no tunneling. Jari Arkko: Let's hope we can agree to do simple things first, more complicated later. Fred showed slide on DNS function. It can support client-server and P2P flows, simplest case is static configuration and it can do dynamic A<->AAAA translations on the fly. Allows devices in IPv4 domain to be accessible to IPv6, and a subset of IPv6 accessible to IPv4. Marcelo: Asked for clarification on A-AAAA translation. A<>AAAA both ways? Fred: Possible, not required in every solution. We have opportunity to address different ways. We could do rewrite per DYNDNS update or do it during each setup. Iljitsch: Regarding address formats, what does IETF need to do here? Marcelo: This is important issue but I don't have an opinion. Fred: I'll defer to the chairs Chairs: There is no draft on address formats, so let's prepare a draft and discuss at next IETF meeting. Fred: Lots of drafts already written and we included a write-up in framework draft appendix Eric Nordmark: (domain to domain picture) are these administrative domains or more complex? Fred: Cernet2 is a different network under a common admin with each campus possessing DNS sub-domains. Randy Bush: I am not very happy. My customers are big enterprises with no more IPv4. Let's get this out the door. IP/ICMP Translation Algorithm - Fred Baker ------------------------------------------ Draft: http://tools.ietf.org/html/draft-baker-behave-v4v6-translation-00 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-6.pdf Fred described this new draft as an update to RFC2765. Some detail was devoted to explaining 4->6 translation for stateless (based on algorithm) and stateful (lookup done on mapping table inside xlate) translation. Xlate should know when to translate by knowing IPv4 address range (representing IPv6 hosts with IPv4-mapped IPv6 addresses) and when to just forward (if more specific IPv4 DA arrives). There are some issues like fragmentation. The 6->4 translation scenario was covered in equal detail. Interactions with RFC3484 Host Behavior should be unchanged but hosts should select source and destination addresses of the same type. Erik Nordmark: In stateless mode is the translation checksum neutral? Fred: Need to work details on that one. Erik: You will need 16 bits. Dave Thaler: I believe the framework draft is informational and this SIIT draft is prescriptive/descriptive. Comment from jabber says that SIIT should not specify address format. Fred: We can break this into two parts. Ed Jankiewicz: Is SIIT a solution or foundational to all solutions? Fred: Applicable to all solutions. Rob Austein: Been about 10 years since I did NAT-PT, but it can't be checksum neutral due to UDP. Fred: We have not gotten to that yet. NAT64 - Marcelo Bagnulo ----------------------- Draft: http://tools.ietf.org/html/draft-bagnulo-behave-nat64-02 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-8.pdf Marcelo described basic application scenario of an IPv6 host connecting to an IPv4 server on the other side of a NAT64 box. He outlined the differences of this draft vs. RFC2766 and how this document (defines how mappings are created in NAT64 box) is related to the other documents (SIIT specifies translation, DNS64 document describes DNS functions and framework wraps it all up into one). Marcelo showed detailed flow noting that no state is created in NAT64 box until the first data packet arrives. This is similar to NAT44 behavior. Only relationship between NAT64 and DNS64 entity is that latter knows the former's IPv6 prefix. Dave Thaler remarked that, unlike NAT-PT, NAT64 has no dependency on DNS64. Other mechanisms for an IPv6 host obtaining IPv4-mapped IPv6 addresses representing IPv4 servers are not precluded. Remi: Distinction between SCTP single- and multi-homed flows thru NAT64? Marcelo: Don't know, have not thought about it. Magnus: if end-host can reach multiple translators Problem here is that path of first packet sent from SCTP multihomed host is not predictable. Remi: need a protocol between boxes Iljitsch: SCTP and DCCP are not widely deployed, SCTP is complex, maybe we don't need that scenario in the first go-around. IPsec is in wide-use but one side would need to be aware of that. Marcelo then posed the general question to the WG: Should we include all protocols (TCP, UDP, DCCP, etc.) in base spec or just include TCP/UDP in base spec and address others in separate documents? This generated much discussion. Iljitsch suggested the SCTP NAT64 work could be done in the same document as SCTP NAT44. One concern expressed was that including just TCP/UDP in the baseline document would make other protocols covered in additional documents optional. Dave attempted to clarify the question down to one document including all vs. multiple documents. Several comments followed regarding general process. Cullen pointed out that one document means implementation become mandatory for all. Dave responded by stating that implementation being mandatory is orthogonal to discussion of one or more documents. Sheila chimed in that she would have no objections to separate docs as long as original/baseline does not preclude other protocols (especially IPsec). Margaret stated this boiled down to three things: 1) document organization question, 2) compliance matrix, 3) timing of documents being published. Gregory Lebovitz pointed out that customers need this, vendors will be implementing so fear of RFC compliance is not rationale. Dave asked for hums in favor of baseline NAT64 for just TCP/UDP, with any others in separate docs. Response: hums for and no objection Margaret: consensus as separate docs; what about linked publication? Ilytsch: what if the other docs don't progress? That would hold this one up Gregory: practical - there are customers needing this solution now, vendors will provide regardless. As we get close, and vendors confident that this will be published, vendors will proceed. Dave: fast path to base spec is a good idea Dave asked for hums on 1) publish separate docs concurrently or 2) progress and publish documents separately. Response: Hums for both but, 2) progress/publish separately, had more hums. Jari Arkko: IPsec is important, we need to get this done. Dave asked whether this should become a WG document, and the chairs conferred and suggested the WG discuss on the list (for all IPv4<->IPv6 translation related documents, not just this one). Marcelo then brought up the question of end-point independence. Magnus stated we need end-point independence in the baseline mode. Remi suggested it was important for the 6-4 and 4-4 cases. Dan Wing suggested we could discuss during LSN (CGN) talk. Cullen: confused - mappings or filtering? If we don't have end-point independent mappings, NAT traversal breaks. there is already a BCP for endpoint independence in the NAT44 cases. Fred was concerned that 6 side is private and 4 side is public. Marcelo: end-point independence is defined for private and public in the NAT44 cases, but NAT64 might do something different. Iljitsch: at least one NAT needs to be end-point independent. In NAT64 we can afford not being end-point independent because the NAT44 are; do we NEED to forgo end-point independence? Christian: as we run out of IPv4 addresses, requiring end-point independence becomes more problematic. Alain: need to start with endpoint independence; next critical resource is number of ports; don't completely close the door, but what does it mean to not have end-point independence? Dan: at the next IETF we will have a discussion on drafts on end-point independence DNS64 - Marcelo Bagnulo ----------------------- Draft: http://tools.ietf.org/html/draft-bagnulo-behave-dns64-01 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-9.pdf Basic NAT64 with DNS64 element application scenario outlined. DNS64 can be in the local nameserver which simplified deployment on legacy hosts or it can be located in the host itself. A more detailed application flow example was explained. Question on tagging synthetic AAAA RR since depending on the topology, different non-authoritative servers may produce different results. Initial feedback from the DNSext WG was that it can be done but it is not needed from a DNS perspective. Alain: as long as the mapping prefix is known locally; changes the problem to how to transmit the information about prefixes. Assuming a number of moving parts. Rob Austein: Might need to tag for DNSsec case in a manner similar to DNAME synthesis. The slides illustrate several design questions and proposed behaviors surrounding DNSsec handling. Andrew Sullivan: if we do it using DNSsec way, then you do it all the time. Marcelo: We need to write down the details in a future revision. Large Scale NATs, NAT444 - Akira Nakagawa ----------------------------------------- Drafts: http://tools.ietf.org/html/draft-nishitani-cgn-01 http://tools.ietf.org/html/draft-shirasaki-nat444-isp-shared-addr-00 Slides: http://www.ietf.org/proceedings/08nov/slides/behave-7.pdf Akira reviewed the draft name change from "carrier-grade NAT" to "large scale NAT" reflecting that this function might find its way into carriers, ISPs and large enterprises. He also reviewed the new draft structure and its association with the NAT444 and ISP Shared Address documents. Akira summarized the general requirements for LSN including transparency, CPE fairness (ports per sub), connectivity (hairpinning, hole-punching), logging, and traceback. An LSN supporting the NAT444 model was described along with an ISP shared address used to address the private IPv4 network between the customer CPE and the provider-operated LSN. In addition the LSN is can support the DS-lite (tunneling model). Tatuya Jinmei asked if the intent is to extend the lifetime of IPv4. Akira answered that this is not the intent of the LSN draft. Someone also commented that these documents do not support the A+P cases. Port Range - Gabor Bajko, Randy Bush, Remi Despres, Pierre Levis, Olaf Maennel, Teemu Savolainen ----------------------------------------------------------------- Drafts: http://tools.ietf.org/html/ draft-bajko-v6ops-port-restricted-ipaddr-assign-02 http://tools.ietf.org/html/draft-boucadair-port-range-00 http://tools.ietf.org/html/draft-boucadair-dhc-port-range-01 http://tools.ietf.org/html/draft-ymbk-aplusp-01 http://tools.ietf.org/html/draft-despres-sam-01 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-4.pdf Randy began the tag team presentation by pointing out the IPv4 run-out problem and that a CGN breaks the Internet and produces walled gardens. Idea is to move NAT to CPE and maintain incremental deployability, e2e customer control, e2e transparency and scalable/stateless core network. Gabor Bajko discussed port-restricted IP address solution targeted for tightly controlled networks with pt-pt links and no NATs. An upstream gateway would perform IP + port forwarding into a tunnel. A host/CPE uses DHCP to request IPv4 address plus a port range (beginning/ending values). A host could implement a NAT if necessary. Next up was a discussion of the Boucadair Port Range drafts. Solution is BB residential CPE and ISP CPE. Incoming packet from the Internet are forwarded by Port-Range Router (PRR) that must have route to each CPE. Inter-CPE traffic is hairpinned thru PRR. DHCP servers must be extended to hand out port ranges or PRR can have DHCP proxy to distribute port range down to CPEs. Port range is a value with mask which brings added flexibility and is easier to compute. A comment was made that these solutions are destroying port randomization. Next up was A+P draft discussion (Draft YMBK). A+P Gateway has private IPv4 and NAT44 on one side (customer), IPv6 on the other side (upstream) and it does port restricted IPv4 forwarding thru an IPv6 tunnel up to border router to maintain end-to-end IPv4 connectivity. Gregory: Problem is that CPE cannot be changed Randy/Olaf: We assume CPE can be incrementally updated Remi Despres concluded the port range presentations with a brief discussion of SAM and then 3 slides offering a useful comparison between the multiple approaches. Alain: Would like to see these efforts merge concerned about unintended consequences related to routing (this seems to result in injecting all IPv4 routes into IPv6), provisioning (cookie-cutter approach), etc. Charles: concern about using ports to do 4-6 connectivity. Is there a non-port solution? Remi: These are not 4-6 solutions but rather restore e2e IPv4 connectivity Jonathan: Proposals don't work with non-port protocols like IPsec and SCTP Remi: IPsec can run over UDP but if not go to IPv6 Randy mentioned that "exploding table" comment can be addressed. Steve Bellovin proposal re IPsec; if encap at CPE want to find the optimal exit border router, optimal exit IPv4 address. Alain and A+P folks meeting and finding similar signaling and action semantics. Where things happen are different. Converging in interesting ways. This presentation was meant to illustrate the dimensionality, not to advocate one solution over the others. Woj: What about ICMP? Remi: Can be supported and will add reference James: Concern that these port range solutions defeat port randomization and thus becomes a security exposure. Dave: What is common to all port range drafts is that things that don't use ports don't work as currently specified. Dave: There are three possible use cases: 1) You give a port-range-restricted IP address to a NAT (NAT44 or NAT64). The NAT is a constrained function device. This is probably OK. 2) You give a port-range-restricted IP address to a constrained function host, like a closed cell phone platform. This is probably OK. 3) You give a port-range-restricted IP address to a general purpose host, like a PC. This breaks a bunch of stuff. SESSION THREE FRIDAY, 13:00-15:15 ====================================================================== Note takers: Hemant Singh Jabber scribe: TJ Evans Agenda, new charter, milestones - Chairs ---------------------------------------- Dan Wing already left, so Magnus co-chairing meeting with Dave 1. Malta interim meeting is cancelled. 2. Maybe still have a small interim meeting somewhere else than Malta. UDP Path MTU Discovery using STUN - Marc Petit-Huguenin ------------------------------------------------------- Draft: http://tools.ietf.org/html/draft-petithuguenin-behave-stun-pmtud-02 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-10.pdf Remi-Denis: Can't use Path MTU for SIP because SIP has no endpoint? This is correct. Can't use Path MTU for TFTP in TURN because TURN restricts packet size to 576 or something in that ball park. Presenter gave some history on various earlier Path MTU schemes. RFC 4821 - this draft is not a new PMTUD method Send Probe - DF bit, bigger than current PMTU How to apply the result processing in 4821 UDP cannot identify the packet that was sent; add mechanism to detect 1. simple - STUN transaction with timeout 2. complete - 1 probe as STUN indication looking for a better solution to reporting Checksum variant - report of time sequenced checksums Header variant - look like TURN channelDetect Discovery - server must be capable of receiving keep-alive Bruce L.: Is there an issue with padding used by this draft? It references padding (experimental) not the experimental use of behavior discovery. Bruce supports the draft. Magnus: should be no problem down-referencing Polled for interest in accepting - more hmm's for yay, but no strong opinion. Not accepted as WG work item yet. NAT security implications - Fernando Gont ---------------------------------------- Draft: http://tools.ietf.org/html/draft-gont-behave-nat-security Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-12.pdf Security related to NAT traversal. DNS attack method guesses source port. NAT de-randomized source ports. Security implications of NAT rewriting or NOT rewriting; at least do it the right way. Recognize reality of NAT and make better. NOT rewriting leads to interoperability problems, doing it WRONG increases attack vector easier for attacker to guess or predict. Stuart Cheshire: Why you need to rewrite the seq #'s or timestamps? Fernando: TCP needs sequential #'s. Timestamps are looked at during receiving syncs. FreeBSD 2004 problems with systems randomizing sequence number. Ditto for timestamps. Bruce L: expecting the NAT to make up for the failure of the TCP stack? David: If three are multiple machines behind the NAT - they all look like one machine. If the machines behind the NAT are all doing the right thing, but their traffic is interspersed, the timestamps get mixed up. If the another machine gets the same ports Eric Rescorla: NATs should not be reassigning ports too soon. Instead of rewriting TCP timestamps, NAT should use WAIT for use of a source port. Iljitch: Only the same port to the same destination is a problem. If port is reused, reuse for another destination address. Don't mess with timestamp and sequence number. Margaret: Agrees with Eric and Iljitch. If this causes a problem that only 65K ports can be opened but note you would use another IP address or two. A sophisticated box with a lot of hosts probably needs more than one IP address. Reusing the same port number and address connecting to the same destination is not correct behavior. You have to keep state for timewait. Can't break TCP integrity by reusing, the other side may still think the connection is open. Mark Townsley has specific evidence on an implementation with wrong sequence number rewrite, caused retransmission. Wait timeout the ports; 64K is key issue for CGN. Adam Roach: How do you not keep state with monotonically increasing sequence #'s? Fernando: hash with a secret key. See RFC 1948 that gives an algorithm to do so without keeping state. Same RFC algorithm for timestamps. Rewriting source port; 5382 unspecified. Randomize except when doing port preservation Lots of feedback Rewriting TTL may break traceroute Lars: What is the purpose behind rewriting TTL? Has stronger security for NAT than even a firewall. Fernando: leaking information Eric: anonymizer Gorry: Ok with rewriting TTL but it's stupid, don't rewrite it as 255 because some protocols use the value. Illjitch: please note, can decrease TTL if rewrite, but not increase. Tony Hain: He supports this draft because it forces people to move to IPv6 :-) Take up on the list in few weeks once next version of draft is posted and then go from there for acceptance as a WG item. NAT66 - Margaret Wasserman -------------------------- Draft: http://tools.ietf.org/html/draft-mrw-behave-nat66 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-14.pdf No per-connection state in ISP, less problematic than IPv4 NA(P)T. Motivational facts: enterprise network operators are asking for it, vendors are meeting the request, it's already out there and cannot be prevented. Possible response to the facts: do nothing, maintain silence, end up with NATs based on v4 NATs or variations or document a good IPv6 NAT mechanism: consistent, less negatives, e.g. NAT66 Gregory: It's not an opinion yet - is there is 3rd option - we explicitly write a document that we don't do it. RFC4864. Yes, we have such a doc. Remi: It's not a new design. IIjitch: Don't do it. Dont pay attention; build our protocols such that they work without NATs. We should say don't waste your time on NATs, and we wont do anything to help you. In IPv6, you don't need it to fix address issues. The draft tries to strike a balance - calls out alternatives (RFC 4864). There are some needs that are not well-covered yet, so some may use NATs, so here's what to look out for. Three scenarios in the draft Two mechanisms - two-way algorithmic and Topology hiding There is a better suggestion for topology hiding, the version in draft is broken as pointed out by Tony Hain. Two-way algorithmic - overwrite source address prefix and adjust the checksum Just need to know the mapped prefixes Topology Hiding mechanism Prefix is mapped, subnet and part of IID encrypted, checksum correction in low order bits Doesn't muck up IPsec or transport layer Still changes the IP address en route, still problem for apps and security mechanisms relying on immutability Open Issues heard on the list The Name Game - highlight the difference, we don't really have NAT in IPv6 Christian Vogt: Why not call it as a prefix translator instead of NAT66? Hairpinning - yes, it should be covered here What are topology hiding requirements? Others dont know either ULA addresses behind the NAT? default, but Dave T says it changes the semantics of ULA. Motivations/applicability From Fred, customers say topology hiding is important. Cisco IT example where Cisco has about 200 partner companies that need to access data from Cisco and vice versa. Set up a mutual NAT only a small number of systems can talk through. See draft-baker-v6ops-b2b-private-routing. Gregory: Both sides use 1918 space and that is why they use Mutual NAT. Were you describing a different issue? Is access control (firewalling) collocated with the mutual NAT routers? Fred: Yes, only advertise a small amount of routing. Eric: What is the idea behind the NATs? What space is getting translated? Is the idea that Company A maps onto your network? Tony: Inside the Cisco network, the external company looks like it is inside but at the edge. Eric Kline: Why would this not work without NAT66? Wouldn't more specific routes and public addresses solve the problem? Gregory: If I have all globally routable space, I give them an address that they can attack. Scaling the Internet and multihoming. Prefixes are distributed around the periphery Provider Independent (PI) multihoming does not allow routing to scale PA multihoming RFC 3582 IETF proposed SHIM6 to scale prefixes - but shim6 had other issues. GSE or 8+8 (to be draft) Gregory: forces prefix aggregation; same number of addresses but less routes Route optimization in Multihoming Different return route results in a different address on SYN-ACK Iljitsch: just rewrite the address back Fred: symmetric NAT Remaining real issues The uniformed confuse NAT with security Margaret: should we work on this, if so why/not? Christian: not standardizing does not prevent use; we can only make things better by standardizing; analysis on mailing list: reachability, robustness, mutable in route. In NAT66 reachability and robustness are solved; most applications have to deal with mutability of IP address. Tony Hain: let's do better; having NATs doesnt make things better. Pop it up and redefine what doing better means? Better network without address mangling. No problem defining a NAT if there is a real need there are other ways of doing topology hiding. Are we creating more problems by attacking GSE, somebody has to know the mapping, if not DNS, then who? Fred: LISP makes GSE look good Tony: depends on your point of view what looks/is better. Is this helping? See mail. I dont think we need this. Gregory: Two issues - NAT and reachability but still not reachable because of firewall. Keep in mind that reachability in IPv4 is a problem because port mapping, access control will not go away. Application level proxies, IPS, firewalling will all still be there. Margaret: you can build those things configurable Gregory: symmetric NAT still broken by a stateful firewall. Keep both sources of reachability problems in mind. In the real world, the firewall keeps state. We have a real problem but this addresses half Merike Cao: Reference to infrastructure hiding draft in operational security WG, discusses how ISPs are doing infrastructure hiding. Will send pointer to mailing list. Remi Despres: how can you do a 1:1 mapping, while reserving 16 bits for checksum adjustment? See the draft. Remi D-C: must define it well, cannot be misquoted or misused Jari: confirm the motivational facts; even if things happen despite the IETF, this can have a significant impact on what will happen. How we phrase and market this is important. I don't believe in the topology hiding argument. Steve: don't touch the lower 64 bits Iljitsch: interesting Gregory said about firewall. In IPv4 we don't try to work through firewalls. In IPv6 we could say NAT66 is like a firewall. Bob Hinden: NAT66 is less evil than what we have today, the address manipulation is cool. Side-effect of giving everyone a /48 is good. GSE terrifies me. Michael Dell calls the location-ID split an urban myth of the Internet. Margaret: Fred's slides are not in the doc, but is an application of the doc; we have to understand why people want to buy NAT. Mark Townsley: renumbering is handy with NAT66. It's somewhat inevitable. Avoiding renumbering is not in the doc. Magic mapping won't work with renumbering; NAT66 works with PA. There's a dramatic differences between this and the IPv4 doc, GSE work loosely fits in RRG right now, we're already working on this! Margaret observed that there was no no consensus yet. Is it worthwhile for Margaret to continue to work on the doc? Dave T asked the audience whether Margaret should give up or continue. Over 30 would like to see another draft, about 3 wanted to drop. Lars: NAT66 is not urgent. Focus more on v4v6 coexistence. Mark T and Sam: NAT66 is an analog to what is going on with NAT46, NAT64, etc and it is a good design point to build together. Dave T: when we do NAT64 consider the implications, and next stage being UNSAF considerations. Jari: should also focus on scope. Should not be very large. Randy Bush: keep your enemies close :-) Virtual IPv6 Connectivity for IPv4-only networks - Christian Vogt ----------------------------------------------------------------- Draft: http://tools.ietf.org/html/draft-vogt-durand-virtual-ip6-connectivity Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-13.pdf Filling the IPv6 transition toolbox. Currently the onus is on the IPv6 side due to the preponderance of IPv4. Dual-stack and translation (NAT64) to get v6 onto v4 infrastructure - need global IPv4 addresses Over time the incentive shrinks, and less IPv4 addresses available Also IPv4 side impetus grow as more IPv6 available Growing need for a v4-facing translation The virtual addresses on v4 side are private and ephemeral local, no global IPv4 needed Virtual v6 addresses are global and stable Dave: This looks just like NAT64 Christian: types of addresses are different, deployment model is different, some different security implications. For an inbound connection, the IPv6 host looks up the virtual IPv6 address for the IPv4 host in DNS which is statically defined. The router then creates a local virtual IPv4 address for the IPv6 host. For an outbound connection, the IPv4 host queries DNS, triggers the mapping, private v4 address returned in the reply. Eventually the impetus moves to the IPv4 side Should this be in the toolbox? Dave Thaler: It seems that the main unique thing here is NAT46 support (i.e., support for the "an IPv4 network to IPv6 Internet" scenario. The rest seems to be the same as the other items discussed yesterday. IPv6 destination header option - Remi Denis-Courmont ---------------------------------------------------- Draft: http://tools.ietf.org/html/draft-denis-behave-v4v6exthdr Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-11.pdf Small extension header is used to transmit IPv4 mapping info. use Destination Header or generic IPv6 Extension Header? What about Nested NATs (NAT64, NAT46)? TCP header inserted for SYN and SYN/ACK. What about UDP, UDP-lite? Always? First few packets? Should this go forward? If so what is the scope? Dave T: need more discussion on the list On-demand privacy protection - Remi Despres ------------------------------------------- Draft: http://tools.ietf.org/html/draft-despres-sam#section-3.6 Slides: http://www3.ietf.org/proceedings/08nov/slides/behave-15.pdf SAM does address and port scrambling. Issue with multihomed sites is how to distribute key used for scrambling (must be the same) and how to update when needed. DaveT: folks should consider this along with the rest of the NAT66 discussion, unique thing here is to only perform upon request of application.