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

["Yaron Sheffer" <yaronf at checkpoint.com>]

Hi Vijay,

Please see my comments below.

	Yaron

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay.devarapalli at AzaireNet.com]
> Sent: Wednesday, April 26, 2006 1:37
> To: Yaron Sheffer
> Cc: 'Pete McCann'; 'Mobile IPv4 Mailing List'
> Subject: Re: [Mip4] Working Group Last Call fordraft-ietf-mip4-mobike-
> connectivity-00
> 
> 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?
> 

Moreover: the DMZ architecture assumes that the DMZ is less secure than the
internal network. Therefore the architecture allows the least amount of
traffic to traverse the DMZ, that is, only traffic between the trusted
network and the external network. Requiring all normal traffic to the mobile
nodes to traverse the DMZ would negate this architecture.

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

Yes, this is better.
 
> > - 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 add the above text.

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

Great.

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