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

From: Jari Arkko <[email-masked]>
Date: Mon, 22 Aug 2005 18:23:44 +0300

Hi Pasi and Vijay,

I finally found time to read this draft. Overall, I like it
a lot. Some of its good properties include simplicity,
minimal changes to both existing VPN plumbing and
MIPv4 systems, and the separation between the two.
I support taking this work forward.

Technical:

> 3.  Solution Overview

I started to wonder whether there's something here
that would apply in similar manner to Mobile IPv6. There
does not appear to be any specific dependency on Mobile
IPv4 here. Doing the same for Mobile IPv6 appears to
be possible, although doing VPN + IPsec-based
home agent security would imply nested IPsec tunnels.
Interestingly, with v6 RO you could eliminate the
second (inner) tunnel in your solution.

But perhaps that discussion falls under the scope of
the v4-v6 interoperability scheme.

In any case, I think it would be useful to think about
this matter in order to ensure that we don't have
too fragmented solutions (this works for v6 only;
that you can do only if you also access a corporate
VPN; it connects v4 and v6 but doesn't work if you
combine it with VPNs; etc).

> 3.4  Crossing Security Boundaries
>
>    Security boundary detection is based on the reachability of the i-HA
>    from the mobile node's current point of attachment.

I think it would be useful to recognize that there
can be other sources of information. I like the fact
that you have defined one mandated scheme here
but its quite possible that there will e.g. L2 assist
or configuration information in some cases; lets
not rule that out.

> 3.4.1  Operation when moving from an untrusted network

Is there a need to talk about the specific SPD policy
settings that are necessary to enable MIPv4
operations to be carried through a VPN tunnel?

Or are we assuming (the most often used)
all-or-nothing VPN model?

> 3.4.2  Operation when moving from a trusted network

Lets remember that MOBIKE has mechanisms not
just for movements, but also for multihoming support
and the ability to detect problems. I suppose there
has to be some specification here about the
interaction between problem detection mechanisms
in MIPv4 and MOBIKE -- unless we are restricting
this spec to situations where we get information
from L2 that we have moved.

> Appendix A.  Mobility Extensions for IKEv1

I would rather not see this defined in this document.
Personally, I'd favor recommending an upgrade to IKEv2,
but if that's not sufficient then it would make sense to
have a discussion elsewhere in the IETF (maybe in the
MOBIKE WG or on the IPsec mailing list) about whether
this is needed, and how it should be provided.

Editorial:

>    typically, separated by a DMZ.  Access to the intranet is controlled

Expand DMZ on its first occurrence.

>    1.  Initiate IKE mobility exchange to update the current address with
>        the VPN gateway.  If the new network is also untrusted, this will
>        be enough for setting up the connectivity.  If the new network is
>        trusted, and if the VPN gateway is reachable, this exchange will
>        allow the mobile node to keep the VPN state alive while in the
>        trusted side.  If the VPN gateway is not reachable from inside,
>        then this exchange will fail.
>    2.  At the same time as step 1, send a Mobile IPv4 Registration
>        Request to the internal Home Agent without VPN encapsulation.
>    3.  If the mobile node receives a Registration Response to the
>        request sent in step 2, then the current subnet is a trusted
>        subnet, and the mobile node can communicate without VPN
>        tunneling.  The mobile node MAY tear down the VPN tunnel.

Maybe renumber these "1a", "1b", and "2" for clarity (or something
similar). Other occurrences later in the document, too.

--Jari

-- 
Mip4 mailing list: [email-masked]
    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/

---

From: Sami Vaarala <[email-masked]>
Date: Mon, 22 Aug 2005 20:21:22 +0300

Hi Jari,

> I support taking this work forward.

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).

As far as I can see, this makes IKEv1 support mandatory, which
is reflected in the current VPN solution draft (essentially the
same mechanism, but uses an outer MIPv4 layer to compensate for
lack of IPsec mobility support).

If we drop the "deployed VPN" requirement, we're defining a new
solution for the problem.  Such a solution does not ease the
perceived MIPv4 deployment issue of existing VPN infrastructure.
I'm not sure the perception is correct, but it was included in
the problem statement because several vendors thought it was
relevant.

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.

As discussed in earlier e-mails, I believe that:

  1. A solution document should address current VPN deployment.

  2. There are multiple VPN technologies currentl in use.  For
     instance, let's not forget L2TP/IPsec which probably accounts
     for a sizable chunk of deployments.

  3. Because no new protocols are needed specifically for MIPv4/VPN
     coexistence, the most appropriate way of dealing with the
     solution space would be an applicability statement of existing
     protocols for the enterprise scenario.

Best,

-Sami

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 25 Aug 2005 16:51:21 -0700

hi Jari,

thanks for the review.

> I support taking this work forward.

thanks.

> IPv4 here. 

yes its possible. infact in 3GPP2-WLAN IW, this is already
being considered. a MIPv6 tunnel with a HA through an IPsec
tunnel with the PDIF. I thought about writing up a draft
for MIPv6 too, but nobody is asking for it right now. :)
also for MIPv6, it might make sense to collapse the VPN
gateway and the HA into the same box.

> Doing the same for Mobile IPv6 appears to

yup.

> combine it with VPNs; etc).

I didnt understand the above. ??

> or configuration information in some cases; lets

very true. we hint about this in the draft.

    There could also be some out-of-band mechanisms that involve
    configuring the wireless access points with some information which
    the mobile node can recognize as access points that belong to the
    trusted network in an enterprise network.  Such mechanisms are beyond
    the scope of this document.

> all-or-nothing VPN model?

I prefer the MIPv4 signaling messages and the IP-in-IP packets
appearing to the IPsec tunnel as ordinary traffic. if the
all-or-nothing VPN model is not used (very rare), then we need
to add selectors so that the MIPv4 signaling messages and
IP-in-IP packets are not discarded.

> from L2 that we have moved.

I think this is implementation specific. the mobile node could
get information from multiple sources, MOBIKE, MIPv4, L2,
802.21, etc... the host implementation on the mobile node should
decide what to do with the information from all these sources.
we shouldnt venture into specifying how they can work together.
what do you think?

> this is needed, and how it should be provided.

okay.

> similar). Other occurrences later in the document, too.

okay.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sun, 28 Aug 2005 12:28:50 +0300

>existing deployed VPN infrastructure should be used (see e.g.
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.

>MIPv4/VPN compression interactions, and integrated MIPv4/VPN
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?

--Jari

---

From: Sami Vaarala <[email-masked]>
Date: Sun, 28 Aug 2005 17:30:27 +0300

Hi,

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

> what to do, if we discard the no-changes-at-all

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