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

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Tue, 19 December 2006 19:59 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwl7E-0002KB-QL; Tue, 19 Dec 2006 14:59:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwl7C-0002K4-Sl for mip4@ietf.org; Tue, 19 Dec 2006 14:59:06 -0500
Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwl7B-0003ke-F2 for mip4@ietf.org; Tue, 19 Dec 2006 14:59:06 -0500
Received: from [127.0.0.1] ([66.92.223.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Dec 2006 11:59:04 -0800
Message-ID: <45884487.2050209@azairenet.com>
Date: Tue, 19 Dec 2006 11:59:03 -0800
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Yaron Sheffer <yaronf@checkpoint.com>, Hans Sjostrand <hans@ipunplugged.com>
Subject: Re: [Mip4] Some comments on WGLC: draft-ietf-mip4-mobike-connectivity-01.txt
References: <200612171106.kBHB6H67001776@michael.checkpoint.com>
In-Reply-To: <200612171106.kBHB6H67001776@michael.checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 19 Dec 2006 19:59:04.0291 (UTC) FILETIME=[2274DB30:01C723A8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: mip4@ietf.org
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

Hi Yaron,

Yaron Sheffer wrote:

>>> 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?
>>
> Because you can get an address on 192.168.0.0/16 from the enterprise DHCP server on the LAN, and immediately later another address on this subnet, or even the same one, from the untrusted WLAN (which uses a different NAT). This can be detected through layer-2 indications, but there are weirder cases when even that won't work.

Implicit in my reply was that DNAv4 (RFC 4436) is
used for movement detection. With DNAv4, the mobile
node will be able to detect movement to another subnet
for the scenario you mention above.

Hans Sjostrand wrote:
>>>
>>> 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.

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

Ok. We will go with what 3344 says. Here is the new
text in section 3.4

    Security boundary detection is based on the reachability of the i-HA
    from the mobile node's current point of attachment.  Whenever the
    mobile node detects a change in network connectivity, it sends a
    Registration Request to the i-HA without any VPN encapsulation.

This will also remove the reference to RFC 4436.

Vijay





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