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/
|