INTAREA meeting notes - IETF 76 1300-1500 2009-11-09 (Mon) Notes taken by Ed Jankiewicz Last revised 2009-12-11 by Jari Arkko ------------------------------------- ADMINISTRIVIA ARKKO/DROMS 10 MINUTES ==================================== Agenda bashing; blue sheets; scribe; Jabber scribe Note well, agenda bash WORKING GROUPS UPDATE ===================== http://www.ietf.org/proceedings/09nov/slides/intarea-3.pdf DNA, PANA to be closed 6man - UDP checksums discussion should be interesting NETEXT discussing BOF outcome 6lowpan - ND extension A lot on IPv4/IPv6 coexistence in several groups Wed 13:00 AplusP BOF, address sharing through tunnel deployment 3GPP-IETF joint meeting on IPv6 cellular, March 2010; are the current models sufficient for cellular operators? Tools in development and new tools to be considered. Opportunity to work together. Any other WG chairs have anything? No takers Intarea “working group” formation - dual role as discussion forum and secondly to advance work items in the IETF. Typical WG organization with two co-chairs, looking for volunteers Alain Durand - is this WG the right place to discuss issues arising in the Intarea with impact on other areas (eg Application)? Jari - definitely one of the forums Alain - cross-area discussions may be needed Ralph Droms - this has happened in the past, discuss the same draft multiple WG meetings, area meetings Jari - surface to all the right areas. Francois Le Faucheur - As someone driving a work item that fits well within IntArea but does not fit under in any existing IntArea WG, I support the creation of this WG. Mark Townsley - don’t lose the opportunity to maintain the open intarea area discussion - important to AD to hear this stuff. Don’t delegate too much away to intarea WG (chairs agree - intention is to maintain focus on area-wide concerns) Intarea WG work items: New work should satisfy some basic conditions, setting a high bar. Not “abandoned work” from “failed BOFs” but important work affecting the area Initial milestones: IPID doc and tunneling issues ISSUES WITH IP ADDRESS SHARING M. FORD 20 MINUTES ================================================= http://www.ietf.org/proceedings/09nov/slides/intarea-0.pdf repeat of presentation in Softwires from SHARA BOF, merged several prior efforts Collect all the various issues in solution docs, capture common issues into one citation Taxonomy: CGN vs port-range solutions Long tail of subs requiring more than median number of ports, need to balance sub/address ration; manage port churn; implications for logging and signaling Breaking applications that care about ports; typically ALGs used CGN has limited ALGs available, port-range solutions require changes to ALGs ICMP problematic. List of other issues, some needing more contribution (multicast in particular) Behcet Sarikaya - address sharing and mobile IP at AplusP BOF Charles Perkins - working on a solution that works around some of these problems Ralph - this is the taxonomy of problems, not solutions Security issues discussed including restricting port range (less port randomization), impact on logging and “penalty box” extend to include ports; spam blacklisting IPsec through NAT is applicable; authentication based on only IP address no longer works Joe Touch - port randomization is not security; limiting concurrent or sequential connections (within timeout) 3 bit per host - 8 connections Sam Hartman - let’s make sure port randomization is important before we spend any time on it. IPsec connection latching - a way of naming for upper layer protocols to use; may be port sharing implications, please double check Joe Touch - unsigned Diffie-Hellman; binds up and down. Multiple identities per port? Ralph Droms - author is happy to accept text Geo-location and proximity; reduced confidence and granularity Traceability - legal implications; log source address and port and timestamp to unambiguously identify subscriber; large volume of data for long-term retention of mappings Any additional issues? Alain Durand - can we get Transport input? Multipath TCP, etc. need input/text from them; what do we break? Maybe good idea to present in TSVarea Kenji Rikitake - if large number of CPE, there are allocation strategy problems; scalability and complexity Joe Touch - control block sharing, congestion control, based on IP address; is there IANA impact from port sharing Ralph Droms - unilateral deployment of address sharing has impact on other unrelated entities - you can create problems for others Mat - yes, this needs to be addressed Ralph - communicate with Mat on text, comments, etc. not sure where to home this Alain - Softwires may be the home Jari - probably reasonable to home it here, but not calling yet Alain - don’t wait until next meeting to adopt in a WG Jari - we can do on list in the interim IP ROUTER ALERT CONSIDERATIONS AND USAGE F. LE FAUCHEUR 15 MINUTES ================================================================== http://www.ietf.org/proceedings/09nov/slides/intarea-1.pdf Accept as WG work item (assuming intarea WG is formed)? Problem Statement - Router Alert Option security concerns not well documented; practical questions remain to be answered - should RAO be allowed or blocked? This would be a BCP to document the concerns, identify where RAO is appropriate or not; implementation guidelines This is not about redefining RAO - document the current situation; see narayanan draft Doc changes Recommendation on not using end-to-end RAO generalized; illustrations of the flows that are/not recommended Within an Administrative Domain is OK - safe In water-tight overlay model - also safe - no leaking of RAO over domain boundary Proposing this as a WG document, not enough review yet Suresh - not progressing the hop-by-hop doc, no clear way forward Sam Hartman - talk a lot about security, is this more than DOS? Francois - mainly thought about DOS Sam - does describing this as security issues really add clarity to the doc? Ralph - assuming an Intarea WG, should this be a WG item? Consensus yes, to be confirmed on mailing list Margaret Wasserman - does this doc meet the other criteria for a WG doc, that was previously put up? Jari - seems there is enough contributors/reviewers and demand for this, please comment if you feel if doesn’t meet the criteria TRAFFIC SAFETY APPLICATIONS REQUIREMENTS C. CANO 15 MINUTES =========================================================== Vehicular networks emerging, initiatives going on in US and Europe Can these performance requirements be met by IP based network and transport solutions? Traffic safety applications Applications and use cases quite similar between US and European consortia; performance requirements differ is this work interesting? Is IP an appropriate solution to these requirements? Charles Perkins - difficult security issues on vehicular communications; what is the security architecture? Analyze the security requirements before deciding IP is the right solution; document would not be complete enough without the security analysis Ralph Droms - are there security standards/requirements from the consortia? Yes George Tsirtsis - why is this in the Internet Area? This is application or L2 problem? Implication that some IP functions may need to change, e.g. ND too slow Ryuji Wakikawa - requirements in this doc derive from SDO; governments assign frequencies for the v2v communication; did not pay attention to the network, VSC is single hop. Looking for feedback from IETF. Brian Carpenter - this seems to be a typical application scenario for MANET. How quickly are these consortia going to decide on a network? If they are prepared to go through several years of SDO liaison activity we might be able to contribute, otherwise we should wash our hands. Jari - we’re not here to design everyone’s networks; not clear what we should be doing here. This may not be the right forum. Ralph - what is the timeline? Wes George - is this interesting? Yes. IETF can help with this. Can IP solve the problem? Yes, but need to identify gaps. Lack of reference to IPv6 - sensor net, smart grid also similar omission Francois - C2CC is considering only IPv6 Thierry Ernst - car manufacturers don’t buy into IP for car safety; SDOs are considering IPv6 - liaison is necessary; why Intarea - interaction between MEXT, not just mobility issue, address management, etc. Ralph - collect interest and comments THE SUBNETWORK ENCAPSULATION AND ADAPTATION LAYER (SEAL) ======================================================== F. Templin 20 minutes http://www.ietf.org/proceedings/09nov/slides/intarea-2.pdf Accept as WG work item (assuming intarea WG is formed)? Tunnel MTU - how to determine? How can the tunnel adapt to restricted links? SEAL adds a 4 byte encap sublayer; tracks MTU without PMTU discovery Works like IPv6 fragmentation, with fix segment size and not overlapping segments No prior negotiations needed Draft status - lots of list input, changes made This is a standards track submission through intarea, vs experimental RFC on SEAL-FS (fragmentation sensing) The MTU is based on Egress Tunnel Endpoint (ETE) maximum reassembly size, not on the minimal link Unmitigated fragmentation considered harmful, but carefully managed fragmentation is useful. In-network fragmentation is “canary in the coal mine” Margaret Wasserman - wrote review of the doc, need a larger answer - already a ton of tunneling protocols, who needs this and for what? Fred - SEAL focuses on the encapsulation format; companion draft on VET covers the end-point negotiation Margaret - why do we need yet another? Fred - sequence number and MTU amelioration Margaret - not convinced Jari - if no one knows what this is used for Alain Durand - if we had this years ago, it might have been helpful. Now it is too late, cat is out of the bag. Yet another Fred - well recognized that MTU is an issue in tunnels; Mark Townsley - what is the target status? Inventing a protocol is not hard; getting it deployed, mindshare, etc. is really hard. Publishing this as experimental/informational is a good idea, putting it into practice, code first - then standards track. Fred - an attempt to make tunneling a first-class citizen Mark - this is only a piece of a piece of what could be a first-class citizen; a new tunneling protocol attempting to obviate the rest becomes an n+1 Fred - there is a scenarios doc (RANGER) as well Jari - do you (mark) foresee using this? No. Margaret - many tunneling protocols are being developed, and don’t seem to be adopting this; that is worrisome. Maybe there are specific objections or they feel they can solve it more simply. Jari - it is clear there is a problem with MTU in tunnels, not clear if this should be the solution. Mark - big difference between “is this interesting, and you might use” versus “are you planning to use it” Jari - if people don’t see using it, why take up the effort? Take on the mailing list LIGHTWEIGHT IGMPV3 AND MLDV2 PROTOCOLS R. BONICA 10 MINUTES =========================================================== (Ron not here) Jari - need review here please take a look. OTHER WG ISSUES, NEW BUSINESS, ETC. ARKKO/DROMS 10 MINUTES ========================================================== None