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

Hi Vijay,

some comments embedded.

Vijay Devarapalli wrote:
> 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.

I maintain that a mobile ip working document should describe the home 
mode. It's central and important. There are also other places where the 
FA and collocated away cases are described. But not the home case.

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

Firstly I don't think that a complimentary document should start 
defining MN behavior. That is regardless of handover performance. We 
should simple leave that to RFC3344. If you have concerns with handover 
performance and FA discovery, please take that in the RFC3344bis 
discussion. Do not write some new MN behavior in a complementary document.

A FA might for some reason not send out broadcast or multicast 
advertisements, thats true. But an FA SHOULD (section 2.3 in rfc3344) 
respond to Agent Solicitations. And a MN that doesn't solicitate on a 
new link seams a but passive in my mind, but thats implementation. In my 
experience a MN normally pics up a FA in almost notime.

>>
>> 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. 
> 4. Movement detection and security.
>
> This sentence just describes what the MN must do.
> What would you like to see here?

Again, I don't think that we should define up new behaviors. RFC3344 
states.
-    A mobile node SHOULD initiate a registration whenever it detects a 
change in its network connectivity.

Thats pretty good for me. It's then up to each implementation to make 
it's own determination what "network connectivity" means.
>
>> But I think this sentence is a potential security problem. 
>
> Can you elaborate a little bit more on the security
> problem?

RFC4436 openly admits "In general, adjustment of the security 
configuration based on DNAv4 is NOT RECOMMENDED.". Therefore, assuming 
that they'll do the trick is a bit optimistic. I think there are quite a 
few security considerations to be elaborated here.

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

Assume that you are on a trusted network. And the computer associates 
with a new BSSID (i.e. a different AP than before). What would you have 
wanted your VPN vendor to do.
a) Accept the new nice AP that so kindly did let you in and continue to 
send clear text traffic.
b) Stop sending traffic until a registration procedure against the i-HA 
has made it clear that no security boundary has been passed.

My choice is clear. And I think the RFC4436 guys agree since they point 
out that arp and dhcp is NOT a security feature. Therefore, subnets are 
not the for making sure security boundaries are crossed or not.

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

There are no external home agent in this context. Atleast not in the 
terminology the solutions part of the document that I read through. It 
was just a suggestion to be fair to readers of this document that an 
internet FA is unusable and if one is detected it should discarded as a 
possible agent. Not a big thing.

>
>> 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
>
I know that advertisements isn't protected, thats why I sued works like 
"assumption" and "educated guess". This was probably more 
implementation. A smart implementation could make assumptions and 
educated guesses but it's ok for me to leave it at that.

Please, no new requirements for MN behavior to acquire a CoA or not.

Regards

/// Hasse

-- 
Mip4 mailing list: Mip4@ietf.org
    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/