Subject: [Mip4] Comments on draft-ietf-mip4-vpn-problem-solution-01

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Oct 2005 02:34:43 -0700

hi,

I dont have too many comments. the draft is in a very good
shape already.

some high level comments first.

- this draft is ready for a WG last call (or has it been
done already?).

- there is a lot of text on emphasizing why we need a dual
MIP layer. I understand the need for it, but I wonder if it
is too much. the problem statement draft talks about this too.

- I think it would be a good idea to add some text on running
multiple instances of Mobile IPv4. from our implementation
experience, it has not been easy dealing with multiple
instances of MIPv4 and two different home addresses (and two
MIPv4 NAT traversals at the same time). infact it is an
implementation nightmare.

>    This document outlines the proposed solution for the Mobile IPv4 and
>    IPsec coexistence problem for enterprise users.  The solution
>    consists of an applicability statement for using Mobile IPv4 and
>    IPsec for session mobility in corporate remote access scenarios, and
>    a required mechanism for detecting the trusted internal network
>    securely.  The solution requires only changes to the mobile node;

should be explicitly mentioned here that changes are not
required for the VPN GW and the HA.

>    changes to Mobile IPv4 or IPsec are not required.

/s/Mobile IPv4 or IPsec/Mobile IPv4 or IPsec protocols/

>    o  must support foreign networks with only foreign agent access;
>    o  should not require changes to existing IPsec or key exchange
>       standards;

/s/standards/protocols

>    o  must adhere to the Mobile IPv4 protocol (but may require new
>       extensions or multiple instances of Mobile IPv4); and

I am not sure what is meant here. what is "adhering to the MIPv4
protocol"? make minimal changes?

> 1.7  Why IPsec lacks mobility

should section 1.7 be re-written now that there is a MOBIKE protocol?
but ofcourse there is none for IKEv1 and not all IKEv2 implementations
may support MOBIKE. but atleast acknowledge.
> 
> 3.3  Proposed algorithm
> 
>    When the MN detects that it has changed its point of network
>    attachment on a certain interface, it issues two simultaneous
>    registration requests, one to the i-HA and another to the x-HA.
>    These registration requests are periodically retransmitted if reply
>    messages are not received.
> 
>    Registration replies are processed as follows:
>    o  If a response from the x-HA is received, the MN stops
>       retransmitting its registration request to the x-HA and determines
>       it is outside. 

we should say here the MN 'tentatively' determines that it
is outside. only confirmed once it gets no response from
the i-HA.

> 3.5  Rationale

for?

> 5.3  Latency considerations
> 
>    TBD: rewrite this section.

theres an empty section.

> A.1  Connection setup for access mode 'cvc'
> 
>    The following figure illustrates connection setup when the mobile
>    node is outside and using a co-located care-of address.  IKE
>    connection setup is not shown in full, and involves multiple round
>    trips (4.5 round trips when using main mode followed by quick mode).
> 
>     MN-APP      MN        x-HA       VPN        i-HA        CN
>      !          !          !          !          !          !
>      !          ! -------> !          !          !          !
>      !          !  rrq     !          !          !          !
>      !          ! -----------------------------X !          ! rrq not

isnt this dropped in the DMZ itself?

Vijay

-- 
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: Tue, 18 Oct 2005 01:01:54 +0300

Hi Vijay,

Thanks for the review, comments below.

Vijay Devarapalli wrote:
>[...]

I agree.  Some text was added on request earlier but should
be pruned now.

> implementation nightmare.

Do you have a suggestion for text (and where to put it)?

I guess the difficulty depends somewhat on product architecture.
If both MIPv4 and VPN layers are part of the same code base, it's
not such a big deal.  But if the VPN layer is from a third party,
it can surely get hairy.

> required for the VPN GW and the HA.

Ok.

> /s/Mobile IPv4 or IPsec/Mobile IPv4 or IPsec protocols/

Ok.

>>    o  should not require changes to existing IPsec or key exchange

Ok.

> protocol"? make minimal changes?

The intent, I think, is that the solution must not change the semantics
of existing MIPv4 specifications.  Admittedly vague.

> may support MOBIKE. but atleast acknowledge.

Agree.

> is outside. only confirmed once it gets no response from

Ok.

>>    TBD: rewrite this section.

Will deal with these in next revision.  We did have a latency
considerations section in an earlier revision but it was removed
because it was a bit unclear and in need of a rewrite.

> isnt this dropped in the DMZ itself?

Yes.  The attempt is to indicate the intended destination with the line.
The end result is misleading.  I'll fix it.

Best,

-Sami