Re: [Mip4] review of draft-devarapalli-mip4-mobike-connectivity-00.txt

[Sami Vaarala <[e-mail]>]

Hi,

>> The problem I see w.r.t. to using IKEv2/MOBIKE is that it does
>> not, alone, match the current problem statement.  The assumption
>> made in draft-ietf-mip4-vpn-problem-statement-03.txt is that
>> existing deployed VPN infrastructure should be used (see e.g.
>> Section 5.1).
>>  
>>
> Yes. I still view that as the main and most urgent
> use case, so the problem statement is OK. However,
> I believe we are also at a situation where we can
> see future deployments (particularly those based on
> IKEv2) start to do new things. I don't see a problem
> with pursuing two tracks simultaneously. Its not
> like they would be two redundant solutions, its more
> like points in different stages of evolution.

Right, I agree.  And I agree we can pursue two tracks at the same
time.  However, given that these two tracks have so much in common,
it doesn't seem useful to specify them in two seemginly separate
specifications.  Given the way the solutions are specified,
x-MIP + IKEv1 vs. MOBIKE + IKEv2 are just two different access modes.
The overall approach, the intranet detection, etc, are all same.

But stepping back a little, if we relax either the "existing VPN"
or "minimal MIPv4 changes" assumptions, we get a number of different
solutions.  For instance:

    - A *very* straightforward way of getting mobility without x-MIP
      (and just IKEv1+IPsec) is just to use the "implicit ESP update"
      mechanism already deployed by some vendors.  I believe a similar
      mechanism is used in the MIPv6 + IPsec draft.  This is rather
      simple to implement and does away with the x-MIP overhead
      completely.

    - We could specify IKEv1 mobility extensions to allow more or less
      the same effect albeit with more vendor effort.  Vijay's draft's
      Appendix has a suggestion for this.

    - Looking at x-MIP, we can also eliminate x-MIP overhead completely
      by defining an optimization extension between the MN and the x-HA.
      This approach retains FA support, while eliminating all x-MIP
      overhead in non-FA scenarios.  The rough approach was described in
      draft-vaarala-mip4-optudp-00 [*].

    - A very important concern in practice is managing the keys and
      authentication in a dual MIP or MOBIKE+MIP solution.  Should we
      define something to make this easier?

At least to me it's not at all clear which avenue would produce the
best possible solution - minimal changes, maximum impact, and maximum
generality (especially).  So going past absolute minimum changes (dual
MIP) needs more thought on what criteria we should apply to solutions.

>> If we decide that there is no deployment issue w.r.t. MIPv4 and
>> already deployed VPNs, we should IMO take a larger view of
>> improving MIPv4/VPN coexistence.  Minimizing overlap between
>> the two mechanisms would give a much better solution.  For
>> instance, there is room for improvement in MIPv4 packet overhead,
>> MIPv4/VPN compression interactions, and integrated MIPv4/VPN
>> packet authentication.
>>
> I believe we will eventually get there. Probably step
> by step, however. I view Vijay's draft one of those
> steps... eliminating one unnecessary level in the stack.
> Or are you arguing that we should spend more time thinking
> what to do, if we discard the no-changes-at-all
> assumption?

I think we should work on defining what the longer term goal is w.r.t.
IPsec and MIPv4 integration.  I don't think it's clear people agree
what that goal should be.  And proposing, discussing, and comparing
solutions beyond dual MIP is difficult at the moment, because we have
nothing to compare them against.

As far as dual MIP is concerned, going forward with it would be useful
as a baseline and as documenting existing practice (as far as I know,
some people are deploying it, although I'm not sure at what scale).
But if we agree on working on a better long-term solution, that would
of course be preferable to working on a limited dual MIP solution.

Best,

-Sami

[*]
http://users.tkk.fi/~svaarala/publications/draft-vaarala-mip4-optudp-00.txt


-- 
Mip4 mailing list: [e-mail]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/