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

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 27 Apr 2006 18:52:08 -0400

Hi,

The document looks OK to me. So it should progress as intended.

One comment: having the MN send MIPv4 registration request outside of
the VPN tunnel may increase setup time. This will happen if the MN has
moved into an un-trusted network.

If the MN has a VPN tunnel, why not having it send MIP4 RRQ over the VPN
tunnel? 

Thanks,
Kuntal

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]]
> Sent: Monday, April 24, 2006 8:50 AM
> To: MIP4 Mailing list
> Subject: [Mip4] Reminder: Working Group Last Call fordraft-ietf-mip4-
> mobike-connectivity-00]
> 
> Hi,
> 
>   This is a reminder regarding the WG last call on the mip4-mobike-
> connectivity
> draft, which ends this Friday.
> 
> Please indicate whether you support sending this draft up for
publication
> or not.
> 
> Regards,
> 
> 	Henrik
> 
> 
> -------- Original Message --------
> Subject: [Mip4] Working Group Last Call for	draft-ietf-mip4-mobike-
> connectivity-00
> Date: Fri, 14 Apr 2006 12:25:27 -0500
> From: Pete McCann <[email-masked]>
> To: Mobile IPv4 Mailing List <[email-masked]>
> 
> 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/

-- 
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: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Apr 2006 17:29:05 -0700

hi Kuntal,

> moved into an un-trusted network.

the MOBIKE update message and the registration
request without VPN encapsulation to i-HA
will be done in parallel. if the i-HA replies
with a registration reply, then it means the
MN is attached to the trusted network.

> If the MN has a VPN tunnel, why not having it send MIP4 RRQ over the VPN

once the MOBIKE update is done, a registration
request is sent over the VPN tunnel too.

security boundary detection based on i-HA
reachability is described in more detail in
draft-ietf-mip4-vpn-problem-solution-02.txt.
see section 3.3.

Vijay