Subject: [Mip4] Working Group Last Call for draft-ietf-mip4-mobike-connectivity-00

From: Pete McCann <[email-masked]>
Date: Fri, 14 Apr 2006 12:25:27 -0500

This message announces a WG last call on:

  "Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE"
  - draft-ietf-mip4-mobike-connectivity-00

The last call will conclude at 24:00 UTC on Friday, 28 April 2006.

draft-ietf-mip4-mobike-connectivity-00 describes the use of IKEv2 and 
MOBIKE in conjunction with Mobile IPv4 to offer secure connectivity to a 
protected network along with mobility.

A URL for this Internet-Draft is:

<http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity-00.txt>

Please respond to this WG last call:

* If you have no comments on the draft, and support its advancement,
   simply respond with a line containing something like

    "I support the advancement of this document to the IESG with a
     request for publication as proposed standard."

   If you have comments, please use a line similar to the one above, and
   supplement this with your comments.

* If you *don't* support its advancement, respond with a line containing
   something like the following, supplemented by your comments -

    "I don't support the advancement of this document to the IESG with
     a request for publication as proposed standard, for the following
     reasons:"
    ...

     Pete & Henrik

-- 
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: "Yaron Sheffer" <[email-masked]>
Date: Sun, 23 Apr 2006 19:09:54 +0300

Dear WG participants,

I support the advancement of this document, with the following comments:

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

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

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

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

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

- I would like to reiterate my conviction that having 3 different ways (or 3
drafts and maybe 4 ways) of mixing IPsec and MIP is anything but a clear
direction for the market. 

Thanks,
	Yaron

-----Original Message-----
From: Pete McCann [mailto:[email-masked]] 
Sent: Friday, April 14, 2006 20:25
To: Mobile IPv4 Mailing List
Subject: [Mip4] Working Group Last Call
fordraft-ietf-mip4-mobike-connectivity-00

<http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity-00.
txt>

     Pete & Henrik

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Apr 2006 15:37:16 -0700

hi,

thanks for the review.

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

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

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

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

> required, e.g. so that the MN can force-send RR in the clear, bypassing the

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

---

From: "Yaron Sheffer" <[email-masked]>
Date: Thu, 27 Apr 2006 14:36:12 +0300

Hi Vijay,

Please see my comments below.

	Yaron

> From: Vijay Devarapalli [mailto:[email-masked]]
> 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:

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.

>     home agent to update the binding cache with the new TIA.

Yes, this is better.
 
>     This is described in more detail in [10].

Please add the above text.

>     mobile node.  This is local to the mobile node and out of scope for

Great.

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Apr 2006 11:27:58 -0700

> nodes to traverse the DMZ would negate this architecture.

will add this text. thanks.

Vijay