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

[Jari Arkko <[e-mail]>]

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