Mobility for IPv4 BOF (mip4) Monday, July 14 at 0900-1130 ============================== CHAIRS: Basavaraj Patil <Basavaraj.Patil@nokia.com> Gabriel Montenegro <gab@sun.com> Phil Roberts <proberts@megisto.com> NOTE: MIP4 is in the process of being approved as a working group. Final approval MAY happen before Vienna IETF. Details, work items, chairs, etc are likely to change. All presentations slides are available at the following web site. http://www.mindspring.com/~bpatil/IETF57 /MIP4_MIP6_MIPSHOP_Slides/ San Fran: discussion on next steps in IP Mobility Proposal of 3 BOFs: MIP4, MIP6, MIPSHOP AGENDA bashing Discussion on Charter and potential work items: 15 min Presenter: Chairs Charter Highlights Interoperability of existing implementations Look at proprietary extensions Progressing the MIPv4 base spec to draft standard Completion of AAA Key exchange for MIP AAA-NAI completion and MIPv4-AAA review Dynamic HA assignment discussion VPN Solution for MIPv4 completion Samita: LPAS document? Should we publish as an informational document? KLeung: some draft Gopal: MIP depends on auth from the client. In WLAN, there is a lot of auth, fast auth, etc. Would it be something that the WG would consider to take advantage of this to do mobility? Raj: if you could frame the question as something the WG could discuss, maybe... but, we are trying to limit the scope of the charter. Gopal: not fast handoff, but it is a fundamental change in the way you look at mobility. Maybe you don't have MIP client on your laptop. Gabriel: 2 things: one is to have L2 triggers with authentication. other thing: how to implement mobility on nodes that don't implement mobileIP Gopal: so how do you take charge of a L2 trigger, second is how do you use some information to detect that MN has moved independent of MIP stack ThomasNarten: might be related to BOF on dna later in the week. What does it have to do with this WG here? This is Mobile IPv4 specific things. Gopal: biggest deployment problem is Mobile IP client stack. We can enhance existing framework to handle nodes without MIP stack. KLeung: applies well to interoperability issue. Key thing is adding support for non-MIP clients using MIP infrastructure. Thomas: That's interesting, but it's a big change. Not clear that this group should be the ones looking at it. Kleung: people are doing this already, sometimes proprietary signaling. Gabriel: everything so far has been mobile initated. Not sure there's scope for network initiated. Gopal: it is a mobile initiated, just not MIPv4 initiated. Raj: the reason you would like to do this is because of the difficulty of deploying MIPv4 on you laptop, right? Gopal: there is work going on elsewhere. Raj: trying to figure out what is the proprietary implementations of MIPv4, see if there is enough interest in this working group to standardize some of these ErikN: when you do this, you have to change home agents too, right? Gopal: there are ways not to change any HA code at all and still make it work. Or, there are ways to make it work better. RajeshKumar: have worked on IPSec agent implementation. As far as MIPv4 clients are concerned, haven't seen any incompatibilities There are a lot of L2 switches that a number of vendors are trying to build. This is mobility at L2, they are not using network layer. No issue with compatibility of Mobile IP. Gopal: LAN switches & VLAN switches: sometimes layer 2, but sometimes layer 3 RajeshKumar: no, L2 is L2, if you do L3 you need MIP. ErikNordmark: dynamic HA issue: might want to configure more things when you connect to your home ISP. enroll BOF, Is there synergy between these efforts? Gab: that point will be explored a bit more in the MIP6 BOF. Heard about enroll, doesn't seem to help that much for handoff from one HA to another, but might help with the initial case. Raj: other thoughts on the charter? Eric (FranceTelecom): Working documents, low latency handoffs? Raj: completed by WG, consensus make it experimental. WG would no longer work on it. We just have a milestone to get it to the IESG & publish it. VPN Design Team Update: 20 min Presenter: Gopal Dommety Problem Statement Draft DT version is finished Security review by Radio Perlman Draft is published draft-ietf-mobileip-vpn-problem-statement-req-03 The I-D which will be completing WG LC before the meeting has been revised following reviews by the Mobile IP security advisor (Radia Perlman). The intent is to provide a status update on the problem statement as well as discuss any LC comments/issues that may be identified Solution Base Solution (no IPSec changes) Optimizations (some changes for efficiency) Base Solution - work completed Need security review Last Call for base solution after security review and Problem Statement review by WG and IESG Optimizations to be completed before next IETF Problem Statement details 16 page draft IP Sec VPN is used to access the Enterprise network How do you get seamless mobility when moving from one hotspot to another or to wide area provider Mobility from one subnet to another inside enterprise Transition from inside enterprise to outside and back Figured out all the various placements of IPSec, Home agents, firewalls, foreign agents. The one that made most sense is: HA deep inside enterprise network VPN at the access concentrator Issues and requirements Without FA: the IPSec SA needs to be renegotiated on movement With FA: FA cannot modify/process IPSec packets from the MN Problem statement draft includes: Issues that need to be addressed for providing seamless mobility in this scenario Requirements for the solution Working Group Last Call RajeshKumar Requirements document is pretty complete Solution draft covers detail (42 pages) but to go to last call people will need some time to review all solutions Gab: only problem statement is about to go to last call. One comment: "seamless" here might be inappropriate Gopal: a little marketing on my part, will look into it VPN solutions discussion: 20 min I-D: draft-ietf-mobileip-vpn-problem-solution-02.txt Presenter: Sami Vaarala of Netseal The design team has discussed a number of options in the solution space. This agenda item is aimed at presenting the conclusions reached and the reasoning behind the choice being made. VPN solutions draft Conclusions and rationale Document a base approach with minimal changes to standards Optimizations considered (but postponed) We need a home agent inside the enterprise We need an external mobility agent IPSec does not have standardize mobility (SA endpoint update)and we want "seamless" mobility even when outside We need to support FAs in the external networks => the lowest layer must speak MIP Some problems left out of scope for now e.g., network with only HTTP access Three layer solution Topology External home agent + firewall + internal home agent First step: discovering whether inside or outside. Send RRQ to external and internal HA, get response from only internal HA. When MN is outside Send RRQ to both external and internal HA, get response only from external HA Then run IKE, VPN address assignment Then run RRQ inside tunnel to internal HA. Must use reverse tunneling to internal HA External movement is handled just by external HA/Mobile IP Pros and Cons of 3 layer solution Pros Only MN is aware No changes to IPSec of MIPv4 Cons Overhead (latency, packet size) Three layers to manage (e.g., authentication) Software complexity Three layers != three boxes Combined VPN + HA box possible Status -02 missing some comments; pending security review George Tsirtsis: do the HA's need to be close to the firewall? Sami: no Charlie What you are assuming, is that it is difficult to make the internal HA visible to the firewall. Typically, firewalls do permit visibility to an internal host. Sami yes, but we are assuming that we have to go through IPSec gateway Charlie why? Maybe packets to HA would not need to be IPSec protected, nothing prevents you from using IPSec to the HA This solution goes beyond complex to fantastically complex Sami: if each HA were part of the security perimeter, our solution would be simpler, but very hard to achieve in practice. but yes we would like to work on optimizations. Henrik: using IPSec directly to the HA is one way, but is not acceptable to many network administrators. We don't have to work on it in any case because it's already supported by standards. If we have to pick one, this is it. Kleung: this is one reason we need a deployment WG. RajeshKumar: Generally, VPN manufacturers are a bit different from mobility vendors It's very hard to get someones IPSec client to work with someone else's software. Given that, don't foresee that some vendor will be able to deal with all different IPSec implementations. So implementation of firewall will be separate from HA for some time. Gopal: complexity is a very relative term. This is a pretty simple solution. Gabriel: any implementation experience? Sami: yes, some, it's doable with client in Windows. It's not too easy but it's possible. It has been used in practice already. Henrik: Birdstep has one commercially available, we have one internally available Gabriel: seems like this would have a certain overhead even if you are internal, right? You have to wait for both registrations to detect where you are, and there are some retry issues. Sami: yes, but strategy is that if you get a response back from the internal HA, you just forget about external HA. If external one responds first, you can accept it optimistically, or retry a few times. Gabriel: you can maybe use some L2 information Sami: yes, you might keep a table of MAC addresses but need to keep in mind security Charlie: intended to be a solution to work without changing administrative practice As it's presented, it seems to say that this complicated solution is the base solution, and benefit is that you don't have to change anything. I would request to present this solution as a trade-off. One is to admit packets to go back to the HA. HA is supposed to deal with security. It is reasonable to suggest to a firewall administrator that they allow packets to go to HA unprotected. Thomas: charlie's point is a pretty good one, you should have an applicability statement. If you are willing to punch holes in the firewall, maybe you can have a slightly more efficient solution. [more discussion back and forth between gopal & charlie & thomas...] Sami: we will clarify for next draft. Dynamic HA discussion: 20 min I-D: draft-kilkarni-mobileip-dynamic-assignment-01.txt Presenter: Kent Leung Capability already deployed in some wireless operators Optimal Home Agent for geographically/topologically distant locations Reduce configuration needs on Mobile Nodes (HA pre-assignment not required) Allow network to select and administratively assign HA to MN Load balance MNs among multiple HAs Hope to accomplish before next IETF Finalize WG charter and chairs Settled by 4 weeks from the end of the meeting Short WGLC on Low Latency handoff in July To IESG in August Progress AAA keys and NAI Interactions with AAA WG RFC 3012bis to IESG in August MIPv4 problem statement to IESG pete: security quesiton is the most important one, yes. but this problem of configuring a SA across domains is very hard. in pp2 we don't have it yet cuz we're waiting for aaa keys and aaa-mipv4 henrik: why both all 0's and all 1's, why not choose 1? pete: diam mipv4 applic did make a difference we don't, we only allow assignemtn in the home domain, but eventually we want to have it also request in the foreign domain panasonic: would like to see more security discussion kent: yes, but we don't want to get tied down to only one method charlie: why not use the initial HA makes the encoding instead of the AAA (analogous to AAA keys). so do you insist on leaving it open? kent: yes charlie: but for example, which SPI to use? there's a roadmap with the AAA drafts, why not use it? kent: not diff from 3344 charlie: yes different, additional parameters to store and transport, in 3344 each HA-MN requires a different MSA ??: route optimization to solve this? kent: you need one ha already. here you don't need to have anythijng configured raj: the point is if you wish to keep the ha closer pete: this draft should not go forward without a security solution. it really should be part of the same roadmap as aaa keys and aaa-mipv4. and not comfortable with sharing one MSA for a group of HA's kent: aaa is not the only way to do it pete: but it should have at least one way of doing it raj: pick a specific method, perhaps the aaa-mipv4 application, but there's need for a solution cuz the current rfc3344 won't quite work Roadmap ------- thomas: finalize WG and chairs within 4 weeks Narten: Status of AAA keys? Tom: most comments addressed, but Lifetime field not used. Charlie: sporadic mention of route optimization for MIPv4, but charter seems to be crafted to exclude it. Under what circumstances would it become a work item? Raj: haven't necessarily seen as much interest. Need to generate interest on mailing list. Gabriel: we were looking at aggressively reducing the number of items. Narten: we should focus on issues where theres deployment experience/issues. Working group needs to come up with criteria for when there is real interest. Real interoperability problems for deployment. Kent Leung: (maybe controversial, but) could we consider Experimental message types similar to VSAs, but act as feedback to standardization. Raj: similar to VSAs that we already have KL: not an extension, but a message type Narten: there are some numbers to use for experimentation/testing, if obstacles we can talk about it. Raj: other items, 3012 bis Gab: reminder that Wednesday morning is MIP6/MIPSHOP IRTF BOF: registration desk 10pm tonight Dave Johnson: Mobicom 2003, Sep 14-19, San Diego http://www.sigmobile.org/mobicom/2003/ |