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

[Vijay Devarapalli <[e-mail]>]

Hans Sjostrand wrote:
> Hi,
> 
> Sorry for being late. There are a few things in the draft that I would 
> like to have clarified before agreeing to sending it to IESG.
> 
> 1. Access mode home seams to be forgotten.
> 
> In figure 1 there is a access mode called {home}, but I can't find it 
> described anywhere in the document. Is the access mode forgotten or 
> omitted on purpose? 

The {home} in the figure refers to the fact that the
link on which the i-HA is present is the home link.
It is not an access mode. There are only four access
modes even in draft-ietf-mip4-vpn-problem-solution.

> 2. Whats a few milliseconds worth?
> 
> In section 3.2 there is a line stating "The mobile node attempts Foreign 
> Agent discovery and CoA address acquisition through DHCP simultaneously 
> in order to avoid the delay in discovering a foreign agent when there is 
> no foreign agent available.". Apart from not complying with the RFC 2119 
> keywords rules, I read it as a statement. The sending of a solicitation 
> and waiting for an advertisements is normally a case of split seconds. 
> Why start a DHCP cycle which only saves a couple of milliseconds an then 
> rely on DHCP servers which normally introduces in order of magnitudes 
> longer delays?

Discovering a FA might take more than a few
milliseconds, especially if the FA does not send
out agent advertisements frequently and the mobile
node has to solicit for agents on the link. If the
mobile node is soliciting by sending agent
solicitations it can take upto 3 seconds before it
can conclude that there is no foreign agent on the
link.

> 3. Dual tunnel a normative reference
> 
> In my mind the references to the dual tunnel draft can't be considered 
> as only informative. The internal/external detection is pretty central 
> to this solution. And leaving the security consideration section to an 
> informative draft I would assume is a bit OTT. It will be very hard to 
> progress this draft through IESG without the dual tunnel draft also 
> being advanced in the same time. Comments on that?

This makes sense. I don't remember why I had
draft-ietf-mip4-vpn-problem-solution as an
Informative reference. Could be because the status
of draft-ietf-mip4-vpn-problem-solution might have
been unknown.

> 4. Movement detection and security.
> 
> In section 34. there is a sentence stating "Whenever the mobile node 
> detects that it has moved to a new IP subnet [9] and its IP address 
> changes". Again a lack of keywords. 

This sentence just describes what the MN must do.
What would you like to see here?

> But I think this sentence is a 
> potential security problem. 

Can you elaborate a little bit more on the security
problem?

> It's not about subnets. It should be crystal 
> clear that ANY detection of network movement whatsoever MUST result in a 
> state that a security boundary may have been crossed and it sends a 
> Registration Request to the i-HA.

Even when there is no subnet change? Why?

> 5. Internet FA's
> 
> In this draft it seams that FA's on internet is silently ignored. 
> Atleast those are not mentioned anyware that I find. I assume this is 
> because the solution doesn't work with internet FA's. I think this is a 
> limitation that might be worth mentioning.

If the mobile node does not have an external Home
Agent that it can reach when it is attached to an
untrusted network, it cannot obviously use the FA
on the untrusted network. If there is an external
home agent that it can use, then
draft-ietf-mip4-vpn-problem-solution would apply.

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

Vijay

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