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

Hans Sjostrand <hans@ipunplugged.com> Mon, 18 December 2006 18:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMmt-0002Ix-P1; Mon, 18 Dec 2006 13:00:31 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMms-0002Is-U4 for mip4@ietf.org; Mon, 18 Dec 2006 13:00:30 -0500
Received: from 213.80.52.78.dataphone.se ([213.80.52.78] helo=mailgw.local.ipunplugged.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMmr-0002f0-0V for mip4@ietf.org; Mon, 18 Dec 2006 13:00:30 -0500
Received: from [127.0.0.1] (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id kBII0GpI004496; Mon, 18 Dec 2006 19:00:22 +0100
Message-ID: <4586D72F.2000103@ipunplugged.com>
Date: Mon, 18 Dec 2006 19:00:15 +0100
From: Hans Sjostrand <hans@ipunplugged.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: "Narayanan, Vidya" <vidyan@qualcomm.com>
Subject: Re: [Mip4] Some comments on WGLC: draft-ietf-mip4-mobike-connectivity-01.txt
References: <C24CB51D5AA800449982D9BCB90325133C901D@NAEX13.na.qualcomm.com>
In-Reply-To: <C24CB51D5AA800449982D9BCB90325133C901D@NAEX13.na.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on mailgw.local.ipunplugged.com
X-Virus-Status: Clean
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: mip4@ietf.org, Vijay Devarapalli <vijay.devarapalli@azairenet.com>
X-BeenThere: mip4@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility for IPv4 <mip4.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mip4@ietf.org>
List-Help: <mailto:mip4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mip4>, <mailto:mip4-request@ietf.org?subject=subscribe>
Errors-To: mip4-bounces@ietf.org

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.

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