RE: [Mip4] Some comments on WGLC:draft-ietf-mip4-mobike-connectivity-01.txt

["Narayanan, Vidya" <[e-mail]>]

 

> -----Original Message-----
> From: Hans Sjostrand [mailto:[e-mail]] 
> Sent: Monday, December 18, 2006 10:00 AM
> To: Narayanan, Vidya
> Cc: [e-mail]; Vijay Devarapalli
> Subject: Re: [Mip4] Some comments on 
> WGLC:draft-ietf-mip4-mobike-connectivity-01.txt
> 
> Comments in the end.
> 
> >>> Besides that, a good assumption is often a good idea.It's a
> >>>       
> >> bit hard
> >>     
> >>> to know of a FA is inside or outside. Thats why we wrote
> >>>       
> >> RFC3846. We
> >>     
> >>> have been using a RFC3846 agent NAI in  FA's to make an
> >>>       
> >> educated guess
> >>     
> >>> if it's a intranet FA or a internet FA. It's maybe 
> therefore a good 
> >>> idea to reference RFC3846 "Mobile IPv4 Extension for
> >>>       
> >> Carrying Network
> >>     
> >>> Access Identifiers" and describe how agent NAIs could be used.
> >>>
> >>> In our solution, if the suffix part of the FA NAI is known as an 
> >>> intranet identifier to the MN, then teh MN go against the i-HA.
> >>>       
> >> The Agent Advertisement is not protected. So I am not sure 
> we should 
> >> be using the NAI extension from RFC 3846, unless rogue 
> foreign agents 
> >> on a link are not considered possible.
> >>
> >> Another option is for the MN to always acquire a CoA from 
> the access 
> >> network and send a registration request to the i-HA.
> >> Once the MN detects that it is attached to a trusted 
> network, it can 
> >> switch the FA CoA mode if an FA is available on the 
> trusted network. 
> >> Will this work for you?
> >>     
> >
> > This seems to be the only thing that will work for this 
> draft. Here is 
> > what I had said in one of my earlier emails to Henrik on this topic:
> >
> > "If the MN is moving from an untrusted network, it needs to first 
> > acquire an IP address, try reaching the HA with it; if the 
> HA is not 
> > reachable, use that address as the VPN tunnel outer 
> address; if it is 
> > reachable, either operate in CCoA mode or then use an FA and 
> > re-register with the FA. OTOH, if the MN is moving from a trusted 
> > network, it may use an FA first; determine that the HA is 
> unreachable, 
> > subsequently acquire an IP address and set up a VPN. "
> >
> > I think the draft can use some text on this. 
> >
> > Vidya
> 
> Formally you are right Vidya. Thats why I thought it was a 
> good idea to introduce an "educated guess".
> 
> If you, for example via RFC3846 advertisements, recognize 
> that you most probably are inside you could start by 
> registering with the i-HA. And vice versa, if you make an 
> educated guess that your outside, then you could start of by 
> doing a VPN tunnel.
> 

The problem is that if there are any statements about using
RFC3846-style FAAs, the document also has to talk about security issues
with masquerading FAs. I'm not sure that is worth getting into. But, I'd
be fine with such text, as long as the security implications are
appropriately pointed out. 

Regards,
Vidya

> This is however completely informational and it's only about 
> handover performance. It's only the IKE mobility exchange and 
> the MIP registration exchange that is valid indications of 
> actual location and security policy to apply.
> 
> We should not mandate behavior here, the specification should 
> be open for implementation.
> 
> Best regards
> /// Hasse
> 
> 
> 
> 
> 
> --
> Mip4 mailing list: [e-mail]
>     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: [e-mail]
    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/