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

[Vijay Devarapalli <[e-mail]>]

hi Jari,

thanks for the review.

Jari Arkko wrote:
> 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.

thanks.

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

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

yup.

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

I didnt understand the above. ??

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

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.


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

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.

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

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?

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

okay.

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

okay.

Vijay


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