Internet Area Meeting IETF 66, July 2006, Montreal Area Directors: Jari Arkko & Mark Townsley Note takers: Vijay Devaparalli and Stefano Faccin (merged and edited by Jari Arkko) 1. Area status update (ADs, 20 min) =================================== BOFs: none this time, shared interest with HOKEY BOF and the NEW BOF. LIES/TERNLI BOF did not happen, but there will a presentation on this topic later in this meeting. One BOF on anycast was discussed, but there was some discussion on O&M open area meeting. WGs creation, rechartering, and termination: Created ANCP (Access Node Configuration) and 16ng (IP over 802.16) WGs. Terminated IPOIB (IP over InfiniBand) due to having finished its main task. MIBs remained in their charter, but there was not enough progress on them. MIPSHOP rechartered after it had finished all of its tasks. MIP4 being rechartered to add dual stack operations work item. MIP6 being rechartered to consider progress and align to current interests and the charter. NEMO and SHIM6 will undergo rechartering before IETF-67. HIP is rechartering for new items and will close thereafter. IRTF HIP WG remains. 2. Other WG news: ================= 6LOWPAN needs to finish its 2 current deliverables (an is a year behind) and wants to address new topics. IPODVB working on L2 security mechanisms that need to be revisited based on current charter. PANA: explosion on the IETF discussion mailing list based on initial e-mail from Sam Hartman. This has led to an effort in the WG to reduce complexity of solution since there is considerable confusion. "Less is more". NETLMM has published its first solution draft from the design team, and will have interim meeting in September. 3. Area documents status ======================== These documents do not have a home in any WG. draft-fenner-iana-exp-2780-02.txt: Experimental allocations for various IP layer numbers. Approved, in RFC Editor”Ēs queue draft-bagnulo-cga-ext-01.txt: Extensions for CGA needed for SHIM6 work. Approved, in RFC Editor”Ēs queue draft-bonica-internet-icmp-01.txt: Extensions to add data objects to certain ICMP messages. Still ongoing discussion, PS vs. EXP and IPv6 issues. Will be discussed today. draft-bagnulo-ipv6-rfc3480-update-00.txt: Updates to RFC 3484 to support multihoming, plus a few other minor updates. Will be discussed today. draft-laganier-ipv6-khi-01.txt: An allocation from the IPv6 space to support HIP implementations that depend on unmodified APIs. Main discussion issue about the size of the allocation is now resolved. Will go ahead as an AD sponsored Experimental RFC. 4. IAB Routing and Addressing Workshop ====================================== Dave Meyer pointed to a mailing list (routing-discussion) for discussion on routing and addressing. There is going to be an IAB-organized workshop on operational problems and future challenges. The plan is come away from the workshop with a problem statement on routing operational issues, not to design a solution. Workshop will in mid-October, time and place to be narrowed down (participation by invitation). 5. Source address selection problem for multi-homed environments ================================================================ http://www.ietf.org/internet-drafts/draft-bagnulo-rfc3484-update-00.txt Marcelo Bagnulo presented issues which if need to be solved would required updating RFC 3484. The goal of this presentation was to agree if RFC 3484 needs updating, and to provide input on Marcelo's multihoming issues. A set of issues in RFC 3484 was identified: remove site-locals, include ULAs, additional tools for policy table handling, handling of unreachable source addresses (identified in SHIM6 and previously in MULTI6; needed for multi-addresses nodes and sites, and can help with ULA cases). Document suggests a set of rules that provide guidance to the application when it selects the src add, similar to the available for dst add selection; also, a modification to the src add selection of the IP layer, so that unreachable source and destination address pairs are detected and alternative address pairs are tried. Dave Thaler - Agrees with working on modification to the source address selection Pekka Savola - Surely we need do the second part, not sure about the first one. Marcelo: For first part intention is to include very lax guidance to the application developers. Pekka: No changes in the implementation? Marcelo: There would be changes in the application. Tim chown - Would like to see these changes happen. Unidentified - It is complicated currently with socket API to do source address selection. Are you proposing TCP connect to do source address selection? Most applications should do it by themselves today. Unidentified - In case of UDP it can be even harder to do. Marcelo agrees. Pasi Eronen - in Windows Vista there are solutions for this. There is exposure to the applications. Marcelo points out that there is also connectbyname call. Dave - Confirm that it is true. API changes are better than having applications deal with multiple addresses and make decisions. Hesham - Agrees with the problem. Asks if we have an idea what is important to solve first? There is a need to prioritize. Bob Hinden - the current IPv4 document is a compromise solution. This can be get complicated very quickly. I would rather with document solutions that actually work from vendor and deployment experience rather than trying to develop new solutions. Unidentified - Is SHIM6 as solution for this? Marcelo responds that SHIM6 requires both ends to be updated, but here we are saying that if you are multihomed and have two prefixes, there is the need to update a large number of nodes. There should be simpler & more efficient solutions available. Jari concludes by stating that there is interest for this work. But we should be careful in not doing too much or too radical solutions. Focus on what implementations already do. 6. Making CGAs survive hash algorithm issues ============================================ http://www.ietf.org/internet-drafts/draft-bagnulo-multiple-hash-cga-00.txt Goal of the discussion is to note that RFC 3972 had a hard wired hash algorithm. Should we change that? Marcelo Bagnulo notes that there is an issue with recent attacks against collision free hash functions. These challenge the application of such hash function for the provision of non-repudiation capabilities. For SEND, the idea is not to move from SHA1 but to allow other hash functions. In order to avoid downgrading attacks, encode in address itself. Use Sec field to encode both current Sec information and the hash function used, reserve 3 values for existing, and create new registry CGA SEC for the future Iljitcsh - why is it necessary to carry the hash function in the address? There are other parameters that are needed anyway. Why not have this information stored there? Marcelo responds that this is to prevent downgrade attacks Pekka Savola - This might be a useful direction to go. But may not be needed now. The current SHA1 function is quite secure. I would be a bit hesitant to do it now. Marcelo notes that today there is not much deployment of CGA. We want to reserve bits today, before deployment happens. Once it happens, its too late to use the same bits. And there are no other bits available. Gabriel - Supports this. Discussion continues about whether other parts of the CGA idea, such as the used public key algorithm, need to be protected in the same way at the same time. Tim Shepard notes that with the public key algorithm, there is no problem with downgrade attacks. But with the hash algorithms there is a possibility of downgrade attacks and so should be encoded in the address itself. For public key algorithms this need not be encoded in the address 7. Way forward with ICMP extensions =================================== http://www.ietf.org/internet-drafts/draft-bonica-internet-icmp-02.txt Goal is to get a feeling from the group on where we stand on the problems remaining on this discussion, such as IPv6 support. Jari gave an update of the history of this proposal. An early version of this is actually deployed out there. Can we have an effect on that deployment? Remaining issues are: o Standards track or experimental? o Given that we are doing for IPv4, should we do for IPv6? One implementation already exists that does this for IPv6. Joe Touch - Does not care if others do some bizarre extensions to ICMP to support some sub-layer 3 protocols. maybe we shouldn't do anything. Mark - we are re-opening the original debate. we don't want to go there. Joe - but you are trying to justify the work using the deployed based as the reason. Mark - Lets not re-open the earlier discussion. Jari - Earlier we did a separation to the base and the application of this. ICMP traceroute for MPLS is one application. No question about that. But there has been other proposed applications, so we may need this for a number of purposes down the road. Pekka - there is an Internet layer implication by this change. Supports proposed standard. Rob Austein - IPv4 and IPv6 versions of ICMP should be similar. What was decided for IPv4 ICMP should be done for IPv6 ICMP too. Bob Hinden - This is probably going to show up in other places (3GPP, Wimax). So not sure doing a special case of MPLS is a good idea. There should be general solution if at all any. Mark - The MPLS objects are themselves advancing in the MPLS working group. We are doing a more general solution here that will be useful for more than MPLS. Conclusion by Mark - Heard a few people say the solution for IPv4 ICMP and IPv6 ICMP should be similar. This seems like the way to go. Jari - Should this go on standards track or experimental? Hum - Mild preference for standards track. 8. Comparison of mobility protocols =================================== http://www.ietf.org/internet-drafts/draft-thaler-mobility-comparison-01.txt Goal: Increase awareness of where the different schemes are in terms of their functionality, efficiency, etc. Dave Thaler presents his analysis on MIP6, SHIM6 and HIP. The analysis is based only on WG drafts. Vijay Devarapalli - Is network outage part of IP Mobility problem? Dave - Maybe. Geoff - It is the rendezvous mechanism that is important to consider. not network outage. Margaret - What would be interesting to compare between MIP and shim6 is where things happen. In mip6, the knowledge of about HoA and CoA is on the home agent and in shim6 it is at the end hosts. There are some architectural differences. Dave - True. But only wanted to see what problem each protocol solves and what features are easy to compare. Hesham - There are architectural differences, but there are two modes in MIP6. route optimization is between the MN and the CN. Tim Sheppard - How you fill in the boxes reflects some architectural assumptions. Want to tease out the assumptions. IPsec VPNs? Pekka - Home Address are as stable as the home link. Subject to home re-numbering. Vijay - There are extensions to MIPv6 to handle home link renumbering and home address change. In the event of home address change the FQDN to HoA mapping is updated. Alex - Include reachability from behind a NAT? Dave - Limiting this to IPv6 only. Assumes no NATs George - You should compare MIPv6 route optimization to shim6 and HIP, since that is end-to-end. Dave - agrees Hesham - There are WG documents in MIPSHOP that reduce the number of MIP messages. Dave - Send me the information. Thomas - Puzzled by the connect overhead. with MIPv6 you can send packets right away if using the tunnel with the home agent. Route optimization kicks in later. Dave agrees. Andre - DoS protection? Dave will consider this Vijay - Do you want to consider maturity and deployment experience of these protocols in your draft? Dave has not considered these. Only a technical comparison. George - Make it clear that you are considering these protocols end to end. There is a home agent (reverse tunnel mode) that is very different. Dave agrees 9. Transport - network layer interface evolution and mobility ============================================================= Goal is to talk about the challenges related to transport - IP interaction, particularly related to implications of mobility technology. Discuss, and gather input for a BOF in this space in IETF-67. Lars Eggert goes over the problem space. John Loughney - Traditional transport protocols assume a uniform path through the network that does not change often and the RTT remains nearly the same. They have to now deal with rapidly changing paths due to mobility. Very significant when the RTT for the path changes. Geoff Houston - It is important to see how the feedback is handled rather than how the feedback is given to the transport protocols. The issue tends to be architectural. What are you trying to do with with the feedback you receive? Lars - agrees. But there is energy in the IETF because we see people wanting to work on this. Geoff points out that we need to require not just energy, but also validity of the approach. Hesham - Transferring information from one layer to other is extremely useful. We need to be conservative on the type of information we transfer, though. Thomas - Worries about folks coming with focused on specific link layers. There is an extension to Mobile IP for the home agent to tell the other end the path has significantly changed. Have a critical mass of people to work offline and come back with a problem statement. Unidentified - Should not try to do the same thing in many different layers. We dont want two layer to interact to a change in the path that conflicts.