[Mip4] Draft BOF Minutes

[Pete McCann <[e-mail]>]

Hi,

Attached are the draft minutes for the MIP4 BOF.  If anyone has
additions/corrections, please send them.  I will be submitting these
early next week.

-Pete


Mobility for IPv4 BOF (mip4)

Monday, July 14 at 0900-1130
==============================

CHAIRS:	Basavaraj Patil <[e-mail]>
	Gabriel Montenegro <[e-mail]> 
	Phil Roberts <[e-mail]>

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/



_______________________________________________
Mip4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mip4