Re: [Mip4] Working Group Last Call fordraft-ietf-mip4-mobike-connectivity-00

[Vijay Devarapalli <vijay.devarapalli at azairenet.com>]

hi,

thanks for the review.

Yaron Sheffer wrote:
> - Bottom of Sec. 1: Passing large amounts of enterprise traffic through the
> DMZ should be avoided, not just from traffic engineering and performance
> reasons but also from security reasons.

in section 1, we currently have

   o  When the mobile node is on the trusted network, traffic should not
      go through the DMZ.  Current deployments of firewalls and DMZs
      consider the scenario where only a small amount of the total
      enterprise traffic goes through the DMZ.  Routing through the DMZ
      typically involves stateful inspection of each packet by the
      firewalls in the DMZ.

you want more text added to this to say there
are security reasons too? actually I am not
sure what the security reasons are. can you
please elaborate?

> - Address allocation is somewhat unclear. At the top of Sec. 3, "the mobile
> node is configured with a home address". While in Sec. 3.2 it is allocated
> an address an uses it as a CCoA (which is also more likely).

in the first case it is the home address we
are talking about. in section 3.2 we are
talking about the CoA. basically we leave out
HoA configuration as out of scope for this
document.

> - 3.3: Why should the MN send a RR when it changes its VPN gateway, if the
> TIA is unchanged? There's no way the HA can use this information.

you are right. if the TIA in unchanged, there is
no need to send a registration request. I guess
I assumed that if the VPN GW changes the TIA also
changes. we could change the text to say

   If the TIA changes due to the mobile
   node re-connecting to the VPN gateway or attaching to a different VPN
   gateway, the mobile node should send a Registration Request to its
   home agent to update the binding cache with the new TIA.

> - Sec. 3.4 should point out explicitly that normal traffic MUST NOT be sent
> out when moving into a new subnet until the process of determining
> location/security is complete.

this is explained in detail in
draft-ietf-mip4-vpn-problem-solution-02. I wonder
if there is a need to repeat them. here is some
text we can add at the end of section 3.4.

   The mobile node should not send any normal traffic while it is trying
   to detect whether it is attached to the trusted or untrusted network.
   This is described in more detail in [10].

> - Please mention that a customized integrated IPsec+MIP implementation is
> required, e.g. so that the MN can force-send RR in the clear, bypassing the
> usual IPsec processing.

how about the following text?

   When the mobile node is attached to an untrusted network and is using
   an IPsec VPN to the enterprise network, the ability to send a
   Registration Request to the i-HA without VPN encapsulation would
   require some interaction between the IPsec and MIPv4 modules on the
   mobile node.  This is local to the mobile node and out of scope for
   this document.

Vijay

ps: you can find the latest text at
http://www.dvijay.com/ietf/internet-drafts/mip4/mipsec.txt


--
Mip4 mailing list: Mip4 at ietf.org
   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/