Last Modified: 2005-01-17
|Nov 03||Problem statement documents (to IESG): (1)- Issues with firewall; (2) - Mobile IPv6 transition between v4/v6 networks|
|Jan 04||Bootstrapping problem statement to IESG|
|Feb 04||Submit MIPv6 MIB to IESG|
|Mar 04||Alternate Route Optimization scheme to IESG|
|May 04||Home agent reliability to IESG|
|Aug 04||Bootstrapping solution to IESG|
|Nov 04||Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering to IESG|
|RFC3775||Standard||Mobility Support in IPv6|
|RFC3776||Standard||Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents|
Minutes of MIP6 WG meeting
Minneapolis, MN USA
Monday, March 7th 2005, 1930-2200
Chairs: Basavaraj Patil and Gopal Dometty
Minutes provided by: Suresh Krishnan
Alper: wants to change the order of item 4 and 5 since framework needs to be covered before the solutions. Patil: Thinks the order is fine as 4 is very specific and will not be affected by the choice of the framework
* Authentication protocol and MN Identity options drafts completed WGLC.
Security ADs have raised DISCUSSes
IDs to be revised to clarify the motivation (why do we need these?)
3gpp2 has a critical dependency (already past deadlines)
* Preconfigured kbm draft is awaiting AD review and feedback
* RO security was reviewed by Elywn. Gabriel and Pekka to do the fixes
* Lots of comments about bootstrapping in the ML
* CN IPSEC draft needs WF review before going to WGLC
* IKEv2 ipsec needs reviews from ikev2 experts
Extension to Sockets API for Mobile IPv6
Samita Chakrabarti presenting
No major issues left, just editorial ones. New ID to be issued to fix WGLC issues working with cairs and ADs
AD evaluation comments pointed out that a clearer applicability statement is needed.and a switch is required on the socket apis to do source address selection. say CoA vs HoA
Needs implementation info to make progress maybe from HUT or WIDE).
Implementors need to contact chairs/authors
Targeted for INFORMATIONAL
MIP6 operation with IKEv2
Vijay Devarapalli presenting
A whole bunch of requirements have been relaxed
-> Support for Peer Authorization database, HoA configuration and EAP changed to MAY
-> Clarified that there is no need to use public key mechanism to authenticate HA if the chosen eap method already is mutual.
SA for the BU is not created until the first CREATE_CHILD_SA (requires 3 rtt rather than 2rtt)
SPD entries and dynamically allocated HoA (SPD uses HoA)
-> update SPD when the HoA changes
-> reinstall policy entries when the HoA changes
-> use a name in SPD and have name point to HoA
J. Jee wants a clarification about use of preshared keys as the method. Jari talks about adding a reference to a draft Hannes and Pasi have written about not needing to use PK when EAP mutual authentication is used.He also mentions that the draft has no home currently. Vijay will add the reference
MIP6 AAA framework
The goal of the draft is to identify various frameworks where AAA is used for mip6 service and agree on one or more to standardize
Alper talks about 4 different frameworks and the characteristics of each
Jee is concerened about preconfiguring the HA address and thinks dynamic assignment of HA is very important. Alper will talk about it later.
Vijay wants to know how DHCP server know which domain the MN belongs to? Alper thinks that it is immaterial. Will use DHCP ID to correlate
Vidya wants to know what happens if the NAS and HA do not belong to the same domain as the NAS shares SA only with AAA-L(visited)? Greg thinks that this can work transparently as there is a transitive trust relationship between AAA-L and AAA-H. Raj has the same view as Greg. Gopal wants to add info about AAA-H and AAA-L.
Jari wants to know how MN can know CoA and HA before initiating the procedure. Greg thinks that there is no need to know as the AAA can do the BU James wants to know how the AAA server can know where the prefix is.Greg thinks that it will come from the NAS. Alper thinks that this framework is workeable but complex.
There are three requirements for a solution to fulfill. HA discovery, HoA discovery, and MN-HA key generation
Hannes and Alper talk about how these frameworks can be mix-n-matched to satisfy these requirements
Jari is concerened about the impact caused on network since the goal is to reuse the exisiting AAA relationship. Client software, DHCP and NAS need to be updated to implement these solution.
Framework4: requires new aaa-mip6 application
Framework1: requires confirmation from ip conf sec bof
Framework2: needs new AAA attributes and PANA/DHCP options (*3gpp2 prefers this approach)
Framework3: Very complex and may not be justifiable
Alper wants direction from the WG to know which way to go. Gopal wants people to read the drafts and discuss on the ML
James Kempf presenting
Tries to address situations where loose trust between serving network access provider and Mobility Service Provider(MSP).e.g. enterprise networks, hotspots (As most of them use Credit Cards to authorize and not AAA), and for infrastructureless deployments as well.
John thinks that UAM (universal access method) is popular now but there are still backend AAA networks. He also thinks that 802.1x means more and more RADIUS as UAM does not work on small devices. James believes that CC based authentication is not going away and we need to support it. Jari thinks that this method does not fit a mobility scenario since the CC based authentication is used mainly for wireless nodes in hostpots (usually immobile).
The basic idea is for the MN to ask for DNS SRV records to get the HA address. Then IKEv2 is used to extablish MN-HA keying. Replay protection is provided by Message identity code in DNS (RFC1035) and data integrity and origin auth provided by DNSSEC.
Alper wants to know how the HA will authenticate the MN. James thinks it will be preprovisioned credentials like EAP username/password, preshared keys etc.
Alper is concerned about sharing the HA address with external networks.
James is not worried even though DNS has no authentication. He also clarifies that this is meant to be used in the absence of RADIUS.
Raj is worried about DNS caching HA address. Thomas is also concerned.
Hannes wants to decouple the two problems addressed in the draft 1) use IKEv2 for bootstrapping and 2) use DNS for discovery. He also suggests the possiblity of using multi hop PANA
James wants to use DNS TSIG (RFC2845) for protecting HA addresses. Thomas thinks that nobody needs this. James thinks that if addresses are hard to get it makes DoS harder. Thomas thinks that James is very unclear. He wants to know what is really being protected. MN from bogus DNS replies or the DNS server from bogus DNS requests? James says both scenarios are protected againt. Samita clarifies that DNSSEC is not deault and is optinal. Raj thinks this makes DOS attacks easier Thomas disagrees and states that he likes this solution. This is nice and simple instead of the other complex solutions. He compares publishing the HA address to Wells Fargo advertising its 1-800 Number.
Goals for AAA-HA interface:
Gerardo Giaretta presenting
The document describes design goals and requirements on the interface between AAA and the HA. The purpose of the document is to allow matching goals and frameworks.
Raj wants to know if the draft should become a wg item in its current form?
James supports the document but wants to wait for the output of the Bootstrapping Design Team(BSDT) to proceed further. Vijay disagrees (he does not want to wait). Alper wants to choose framework before doing this as he thinks that we cannot choose anything other than Framework with this.
Gopal wants to know if the goals are related mainly to bootstrapping. Gerardo says there are other goals like accounting. Patil and Gopal think that it is a good idea to do this independently as there are other goals.
Conclusion is that the I-D will be made a Working group draft. However it will not be progressed until the bootstrap design team has completed its work. Any input from the bootstrap work will be considered in the AAA-HA ID.
Location privacy in MIP6
Rajeev Koodli presenting
I-D: draft-koodli-mip6-location-privacy-00 and
Intro- specific scope for MIPv6
HoA - visible in all packets the MN uses it home or visited network
COA - visible at visited networks
Hoa COA could be profiled for activity
COA reveals roaming of a mobile node node when HoA is used
-can use privacy ext, to IPv6 (rfc3041)
- Can introduce additional MIP6 signalling ( when coa changes )
Using 3041 introduces DNS and IPSec considerations
DNS , IPsec (rekeying for change in Hoa)
- reverse tunnel data packets (to solve COA problem)
Privacy Label Computation
Don't send HoA in the BU in the clear - use in label
Label should be computable without the knowledge of HoA
Mobopts will discuss this initially and similar other proposals.
Conclusion: Mobopts will pick up this work and study it further. The resulting analysis will be presented to the MIP6 WG along with recommendations for solutions or best practices suggestions.
Raj wants to know if the wg should work on location privacy:
yes? about 30 hands
no? no hands
(CONSENSUS IN FAVOR)
IPv4 traversal for mip6 protocols
Vijay Devarapalli presenting
This is useful if the MN lands on v4 only access network. The MN registers IPv4 address as CoA using a new mobility option and can setup all types of tunnels. 6 over 4, ESP, UDP etc. Use same mechanism for mip6 and nemo.
Is there interest to do this in the wg?
Gopal thinks that we should discuss this for the next IETF. Greg thinks that it looks interesting. He thinks we should have a bar bof.
Next steps for WG
Gopal Dometty presenting
-> Address AD/IESG comments on auth option
-> Bootstrapping solution
solution ID by next IETF.
Close design team shortly after next IETF
last call and IESG by IETF64
-> MIP6 transition issues
Gopal wants an ID to document transition issues.
Vijay thinks it is a bad idea to write an all encompassing problem statement. Raj and Gopal agree with Vijay. Thomas thinks that this problem has been around for long and v6 v4 transition issues should be documented by someone who ACTUALLY has a problem. Otherwise we will have a huge problem space. Gopal wants to define the problem space to be as narrow as possible. Thomas wants to agree on the scope of the problem before solving it
->work with mobopts to define and suggest privacy solutions
->propose revision to milestones
Rajeev wants to know the timeline for the mobopts work. Gopal mentions that it should be done before the next IETF.
A Scheme of Mobile firewall in MIP6
Qiu Ying presenting
The idea is for the HA to control the activities of the MN in a visited network.
Raj wants to know if this is applicable only with HMIP. Qiu says it is. He also mentions that it is a scenario to illustrate out a general scheme.
PF_KEY between MIPv6 and IPsec/IKE
Shinta Sugimoto presenting
MIP6 uses IPSEC to protect signalling messages. SA pairs need to be established and tunnel mode SAs need to be updated when the CoA changes. MIP6 may not have direct access to the SADB.
Defines a new PF_KEY message called MIGRATE
PF_KEY MIGRATE requires update of SAD and SPD
This has already been implemented
Vijay thinks this is very good work. Hannes has worked on a similar document which is more generic and wants a slot to talk about it.
(OUT OF TIME)
Raj mentions a draft from James/Vijay about HA unavailable message which is sent when a HA is going down. It needs to be discussed in the ML (END OF MEETING)
People referenced in minutes
Basavaraj Patil (Raj)
Gabriel Montenegro (Gabriel)
Pekka Nikander (Pekka)
Elwyn Davies (Elwyn)
Vijay Devarapalli (Vijay)
Junghoon Jee (Jee)
Jari Arkko (Jari)
Hannes Tschofenning (Hannes)
Pasi Eronen (Pasi)
Alper Yegin (Alper)
Vidya Narayanan (Vidya)
Greg Daley (Greg)
James Kempf (James)
John Loughney (John)
Thomas Narten (Thomas)
Gerardo Giaretta (Gerardo)
Rajeev Koodli (Rajeev)
Gopal Dommetty (Gopal)
Qiu Ying (Qiu)
Shinta Sugimoto (Shinta)