BEHAVE Working Group Agenda IETF 80, Prague, March 2011 Chairs: Dave Thaler dthaler@microsoft.com Dan Wing dwing@cisco.com Jabber room: xmpp:behave@jabber.ietf.org?join minutes by: Stuart Cheshire Tuesday, 15:20-18:10, Congress Hall III 15:20 Dave Thaler gave overview of document status. There is an AUTH48 change in NAT64. Deadline for objections is noon Friday; will unblock XLATE document cluster. Dave Thaler asks: anyone interested in SCTP NAT? There was no response from participants in the room 15:30 Scoping CGN Requirements document, Dan Wing Simon Perreault: Clarification: Documents quotes previous RFCs which give requirements relating to NAT in general; further requirements need to be specific to CGN. Mohamed Boucadair: We have to re-examine requirements in the current BEHAVE RFCs. Document should not be useless to service providers. 15:35 Dual Stack Hosts Using "Bump-in-the-Host" (BIH) (Teemu Savolainen) draft-ietf-behave-v4v6-bih-00 milestone date: April 2011 Teemu asked for comments from the room There was no response from participants in the room Hui Deng: Address mapping could be moved to a separate document, to allow for stateless mapping as well Dave Thaler: Stateless mapping from v4 to arbitrary v6 addresses is not possible 15:45 Avoiding NAT64 with dual-stack host for local networks (Jouni Korhonen) draft-korhonen-edns0-synthesis-flag draft-savolainen-heuristic-nat64-discovery draft-korhonen-behave-nat64-learn-analysis milestone date: April 2011 Dan Wing: Should we use DNS well-known-name (hack) or the ENDS0 option (more elegant) Andrew Sullivan: Are there implementations of NAT64 that don't currently implement the ENDS0 option? Mark Andrews: BIND does not currently have the ENDS0 option but could easily add it Andrew Sullivan: Needs to be done quickly Matthew Kaufman: What about client resolver APIs that don't support getting to the EDNS0 option? Stuart Cheshire: What software needs to learn the prefix? Client DNS resolver, or other application software? Dave Thaler: Other application software. Stuart Cheshire: Then the resolver API limitation might be a problem. Andrew Sullivan: Standardizing a DNS well-known-name will be an uphill struggle Andrew Sullivan: We should pick one and do it, not both. Dave Thaler: If DNS well-known-name, we need to decide if it's a single global well-known-name, or per-operator, or per vendor? Matthew Kaufman: This will happen. Better to synthesize locally than to store in the DNS far away. 16:08 Analysis of 64 Translation (Reinaldo Penno) draft-ietf-behave-64-analysis-01 milestone date: February 2011 Dan Wing: We will Last-Call this. 16:10 Carrier-Grade NAT Requirements (Shin Miyakawa) draft-ietf-behave-lsn-requirements milestone date: December 2010 Stuart Cheshire: Why the change from "CGN" to "LSN" Dave Thaler: Poll Lars Eggert: We should Last-Call this rather widely, to other mailing lists: App area, TCPM, Softwire Lars Eggert: Fairness Lars Eggert: Rate limiting on TCP connections could hurt applications. Alain Durand: Enforcing limits is good. Was attack. Lars Eggert: Why not allow full use of available capacity? 16:22 NAT64 Load Balancing (Dacheng Zhang) draft-zhang-behave-nat64-load-balancing milestone date: April 2011 Dan Wing: How many people have read this? About eight people raised their hands Dan Wing remarked that we have a WG milestone for NAT64 load balancing, and asked if anyone had interest in NAT64 load balancing. Nobody came to the mic. 16:30 RADIUS Extensions for NAT Forwarding Port (Dean Cheng) draft-cheng-behave-nat-fwd-port-radius-ext-00 Rajiv Asati: After setting up their mapping, user needs to reboot CPE for mapping to become effective Daniel Derksen: Why not allow COA to install new mapping in the BNG? Roberta Maglione: Agree: Should be allowed in COA message 16:40 NAT64-CPE Mode Operation for Opening Residential Service (Gang Chen) draft-chen-v6ops-nat64-cpe Hui Deng: Divide this into two halves: Inbound and outbound. Inbound belongs in v6ops. Dave Thaler: Yes, Inbound belongs in v6ops, in the form of "CPE requirements" Charles Perkins: How is this different from IVI? Dave Thaler: IVI is stateless, like stateless NAT64. This is stateful. 16:50 Analysis of Solution Candidates to Reveal the Origin IP Address in Shared Address Deployments (Mohamed Boucadair) draft-boucadair-intarea-nat-reveal-analysis Dave Thaler: You claim this does not change privacy, but if client's IP address today changes then the the HOST_ID needs to change too Francis Dupont: Revealing client's source IP address to the server is illegal in Europe. Shin Miyakawa: What stops attacker from forging HOST_ID? Dan Wing: Server is free to ignore the HOST_ID if it detects that an attacker is putting in fake HOST_IDs. Alain Durand: A user today who's not behind CGN can pretend to be lots of users behind a CGN, to circumvent blacklists. Lorenzo Colitti: As a server operator, I cannot rely on this HOST_ID being set reliably by the sender Mohamed Boucadair: Every web site operator should do what Wikipedia does: set up bilateral agreements with all the ISPs they've decided that the trust to set Daniel Derksen: Rapidshare uses source IP to limit downloads to one per user. If non-CGN users can forge their own HOST_IDs they defeat Dave Thaler: Each site operator has their own list of trusted ISPs. That doesn't scale. Dan Wing: This is additional information a content provider can choose to use or ignore as they wish. Joe Touch: The point of this document is to compare the various alternatives Jari Arkko: This is important. If we don't solve this problem then people will be getting blacklisted inappropriately. Stuart Cheshire: The problem is not user A masquerading as user B, it's (non-CGN) user A avoiding blacklisting by masquerading as a CGN with 10,000 users. Dave Thaler: IPv6 with privacy addresses already has this problem Lorenzo Colitti: There are too many opinions in the room. This shows the problem is complicated. The more time we spend on this the less time our engineers spend working on IPv6. Joe Touch: We need to solve this for IPv6 too, so we should think about it. Alain Durand: No, with IPv6 the first 64 bits uniquely identifies the subscriber Dave Thaler: What about at hotspot or an IETF meeting? Joe Touch: The point of this document is to capture these issues. 17:20 NAT64 Management Information Base (MIB) (Jean-Philippe Dionne) draft-jpdionne-behave-nat64-mib Dave Thaler: What is the current level of actual implementation of RFC 4008 (NAT MIB)? Mohamed Boucadair: We need to update the MIB Marc Blanchet: Cisco's NATs implement RFC 4008 Dan Wing: RFC 4008 is okay for a small NAT, but not much use for a big NAT, e.g. it has no per-user alarms. Marc Blanchet: Are you suggesting to abandon RFC 4008 and start again? Dan Wing: I don't do MIBs. Dave Thaler: That's harder than what this doc proposes Dan Wing: Our customers ask for things like per-user alarms. I would like to see a better, standardized, MIB. Lars Eggert: Getting a MIB done where there's not enthusiasm is worse than pulling teeth. Daniel Derksen: I can confirm there is customer demand for this Merike Kaeo: I would like to see this MIB Lars Eggert: We should postpone this question, and see if there is enthusiasm on the mailing list. David Harrington: I'd like to see proprietary MIBs developed first, and then if they're successful we can adopt the best of them. 17:35 Report on Monday's Multicast Bar BoF (Stig Venaas) Stig Venaas: Which WG to work on this? Dave Thaler: Mboned might be good for problem statement Alain Durand: Does it make sense to send the same multicast stream to the same client both natively and over a tunnel? Hui Deng: Do you have documented use-case scenarios? Stig Venaas: IPTV providers don't want to have to source the same multicast stream twice, once over IPv4 and again over IPv6. They'd like to send one stream and have it split closer to the receiver(s). Hui Deng: Where does this happen today? Stig Venaas: Usually within a single provider. Tom Taylor: Don't forget the company site-to-site case. Lars Eggert: Long list of affected areas means we don't know how to slice this. You need a BoF. Stig Venaas: If a content provider wants to do this today they either have to send everything twice (double bandwidth) or force all of their subscribers to switch overnight. Mohamed Boucadair: Don't want to send everything twice Lars Eggert: I said you need a BoF. I didn't mean right now. Put a BoF proposal together. Alain Durand: There is time to discuss this tomorrow in Softwire. We don't need a BoF. Softwire handles v4 over a v6 network, and v6 over a v4 network and that applies to multicast as well as unicast. Lars Eggert: We need to follow the BoF steps because this is how new work gets brought to the IETF. It could be a non-WG-forming BoF. Dave Thaler: I agree with Lars. 18:00 End