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

[Hans Sjostrand <[e-mail]>]

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? Since the (in my experience) by far most common 
roaming case is a guy (or girl) leaving his desk for a wireless network 
it's really interesting. And most of the wireless networks are 
considered insecure. I'd really like some description and requirements 
for the home access mode before advancing the document.

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?

A "MAY" is of course ok to have for the really, really eager ones. 
Please add one for clarity.

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?

I've missed a lot of IETF meetings so I'm not that updated on the dual 
tunnel draft. Is the plans to advance it or scrap it? It's timed out in 
the draft repository. Have anyone implemented it? Sorry if I'm missing 
some obvious information or kicking in open doors. But I think it's 
relevant information in this context.

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. But I think this sentence is a 
potential 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.

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.

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.

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/