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

From: <[email-masked]>
Date: Fri, 28 Apr 2006 11:29:06 +0200

Hi Vijay, 

> [email-masked] wrote:
> > Hi,
> > 
> > In general I support the advancement of this draft as a proposed
> > standard. 
> 
> thanks.
> 
> > I have, though, few minor comments & questions:
> > 
> >  o The draft seems to be biased toward enterprise networks, at
> >    least from the used terminology point of view. However, the
> >    same solution would nicely fit e.g. into 'mobile operator'
> >    controlled and hosted network deployments as well (thinking
> >    e.g. 3GPP stuff here). Maybe few words about that would be 
> >    good to have.. or slight change of wording (like enterprise
> >    network -> trusted network etc)
> 
> its historical. MIPv4 has been working on
> Enterprise connectivity solutions using MIPv4 and
> VPNs for a while. so this was proposed an alternate
> solution when IKEv2 with MOBIKE is used to setup
> the VPN.
> 
> we could in the appendix describe how this can be
> applied to an operator's trusted/untrusted network.
> however, this would need WG consensus.

Some lines around this would be nice.

> >  o Is there a reason why the case "FA integrated into MVPN"
> >    has not been discussed? I have seen proposals like that.
> >    Few lines about why and why not would be useful.
> 
> FA on the VPN gateway? I see enterprise VPN gateways
> supporting IKEv2 and MOBIKE, but not foreign agents.
> so thats why it isn't in the draft. I also wanted
> to keep this spec simple.
> however, there is another draft that talks about
> this.
> http://www.ietf.org/internet-drafts/draft-meghana-mip4-mobike-
> optimizations-00.txt

Ok. I seem to have missed that draft. It might be worth at least
giving an informative reference to this draft.

> >  o section 3.4 discusses about how the MN detects it has crossed
> >    a security boundary. The current text only mentions that the
> >    IP subnetwork has changed. It is possibly a bit far fetched
> >    but in multi-radio MNs e.g. WLAN and GPRS interfaces can both
> >    be given IPs from same private subnets belonging to different
> >    operators (and thus different security 'domains'). 
> 
> I am afraid I didn't get this.

If you have e.g. a terminal with WLAN & GPRS and both radios enabled
simultaneously. Then it is possible that both interfaces are configured
with IPs from the same private subnetworks. So when the user roams
he/she might attach to a GPRS network managed by mobile operator A
(assigning IPs from 10.0.0.0/24) and to a WLAN network is operated by
ISP B (also assigning IPs from 10.0.0.0/24). So I was just wondering
whether this has any affect on the detection of crossing the security
boundary as described currently in the draft.

> > It's not
> >    clear to me that a case where the MN just decides to change
> >    the active interface is covered in 3.4.
> 
> aren't both networks trusted networks in the scenario
> you describe above?

Nope. In the above case the GPRS network could be considered trusted
while the WLAN not.

> Vijay

Cheers,
	Jouni

> 
> 
> > 
> > And some nits:
> > 
> >  o mVPN and MVPN are both used in the draft
> > 
> > 
> > 
> > Cheers,	
> > 	Jouni
> >  
> > 
> >> -----Original Message-----
> >> From: Pete McCann [mailto:[email-masked]] 
> >> Sent: 14. huhtikuuta 2006 20:25
> >> To: Mobile IPv4 Mailing List
> >> Subject: [Mip4] Working Group Last Call 
> >> fordraft-ietf-mip4-mobike-connectivity-00
> >>
> >> 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-co
> >> nnectivity-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/