Re: [Mip4] Summing up: draft-ietf-mip4-mobike-connectivity-01.txt

[Vijay Devarapalli <[e-mail]>]

McCann Peter-A001034 wrote:
> Here is an attempted round-up of the issues that have been discussed:
> 
> 1. Use of an FA
> 
> If the MN is on the trusted network, then an FA can be used.
> There was a proposal from Vidya to put in the following text:
> 
>    "If the MN is moving from an untrusted network, it needs to first
> acquire an IP address, try
>     reaching the HA with it; if the HA is not reachable, use that
> address as the VPN 
>     tunnel outer address; if it is reachable, either operate in CCoA
> mode or then use an FA 
>     and re-register with the FA. OTOH, if the MN is moving from a
> trusted network, it may 
>     use an FA first; determine that the HA is unreachable, subsequently
> acquire an IP 
>     address and set up a VPN. "
> 
> However, there was a complaint that this might be over-specification.
> Can the MN attempt to use an FA before it determines that it is on a
> trusted network?  It seems to me that this is ok, the Registration Reply
> will contain the MN-HA Authenticator if the FA can reach the HA,
> otherwise
> the MN will get no response or a response that fails the Authentication
> check.
> Personally I don't see the difference between the case of starting on an
> untrusted
> network vs. starting on the trusted network: the procedure could be the
> same.

Currently the draft already says

3.1.2.  Access mode: 'f'

    This access mode is standard Mobile IPv4 [2] with a foreign agent
    care-of address.  The mobile node can use this mode only when it
    detects that it is connected to an internal trusted network and also
    detects a foreign agent on the access network.

This addresses part of Hans' concerns about using
Internet FAs.

Now coming to the mobile node's behavior, there seems
to be consensus for the mobile node to always configure
a CoA, check reachability to the i-HA and and if
connected to a trusted network, may use a FA if one
available on the trusted access network. If we agree on
this, I can propose some text.

> 2. Bypass VPN for Registration Requests
> 
> There was discussion on whether it is feasible to bypass a VPN tunnel 
> for the Registration Request.  I think the discussion concluded that
> it was possible, but perhaps some text needs to be added describing
> the SAD.  Does anyone have some concrete text to propose?

I don't think any text is needed. You can bypass the
SPD using either a higher priority SPD entry with
source address set to the local IP address or using
some implementation specific mechanisms.

> 3. Security considerations for exposing the Registration Request
> 
> This one seems pretty simple, there is a short list of concerns that
> could be written into the draft.  Vijay, can you draft some text?

Sent updated text this morning.

Narayanan, Vidya wrote:
> One issue that I think is still open is support for multiple
> interfaces (simultaneous bindings clarification). 

The mobile should be able to use simultaneous bindings.
I wasn't planning to prohibit it.

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/