---------------------------------------------------------------------- IETF72 Mobility EXTensions for IPv6 (mext) WG Meeting Minutes Chair(s): Julien Laganier Marcelo Bagnulo Minutes based on notes taken by Wesley M. Eddy and Sri Gundavelli ---------------------------------------------------------------------- ---------------------------------------------------------------------- MEXT Session I - Meeting Minutes (July 28th, 2008) ---------------------------------------------------------------------- ---------------------------------------------------------------------- ATN Topology Considerations for Aeronautical NEMO RO Christian Bauer - draft-bauser-mext-atn-topology-00 ---------------------------------------------------------------------- - draft is only focused on ATS and AOS, not related to passenger communications - Main types of access networks are ACSP (service providers) and ANSP (national air traffic control agencies) - An airline chooses between one of two existing gACSPs for its services - Locations of CN differs between ATS and AOS - Marcelo has question about the difference between ANSP offering an access network itself, though in AOS, this is never possible. Christian answered by explaining that an airline will never operate its own access network. - Trust relationships exist between all parties and the ACSPs. PKI is mentioned in the requirements doc, but doesn't yet exist, and it is not clear what will exist in the future. There are X.509 certificates for Secure ACARs, and at least one service provider is operating a CA for this. - LMNs won't be for ATS, maybe for nothing. - HAs are expected to be with the ACSPs in order to avoid cost to the airlines of running HAs themselves. - No questions ---------------------------------------------------------------------- Correspondent Router based Route Optimization for NEMO (CRON) Carlos J. Bernardos - draft-bernardos-mext-nemo-ro-cr-00 ---------------------------------------------------------------------- - The CR idea has been around for a long time (ORC and PCH proposals) - CRs should be topologically-close to the CNs; MR has task of finding a suitable CR for a flow - Hesham points out that CR can also be close to MR. - Chan Wah said it was easier for CNs to direct packets through the CR if it was near to them - Pascal noted it could be near a peering - Open Issues - 1) There are many possible designs for the MR to discover CRs - 2) MR-CR signalling / binding establishment: BU/BA based, triggered by MR, and based on certificates for proof of prefix ownership - 3) Use of the MR-CR bidirectional tunnel has to be forced somehow - Hesham asked if it is possible that the CN may also be mobile - Jari Arkko says all that's required is that the CN and CR are fixed to each other rather than that they're globally fixed; more work is needed and the IGP route injection thing is scary - Hesham is concerned about putting the prefixes within the certificates for renumbering, and other inflexibility this causes - Jari says that MR-CR route optimization makes it necessary to put the prefixes into the certificates - Ryuji says this seems doable but not feasible - state on the CR is dependent on the MRs movement and injecting these prefixes for the MNP is a very dynamic operation - Julien has a question about the binding state, is it based on CN's ADDRESS or PREFIX? - Carlos says it could be either - Marcelo points out that it would be undesirable to wind up with a solution that is only good for aviation and not for other industries - Hesham asks what the cost is ... it's just software - Pascal says that as a manufacturer he wouldn't do something if it was just for a small market - Hesham can't see this solution working for anything other than the aero environment - Christian noted that even a line of code is quite expensive in this environment - Jari asked about the passenger side of the use cases - Carlos answered that this is not very good for that - Marcelo said that the passenger traffic may not need to be optimized from the requirements - Pascal trying to figure out how this could work for mobile phones, and notes that providers don't want to disclose the location (CoA) of devices, so he doesn't see how this could work for phones since it discloses the CoA. - Jean-Michele - does this allow that the CR may be another MR? If you want to generalize, two MRs may want to optimize - Carlos sees that as compatible ---------------------------------------------------------------------- The Global HAHA Operation at the Interop Tokyo 2008 Ryuji Wakikawa - draft-wakikawa-mext-haha-interop2008-00 ---------------------------------------------------------------------- - Interop is a big conference / exhibition for networking vendors - Global HAHA was run as part of the show's network - RTT measurements were taken using direct (optimized) and standard MIP paths - Results are promising - Another global HAHA testbed is under work, the prefix is being advertised to the Internet using BGP - The testbed is open for anybody and they are open to collaboration. - Many references are included in Ryuji's slides (papers, websites, drafts, etc.) - Chan Wah asked about aggregation and how topologically-correct address enforcement will work - Pascal explained and Ryuji clarified that the HAs own the same prefix; Chan Wah argued that injecting prefixes is not allowed; Pascal used the example of Nagano Olympics that this is possible - Someone asked who owns the prefix; answer didn't help - Xiaoming Fu asked what the testbed is for; it looks like its functioning and performance is dependent on topology and where you put CNs. What does the testbed show? - Ryuji says it shows how HAHA works in real networks - Suresh Krishnan asks hwo the active HA can be determined, and Ryuji + Pascal's explanation is that the distribution of the HAs is crucial. Everyplace you have an SGSN, you'd have an HA if you were to do this for phones. - Serkan Ayaz asked if the primary HA fails, do the end nodes still communicate? ---------------------------------------------------------------------- The Design Consideration of Correspondent Router Ryuji Wakikawa - draft-wakikawa-mext-cr-consideration-00 ---------------------------------------------------------------------- - Triggering route optimization is difficult since MR and CR are both intermediate to the end nodes in a flow - Carlos - in the aero draft, the MR should be the one who decides - MR has no idea how long the session should continue (how long bindings should last) - CR discovery is also difficult - Binding registration to CR is difficult since the CR and MR can belong to difference administrative domains, and verifying the ownership of the whole prefix is more complicated than verifying a single address - Routing between MR and CR and between CR and CN can also be tricky - Pascal adds 2 issues: - 1) MR may have a burst of control for all RO sessions with each CR rather than a single BU when the MR moves - 2) in general (not for aviation), people would not like a handset to bypass a service providers own services for route optimization in the network - discussion between Pascal and Marcelo about the route exchange between HAs - Carlos brings up the trigger again, saying it's not possible with global HAHA (it's all or nothing) - Ryuji lists many questions that are needed to answer in order to define CR techniques ---------------------------------------------------------------------- DHCPv6 Prefix Delegation for NEMO Ralph Droms - draft-ietf-mext-nemo-pd-00 ---------------------------------------------------------------------- Existing standards have a gap in getting the mobility prefix to the MR. Prefix delegation has benefits from automated management, renumbering, etc. There are questions about security; DHCPv6 security is suggested but not required, and there are some issues with DHCPv6 security BUT it can be extended if needed. We need to understand the security requirements. - Julien mentions that the ipsecme WG will help with one of the issues here - Vijay says integrity protection is all that's required, and no shared key can be assumed - Pascal mentions that sometimes the HA is not the DHCP server, so the SA may not be correct - Jean-Michele says that this was his question; Julien explains that we have to secure the link no matter where the DHCP server is. Ralph clarifies that the assumption is that the HA and DHCP server are under the same administration, so the HA may act as a relay, but it's under control of the network operator. Jean-Michele - will this cover all the operational scenarios? Ralph - I can't imagine one that it doesn't. - If you think of a scenario that doesn't work, post to the list. Kent agrees with Ralph. Julien says the link between HA and server is not specific to NEMO, it's a DHCPv6 issue. Marcelo summarized the idea is to leverage on the existing SA, and leave the HA-to-server link for others. - Ralph says there is not much complexity required, nor is full DHCPv6 needed. - DHAAD is suggested for extension, though there are alternatives suggested. Jean-Michele objects, DHAAD is not secure. Vijay says DHAAD is default, and we have fallback mechanisms, error codes, etc. so there is no need to extend any of the HA discovery mechanisms when we add a new feature to the HA. Pascal says that the RFC (whatever number) doesn't have security, so if the message is already forged, it cannot be even more forged through lack of DHAAD security. Ralph proposes separating use of DHCPv6-PD from DHAAD, since they could work without changes to each other, but perhaps not be optimized. Julien says let's decide and not push that off. Unknown says DHAAD has value and would like to see it remain. Approach #1 - Try to get prefix via DHCP and if it doesn't work, try another server? Approach #2 - Use DHAAD extension DHAAD Approach - 4 hands. Ask-and-retry approach - 4 hands. A LOT OF PEOPLE DON'T CARE Ryuji points out that MCoA works without DHAAD extension. Marcelo - how many people think this is completely irrelevant and that we should just pick one and move forward? - No strong support on this from the room either Decision made to go to mailing list. Anyone who doesn't like the text in the draft needs to send notes to the list. Vijay pointed out that the text in question was thought to be removed before becoming a WG item. It was pointed out that the IPsec VPN people have had exactly this same problem previously. ---------------------------------------------------------------------- TUESDAY, July 29, 2008 1300-1500 Afternoon Session I ---------------------------------------------------------------------- ---------------------------------------------------------------------- Residual threats MIPv6 Suresh Krishnan - draft-haddad-mext-mip6-residual-threats-02 ---------------------------------------------------------------------- Jari comments on the potential ways to block a MN for attacks with BU's for incorrect CoA's Suresh agrees there are many solutions for this problem. Hannes: Nice document, problem is much of MIP6 is not deployed. Its better to see some deployments and see the relevance of the threats and not publish some guides. Marcelo: Is it useful to have a document. Most people agreed to have one doc and now is the question is this doc sufficient. Hannes: Not good to publish docs, if there is a problem fix it. Some of these things are more academic. Talks about tunnel broker. Suresh: We cant wait for ever for solutions. We need to have a doc on the threats George: Do we need to have a doc that stays for ever. It will be useful to describe the document if we are going to do some thing about it. Raj: Agree with Hannes. When MIP6 protocol was described, we had lengthy analysis ... Its better we dont scare people from deploying MIP6. Its just an acadamic excercise. Alper: Agree, there should be a living document. We keep updating Ryuji: Threat about Multiple coa is explained in the MCOA draft. Its better not to have the same text in multiple docs. Jari: I agree with Hannes. If there are new problems, we should document it. Focus on new problems, just having a new opinion or the document on the known problems is not useful. Gabriel: Some of these may go into 3775-bis Security Considerations section ---------------------------------------------------------------------- RADIUS Mobile IPv6 Support Avi Lior - draft-ietf-mip6-radius-05 ---------------------------------------------------------------------- Hannes: I need some feedback on the operational side. HA using IKEv2 with pre-shared key ...what will be the deployment mode ? Vijay: We dont know. IKEv2 with EAP stands out. I'd like to see PSK to disappear and certs to disappear as well. Alper: There is alternative to this approach, key is provided to HA and not exposing all these... There is AAA interaction but only for authorization. Vijay: I agree with Alper, based on the pre-shared Pre-shard key is clearly assumed in all specs. AAA must support the key delivery, for bootstrapping case. Marcelo: Suggests Avi to write the issues and post it to ML. ---------------------------------------------------------------------- RFC3775bis Charles Perkins - draft-ietf-mext-rfc3775bis-01 ---------------------------------------------------------------------- 1. Issue-1 related to seq Number was discussed. Jari, George, Hesham, Ahmad, Vijay and Sri had some comments on this issue. There is a general agreement on the solution. Charlier will propose the text. 2. Issue-2 DHAAD deprecation discussed Sri asked the clarifying question, the DHAAD as a procedure is not going to be deprecaed, only few lines on text on security implications will be added. 3. Issue-4: Sitelocal Issue Jari says, we should state if the spec support ULA's are not. Marcelo: Is the proposal to make site-local to ULA's ? George: Do we really need non-global address in Mobile IPv6. Marcelo: I assumed that this disussion hapenned before. Jari: Its a different type of address and so the use-case is different. I'm ok with the text. The use-case is just a detail, it can be used. Vidya: Remove site-local, thats the simplest solution. ULA's come with other issues and that needs to be documented. So, just leave it at that. Changing site-local to ULA is risky, they are not inter changeable. Charlie: Lot of people agree with the text. Jari: WG should look at the text and comment. Suresh: Is ok with the change. It does not recommend ULA's ..so with hte warning, its ok. Its a valid text. Issue - 8: Issue - 9: Simultaneous Mobility Ashutosh discusses the issue and explains the problem. Recommends option 4 listed in Charlie's slide. Issue 10: Usage of HA lifetime ---------------------------------------------------------------------- Generic Signalling Message Sri Gundavelli - draft-haley-mext-generic-signaling-message-01 ---------------------------------------------------------------------- Binding revocation Ahmad Muhanna - draft-muhanna-mext-binding-revocation-02 ---------------------------------------------------------------------- These two are discussed together and consensus in the room is that Binding Revocation shall NOT use the GSM framework. Rather, the consensus was that binding revocation shall use directly the mobility header and allocates its own MH types values. It was also commented that the Generic Signaling Framework scope and applicability are not well enough defined for the group to progress with that charter item. ---------------------------------------------------------------------- Flow/binding policies exchange Conny Larsson - draft-larsson-mext-flow-distribution-rules ---------------------------------------------------------------------- No comments, more people need to read the draft.