----------------------------------------------------------------------- SHARA BOF Minutes MONDAY, March 23, 2009 0900-1130 Morning Session I ----------------------------------------------------------------------- Issues with addressing sharing approaches, M. Ford & P. Levis http://tools.ietf.org/html/draft-ford-shared-addressing-issues http://tools.ietf.org/html/draft-levis-behave-ipv4-shortage-framework M. Ford presenting. What breaks? inbound communicatinos, ports & addresses in payloads, well-known ports.... Port distribution: How many ports is enough? Active subscribers use 80 - 160 ports at time.... Broadcast/multicast: answer: don't know Port distribution: are port-ranges uniformly sized? If there is no upper limit we enable DoS... Impact on well-known ports: who is the lucky user who gets to use it? Application server location protocols haven't gained much traction..... uPnP v1 monotonically increases port number... or gives up.... will probably be fixed in uPnP IGD 2.0. Security: loging IP addresses no longer sufficient... penalty boxes may be confused, won't know if it's a single user or many, which user to restrict..... Port randomization effectiveness is reduced.... OSS mechanisms basedon IP address... lawful intercept... customer profile management.... will require updates. Additional latency due to request for new port prior to every DNS query: Malicious users sharing your address can impact your connectivity Bob Briscoe: Is this under the control of an operator at one end? M. Ford: Issue for service providers to deal with their subscribers.... penalty boxes affect content providers as well, counting unique users per IP address..... M. Ford: Some issues exist already due to DHCP dynamic addressing or you already have a CPE NAT..... Discussion Sam Hartman: I'd like to question two fundamental goals. The first, the goal of keeping the NAT close to the user.... is that an inherent good? Sam: If the sharing solutions are more complicated to use, deploy and configure than CGN... then having the NAT close to me might not be better than a CGN. Sam: I'm skeptical of the second goal, tying this to the deployment of IPv6. saying "we've got IPv6 in here somewhere" doesn't make it better. Randy Bush: CGN horrifies me.... I felt obligated to propose an alternative solution.... we have networks to operate with Windows 95, that won't go to IPv6 soon..... Sam: CGN may actually be better! Randy Bush: Walled Gardens aren't a reasonable solution.... Alain Durand: The draft doesn't only address shared addresses in the SHARA context.... CGN and others are covered.... Henning Schulzrinne: The harm seems to differ depending on whether this is a Windows 95 solution, with most customers getting IPv6... Henning: if the legacy is a diminishing number... it's a fadeout solution... as opposed to a 10 year time horizon.... Henning: I'd feel better if IPv4 was only for legacy... and IPv6 were still being offered. Leslie Daigle: The document is trying to lay out the tradeoffs.... these are the things that should be considered. Leslie: supporting legacy is important... but shared awareness of the impact is important. Shara Scenarios M. Bagnulo & C. Jacquenet http://tools.ietf.org/html/draft-arkko-townsley-coexistence Current model involves NATs allocated public addresses... Proposal is to assign an address and a port range.... ISP will have port routers..... Ilitjsh: Are you going to do this without NAT? Won't the NATs translate the ports? Marcelo: You can still do things with the address and port range on the NAT. Use case #2: slide 5 On use case #2 you can have IPv4 in IPv6 tunnels.... Use case #3, slide 6. In this use case we have NAT64... which will also need a public address. Use case #4: cellular network scenario..... A+P embedded in device..... Generalized use case, slide 8 Generic case: some CPE doing port restricted NAT, port restricted NAT 64, or Port router. Q&A: Mobile case, port range assigned to mobile handset.... so handset has to know which port numbers to use, right? Iljitsch: read some of text in last two minutes.... we have e2e, we have NATs... do we want to invent a third thing? Solution space for address sharing, R. Bush, G. Bajko, M. Boucadair, P. Levis, Olaf and T. Savolainen http://tools.ietf.org/html/draft-ymbk-aplusp http://tools.ietf.org/html/draft-boucadair-port-range http://tools.ietf.org/html/draft-bajko-pripaddrassign http://tools.ietf.org/html/drafts/draft-boucadair-pppext-portrange-option This is an alternative to mediate problems of CGN.... and assumes that we can't transition legacy systems to IPv6.... A Core Technology with Extensions..... for tuning the core technology to suite different deployment models..... A+P (aka Port Range Router (PRR)) Provides Encapsulation.... port reduction... Fall back to CGN for NAT... where you can't upgrade CPE. DS-lite is a technology where you can't change the CPE. A+P Example: IPv4 in IPv6 encapsulation example there is a Large Scale NAT (LSN). One thing that can happen... port range NATing has been done... no need to remap in the PRR, passes it through. If customer has IPv6 it goes straight out.... The alternative is when there is old CPE... can't do port range mapping... the PRR sees it, knows it hasn't been mapped, hands it off to the Large Scale NAT..... Adapting to different models slide. Compression ratio: is it 1/5, 1/100, 1/1000? Measurements says long tail.... 700 ports is as big as you see in 99.9999% of cases. You can ssign ports non-contiguously to port range router to get some effects of randomization. You can encapsulate with IPv6, GRE, layer 2, etc. Signaling mechanisms: DHCP, UPnP/NAT-PMP, web page... How is the core technology tuned for deployment? For maximum compression: need very dynamic port assignment, expiring soon. If you use large static port assignment... you get minimum port compression ratio. Encapsulation mechanisms: layer2: PPP, layer 3: IPV4 in IPv4, IPv4 in IPv6, GRE..... To avoid problems with ARP on a shared medium, shared IPv4 addresses must be used with an encapsulation. Signaling vs. Provisioning: signaling between host and CPE.... signaling between CPE and Provider Boses. You could give customer a web interface to pick their ports. Signaling is between the CGN/PRR from ISP and web page adjusted by customer. CGN/PRR & application communicating via NAT-PMP/uPnP Documents: Architecture: A+P draft, Address/Port Allocation & Signaling: 4 documents.... Deployment/Application: DS-Lite draft Randy: DS-Lite document is the "poster child" for deployment. Randy: 4 more foils... do not take them too seriously. Randy: RADIUS is one of the thingies.... if you want to work on a document defining RADIUS attributes, go for it. Margaret: Drafts on limitations should bring up stopping innovation at the transport level... and also how it works with SCTP. Margaret: On an earlier slide: some traffic straight through... some goes through the LSN.... it has an odd property. Margaret: Windows XP on the host... it's using the Web with port randomization... will behavior change as the source port changes... so all traffic won't look like it's coming from the same host? Margaret: what if I'm not running NAT... host directly connected to Internet with IPv4 routable address.... Randy: Not detecting on a per-packet basis... the CPE/host is signalling the PRR/LSN... so it knows how to apply to all packets from that CPE/host Randy: I as a customer now have a choice... can pay $50 for a smart CPE which will signal.... Randy: and be closer to e2e Internet. Sam Hartman: I agree that CGN is bad... but I'm trying to determine if this is better. Sam: What is the value proposition for the customer... not doing CGN cuts off some options... Sam: Want P2P applications to work... want to reserve a port.. in a CGN I have more addresses.... less likely I'll have to remap ports for a particular flow. Sam: Will this work better or worse than a CGN that supports uPnP? Randy: IPv4 running out.... NAT inevitable.... closer we can move it to customer control... more likely customer can have tradeoff and make decision. Sam: Don't agree that customer control is inherently good.... though it may be linked to something good... apps working. Greg Lebovitz: channeling Dave Thaler. SAM, R.Despres http://tools.ietf.org/html/draft-despres-sam http://tools.ietf.org/html/draft-despres-sam-scenarios Only signaled traffic goes through PRR. ISP network example: SAM capable sites don't depend on CGNs. If customer implements SAM it has a global IPv4 address.... with 2048 private ports. IPv4 space shared by the NAT44 and a SAM There is the root SAM... and the son of the root SAM.... SAM-capable hosts avoid all NAT traversals. Google maps operates in native IPv6 if you have that..... With IPv6 activated less and less IPv4 ports will be needed. "Simplicity is the ultimate sophistication" -- Leonardo da Vinci. Question: if you want to make it as simple as possible... if end hosts already speak uPnP and NAT-PMP... why not push SAM to the NAT, not host? M. Ford: Clarifying question. So you're allocating 2048 ports per host? Contiguous port range? Answer: Yes Benefits of NAT avoidance, T. Savolainen Scope of benefits discussion: what benefits are available when CGN is avoided... benefits to be gained from A+P NAT binding refreshments consume battery. No NAT for a particular IP flow... not no NAT device located nearby. Dynamic NAT needs refresh... static NAT has bindings locked in. Reduced latency from no NAT on an IP flow. Firewall hole punching still required. No CGN for IP flow: More control for users. Easier to control local NAT with uPnP or NAT-PMP. Answer: one step toward reduced keepalive sending... make it easier to invent next steps. Users/devices/apps have an option for NATless operation. Many apps use NAT keepalives anyway, no? No CGN -- benefits for legal obligations. Simpler and chepaer legal storage.... Conclusions: Benefit of CGN avoidance is cost reductions.... port-restricted addresses held avoid NAT for selected IP flows.... Coexistence is possible with other technologies.... Port-restricted IPv4 address can be combined with other technologies such as dual stack, NAT 64 and DS-lite. Question: Do you want to reduce signaling to keep NAT mappings alive? Answer: yes, that is one goal. Question: are you aware of measurements of consumption with respect to NAT keepalives? Answer: There is one paper out.... If you are mostly in standby you can go for a week without recharing.... if you are sending keeaplives you get less than a day of battery life. Since keepalives prevent sleep. Dave Oran: why the issue of refresh reduction is so important? Dave: Isn't this independent of SHARA vs. CGN? Dave: Is this a separate question? There are proposals for STUN extensions. Marcelo: If you have NAT in the end host... you can provision end host with a port range.... no need for refreshing. Randy: His device is from Nokia... they are hand held... the NAT is on his device or a hop away.... he's not worried about keeping the NAT alive at your house? Dave: If we deal with the general problem of NAT keepalives and signaling.... we will have a general solution. Question: Last two presentations: may increase operator costs. What if A+P cost savings if false? If A+P and CGN cost the same... are there benefits? How important is cost reduction? Port range solution complexity can range from simple if port range is static....this would be at no cost on the router. To more complex. Magnus: AD hat not on. Implications of SHARA on Operations & Mgmt, A. Durand Alain Durand on TCP/UDP port consumption presentation. Here to show some measurements! Data collected... no IPR on the data. Data was collected on only one point in the network. Could be skewed. "Your mileage may vary" Results compared to other studies such as New Zealand study discussed earlier. Graph of ougoing ports on 8000 subscriber sample. Incoming and outgoing ports for TCP and UDP. 40K outgoing TCP ports for 800 subscribers (peak). 30K incoming ports on 8000 subscriber sample (peak) TCP port usage measured based on incoming SYNs. UDP is more difficult... could have methodology issue. UDP outgoing..... 32K ports for 8K subscribers, peak UDP incomin.... 30K for 8000 subscribers. What does it all mean? Transltes into max of 5 ports consumed per user on average in each direction for TCP&UDP. Total: 20 ports/user on average. Needs to be compared with the undreds/thousands of ports that can be consumed at peak by a single user browsing Web 2.0/AJAX site. Concerned about a static port range per subscriber.... customer can run out.... will call service provider saying "I can't browse the web anymore!!" Oversubscription is the answer... rather than cookie cutter approach. Back in old days you had dial up model per 10 or 100 customers. Pipes upstream were not dimensioned to handle the maximum amount for every customer. Answer: in the solution we are promoting in DS-Lite we have over-subscription by saying "any traffic sent will be NATed unless you are using controlled ports via the Web portal" So if you source traffic from a restricted range address, you get A+P semantic... if it is something else we will NAT it. Question: user can use many more ports.... what if they are trying to DoS you? For CGNs to work right... they would have to enforce per-user port limits. Alain: absolutely... draft has reference to this... need maximum number of ports... could be high: 64K, for example. Or a per-second connection establishment limit. Alain: we expect traffic to move to IPv6... this will be better... but reality is that today this isn't the case. Randy: If you are charing by port allocation.... go ahead and DoS me? Alain: What is difference between uPnP and TCP syn.... state is garbage collected eventually, either way. Christian: comments on CGN vs. A+P. Both have advantages/disadvantages..... depending on use case.... we can standardize both, leave it up to the operators..... Alain: they can be made to work very well together. Security Implications, P. Levis, G. Bajko Port selection predictability: can be exploited by attackers using Kaminsky type attacks (on DNS). Problem exists for non-shared IPv4 address. Current solution described in draft-ietf-tsvwg-port-randomization Shared addresses: can be contiguous, non-contiguous, pre-allocated random ports. Non-contiguous port allocation. Problem is that existing algorithms can't be used as they are... they need to be adapted. Pre-allocated random ports. Entropy is preserved Other issues: collective punishment. One client sharing an IPv4 address misbehaves.... all the sharing users are punished. Is this different than it today's NAT environment? ICMP packet too big should apply on a per client basis, not per IP address. Some ICMP mesages (echo request/response) will not go through unless they receive special handling. What are we missing? Geoff Huston Geoff: What goes through my head: "how do you perfect a disaster?" Geoff: Where we were trying to be today was getting rid of the residual bits of IPv4... but now the world is adding 250 million IPv4 addresses every year... and a microscopic amount of IPv6... and this isn't changing. The addiction to IPv4 won't stop. This is serious. Geoff: Do you try to get a soluion that is perfect... or would any solution do? Addresses are fundamental. We're trying to forward based on addresses and ports.... Chipping away at these basic properties of the address architecture...... "How do you know when you have gone too far?" Almost any solution will fly with small units... few will work on a scale of billions. How do you back out if it doesn't work? NATs: you can't remove them. If yout hink you'll get a NATless IPv6 world... you are on mind-altering drugs. Why are we here discussing this? Why isn't IPv6 everywhere? Why have we not made progress? What went wrong? Do any solutions offer anything different? First reality: No money. There never was any money. The Internet was never very good, it was just cheap. Why are there NATs: from an ISPs perspective, they are fantastically cheap. What happens when the ISP has to deploy all this gear? Costs go up but customer sees no benefit. But wasn't that the issue with IPv6? There was no business case for that either? 2. No time. How much time do we have now? We will run out of IPv4 addresses in 24 month's time. We want to be at the final stages in a month or two.... Can we deploy SHARA in 8 weeks? Randy: vendors have code now! 3. Confusion and Chaos. Everyone wants to solve the problem differently. We aren't working together. Where next? Should we perfect the disaster? IPv4 can't last much longer... but we aren't doing IPv6. That is uncomfortable for all of us. If we are not careful... it will be everything over HTTP. Geoff: When all else fails, there is always denial. Geoff: This is all general discussion, M. Ford: I spent time on IPv6 deployment... we were just too early. People will wake up and listen. SHARA will scare them into it! Randy: BS. IPv6 has been deployed for years... it doesn't solve this problem. I wish it did. So did the people who are having to deploy it. Randy: This is cute. Alain has a real problem. He can't number his customer's edge and doesn't want to dump customers without IPv6. Silly Alain... he wants to stay in business! Randy: I wish all of my competitors would go to IPv6... because then I could take their customers! Randy: I'm speaking as the first operator to deploy IPv6... we put money into IPv6, we have IPv6... there is a specific problem for specific classes of providers... they have jillions of little customers who insist on speaking IPv4. Wish it wasn't so. But it is. If you have ideas on how to solve it... rather than pontificating... please tell us. Alain Durand: I'd like to answer Geoff's question. Alain: It's not just IPv6 deployed due to lack of money... it's lack of backward compatibility.... two long tails: what customer has in their home -- a gadget that doesn't do IPv6. Second tail: the content. It's all IPv4. Going to IPv6 won't solve these problems. That said, the more traffic we move to IPv6, the less stress we put on the system. I'm calling port sharing "IPv4.5". Are we going to get stuck there? Or is it the light at the end of the tunnel? iljitsch: It's a solution in search of a problem. The problem with IPv6 is Windows 98 boxes and devices that aren't upgradeable. We know that most users don't care about incoming connections. Margaret: I'm not sure that I like the address sharing solution. I don't like CGN either. I'm not sure which one I like better. It might differ based on the size of the ISP and other factors. If we don't all agree on what the problem is, this is scary. I hope we understnd that people will continue to use IPv4. It's not about Windows 98.... someone will be running VMware and will run world of warcraft. This is a Y2K level issue... we can't say we'll switch to IPv6 in two years. We will have IPv4 for 10 years... maybe longer. Keith Moore: I don't think you can do that analysis. We can't validate statements like "customers don't care about incoming connections". We need to give application writers a way out, so they can continue to work. Next steps - AD, Chairs Magnus: We will ask a few questions. First question: How many people think it is a good idea to work on an extension to CGNs which provides restricted port mapping capability. Greg Lebovitz: An extension to CGNs? Is that what this is? Magnus: Restricted Port Range capabilities.... Magnus: Let's up-level. Are people interested in continuing discussion on this? Yes or no. Hummm..... Question: Are you talking about A+P, something else???? Lars: Should the IETF continue working on shared IP addresses? Yes or no? Hummm.... some humming. Lars: Weak consensus for yes. Jari: We have DS-lite.... Jari: Question here: do we want to do something in addition... that would move control toward the CPE. Jari: I think answer should be "yes" Erik Nordmark: another question lurking: do we want routers that route on port number. Stuart Cheshire: Someone said earlier that users don't want incoming connections. Apple has "back to my Mac"... customer can access their computer at home. Stuart: DirectTV is advertising remotely programming DVRs. Stuart: IPv6 is the future.... IPv4 is in this grandfathered maintenance mode.... but at least we'd have a view out of the mess. Margaret Wasserman: Are we trying to figure out if we want to do one of these proposals? What was I answering yes or no to? What are you going to do with the answer? Magnus: One possibility is to do A+P as an extension to CGN. There are multiple options here. Alain: In my opinion this is a charter discussion. Alan: There are people talking about how this fits together. We need to look at the implications to the global architecture. Alain: We need to document effects on penalty boxes.... architecture considerations that the community can start to describe. Margaret: I hummed yes, that we should keep talking. I hope that's not interpretted to say "form a WG on A+P" Jari: I have a practical problem. We have a softwire WG... we need to know what to put in the document. Jari: do we need to put in a dynamic mechanism for getting the ports? Jari: I'd like to know that relatively soon. Magnus: we will continue the discussion the SHARA, BEHAVE and SOFTWIRE mailing lists. -----------------------------------------------------------------------