Mobility for IPv6 BoF (MIP6) ---------------------------- Wednesday, July 16 2003, 0900-1130 Reported by: Eva Gustaffson (eva.gustafsson@ericsson.com) and Koojana Kuladinithi (koo@comnets.uni-bremen.de) (with some edits by Basavaraj Patil) Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Gabriel Montenegro (gab@sun.com) Phil Roberts (proberts@megisto.com) Agenda: 0. Intro/Agenda/Tahi Test suite update 1. Charter discussion Chairs 2. Thoughts on Bootstrapping a mobile node securely Chairs 3. Alternate HA-MN Signaling Security Ideas Jari Arkko/Charles Perkins (No I-D) 4. Multiple Care-of Address Registration on Mobile IPv6 Ryuji Wakikawa (I-D: draft-wakikawa-mip6-multiplecoa-01.txt) 5. Extension to Advanced Socket API for Mobile IPv6 Samita Chakrabarti (draft-chakrabarti-mobileip-mipext-advapi-01.txt) 6. Backbone interoperability testing Philippe Cousin/Samita Chakrabarti General note: Because of time constraints the Socket API presentation and the backbone interoperability discussion were constrained significantly. -------------------------------------------------------- 0. Agenda/Tahi Test Suite Update -------------------------------------------------------- Only change to the agenda previously posted is the inclusion of the Tahi test suite update. Status of Mobile IPv6 WG I-Ds (base MIPv6 and MN-HA IPsec) clarified. All discuss items (by IESG) on the base spec have been clarified and closed. Awaiting Steve Bellovins approval on the clarifications provided for the MN-HA IPsec I-D. Hiroshi Miyata made an announcement of the availability of the Tahi test suite version 1.0 for Mobile IPv6 which is based on draft version 21. Version 2.0 is expected in October and will support draft version 24. -------------------------------------------------------- 1. Charter Discussion -------------------------------------------------------- Basavaraj Patil presented the highlights of the charter. The Primary goal: improve base spec and work on items critical to get MIPv6 deployable on large scale 1. Refine base spec based on implementations & interoperability experience 2. Split up base spec into smaller modular interworking pieces Work on items identified during development of base: 1. Bootstrap mechanism for setting up SAs between MN & HA 2. Improving HA reliability 3. Support MN changing of address 4. Alternatives to return-routability 5. Multicast support Discussion: Charlie Perkins: we might have more docs for security mechanisms, might take longer, may need to refine milestones later (these are tentative) Thomas Narten: if document is ready in advance of milestone no reason to delay Basavaraj Patil: charter is still being reviewed Hesham Soliman: need to consider MIPv4-v6 interaction; should be included in charter Basavaraj Patil: consider transition issues to be taken up in v6ops, more of a cross-area item Thomas Narten: is there a problem statement for this? Hesham Soliman: some work was done earlier, we can resubmit Thomas Narten: need a few pages summary why this is a problem George Tsirtsis: dual stack node works, but more can be done... Basavaraj Patil: charter is very focused, if you think this is important enough, write a problem statement Samita Chakrabarti: route optimization? Basavaraj Patil: this is the mandated mechanism in base spec Charlie Perkins: decision for separate MIPSHOP WG inconclusive, better to have just one WG, make work & progress easier, need a lot of interaction between the two, would be worthwhile consider making these two WGs the same, otherwise we get more work and less productivity Basavaraj Patil: people working on issues in the different groups are the same yes, but we separate the work into smaller groups to get more focus Charlie Perkins: which WG has broader scope? Basavaraj Patil: MIP6 Charlie Perkins: didn't seem like that; if we have one WG now we can split it up later, would be harder to join two groups later James Kempf: we've been working on drafts for last three years, not making progress, need to get done within next 6 months or this will never be done; easier to finish within 6 months with smaller groups Gabriel Montenegro: can we close this issue? Thomas Narten: has been a long discussion, in the end ADs have to make decision, decided to split, MIP has history of being big and unwieldy, lot on its plate already; hesitant to take on new stuff that is not core, don't want to overload one WG Charlie Perkins: we had a three year's sprint to get the base done, lots of things missing, ex multicast... Thomas Narten: these issues we can still work through, charter is to be put in front of IESG within three weeks -------------------------------------------------------- 2. Thoughts on Bootstrapping a mobile node securely -------------------------------------------------------- Gabriel presented the chairs thoughts on the bootstrapping problem. Discussion: What is it? Why do we do it? ... Hesham Soliman: lots of these comments are not benefits of bootstrapping, but of MIPv6 Gabriel Montenegro: we can discuss later, but there seem to be enough reasons to do bootstrapping Hesham Soliman: just using this doesn't prevent PKIs right...? Francis Dupont: our solution was to use AAA infrastructure; if you want to change addresses but keep peers... Gabriel Montenegro: Jari will talk about these issues in next presentation Hesham Soliman: AAA has to be there, utilize for key distribution, but propose to add normal IKE (public key based to use that) Basavaraj Patil: extend to bootstrap MSA... some credentials exist already? Gabriel Montenegro: yes, some security context exists; the assumption is that you have something to bootstrap off ...Cont presentation: further thoughts on dynamic MSAs, credential provisioning James Kempf: we need to do certificate profile, needs to be looked at Gabriel Montenegro: yes, there is some thought behind it, but we need a bit more; to verify Jari Arkko: worried about using certificates in some cases, sometimes authentiation not necessarily needs certificates... Gabriel Montenegro: yes... Jari Arkko: discussed with IKEv2 folks, IKEv2 has address assignment feature... Hesham Soliman: agrees with Jari's first comment, two addresses; first you be reached through, second 3041address (?) Gabriel Montenegro: first address is identifier (?), same sort of certificate might enable both Hesham Soliman: authorization issues are already been taken care of by HA.... if HA accepts certificate just because of trusting this certificate...? Gabriel Montenegro: the idea is that the HA doesn't know yet... Hesham Soliman: don't understand.... it's for the HA to decide who (what MNs) to accept Gabriel Montenegro: profile would specify ex where security anchor is to be Hesham Soliman: thought you were adding specifics to certificates.... Gabriel Montenegro: no Jari Arkko: wondering about pic, cleaner to do authentication directly with HA using this... only HA knows what addresses are allocated, however, don't really know where pic is going at the moment Alper Yegin: pic is closed, IKEv2 superceding pic work -------------------------------------------------------- 3. Alternate HA-MN Signaling Security Ideas -------------------------------------------------------- Presentation on "Alternate proposal for MIPv6 security" was done by Jari Arkko. He started giving a background to the specification requirements defined in draft-ietf-mobileip-mipv6-ha-ipsec-06.txt to configure the signaling protection using IPsec (and IKEv1/IKEv2), as well as without using IPsec. Discussion: Background, improvements on RR (most people want to improve speed...), suggestion: optional mechanisms allowed in addition to RR Hesham Soliman: possible to add CGAs in a way to eliminate care-of test Jari Arkko: specs are welcome... Charlie Perkins: not only speed, also simplicity and security (can get better with shared secrets than with return routability?) Jari Arkko: right, most of these schemes have some kind of tradeoff... however, we need most of these schemes Hesham Soliman: we took tradeoff of making sure it's secure, if we take a step back, do we want speed? Then what happens to previous assumptions? Different parallel contradicting specs? Don't want that, becomes interoperability nightmare Basavaraj Patil: as Jari said, this is optional Charlie Perkins: in case of shared secret, MIPv6 implementations do allow testing using shared secret Basavaraj Patil: all this is up for further discussion ...Cont presentation: new functions: addressing freedom, dynamic assignment of HAs Hesham Soliman: dynamic assignment of HA, what's the goal? AAA server will pick HA for you? Jari Arkko: yes, roughly, assign a completely new HA for you, addressing location privacy Basavaraj Patil: scope is not only assignment of HA, you can get assigned home address as well as HA Hesham Soliman: yes but we already have these mechanisms in HMIP, is this just copying MIPv4? Jari Arkko: no James Kempf: there is requirement that each MN has ability to use MIPv6, no requirement for ability to use HMIP Hesham Soliman: what's the requirement to do this with AAA? Jari Arkko: need for local HA Greg Daley: experimental protocol, work on this, come back to this later, seems a bit premature, Basavaraj Patil: not to go into MIPSHOP at this point Alper Yegin: options are not limited to home domain ...Cont presentation: HA-MN IKE-variant feedback, additional IKEv2 issues Francis Dupont: "move IKEv2 first then send BU in MIPv6", will not work, do not move SA... Jari Arkko: could you post details on this? Hesham inquired about possibility of eliminating CoA test with CGA. James mentioned that it is not sure, but for some cases, it might be possible. Charlie pointed out that there are most of schemes available to consider within this proposal. But, we have to consider the trade off between speed, security and also configurations. Basavaraj pointed that all those should be discussed within the WG. Hesham raised a question about the goal of DAHA (Dynamic Assignment of Home Agent) within this proposal. Jari told that it is not only finding the current HA, but also to keep the location privacy. Hesham told that it can be done within HMIP with AAA. Jari further explianed that it is not based on whether MN is in home domain or local domain. Jari mentioned about additional IKE2 issues that do not consider in the current MIPv6 draft. Francis Dupont mentioned that it is not the way to do this. -------------------------------------------------------- 4. Multiple Care-of Address Registration on Mobile IPv6 -------------------------------------------------------- Ryuji Wakikawa presented the "Multiple Care-of Address Registration on Mobile IPv6" I-D. He mentioned that this draft (draft-wakikawa-mip6-multiplecoa-01.txt) can be discussed within mip6 or nemo WG. He briefly went through motivation, CoA registration, Binding Management. Basavaraj mentioned that all drafts related to multiple CoA's, flow movement, multiple interfaces will be summarised in order to determine how to proceed in future. -------------------------------------------------------- 5. Extension to Advanced Socket API for Mobile IPv6 -------------------------------------------------------- Samita Chakrabarti presented the "Mobile IPv6 Advanced Sockets API". She briefly explianed what is MIPv6 sockets and updates from draft V00 to V01. In terms of next steps, she asked about creating a working group item within the mailing list. Basavaraj mentioned that this work item would be discussed with the IPv6 WG chairs and decided accordingly. Alper asked if this draft was going to be taken up by the Mobile IP WG and also wanted to understand how the other API draft (draft-yokote-mobileip-api-02.txt) would be considered by the WG. -------------------------------------------------------- 6. Backbone interoperability testing -------------------------------------------------------- Samita Chakrabrti and Philippe Cousin presented the testbed proposal for MIPv6 interop testing. Philippe explained the different types of testing focusing on event testing, MIPv6 permanent test-bed for ad-hoc remote testing & remote event testing. First draft on remote testing is available at www.etsi.org/plugtests. Samitha requested interested people to join the evening Bar BOF to duscuss further about Mobile IPv6 Internet testing ideas, specifically focused on having remote test-beds. |