[MEXT] draft-bajko-mext-sod-01
"Kent Leung (kleung)" <kleung@cisco.com> Thu, 10 February 2011 04:04 UTC
Return-Path: <kleung@cisco.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id D722B3A6850 for <mext@core3.amsl.com>;
Wed, 9 Feb 2011 20:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.498
X-Spam-Level:
X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100,
BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3DHbMcgbxK6 for
<mext@core3.amsl.com>; Wed, 9 Feb 2011 20:04:51 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by
core3.amsl.com (Postfix) with ESMTP id 9A68C3A6867 for <mext@ietf.org>;
Wed, 9 Feb 2011 20:04:51 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com;
dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAPfyUk2rRN+J/2dsb2JhbACCSqMgc59amyyFXASEf4op
X-IronPort-AV: E=Sophos; i="4.60,450,1291593600"; d="scan'208,217";
a="257905301"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com
with ESMTP; 10 Feb 2011 04:05:02 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
[128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id
p1A452lt013599 for <mext@ietf.org>; Thu, 10 Feb 2011 04:05:02 GMT
Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by
xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675);
Wed, 9 Feb 2011 20:05:02 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01CBC8D7.B108492F"
Date: Wed, 9 Feb 2011 20:03:15 -0800
Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520E0A8085@xmb-sjc-235.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-bajko-mext-sod-01
Thread-Index: AcvI13EVOsLIM6H0RGuabPoQ0C4Syw==
From: "Kent Leung (kleung)" <kleung@cisco.com>
To: <mext@ietf.org>
X-OriginalArrivalTime: 10 Feb 2011 04:05:02.0602 (UTC)
FILETIME=[B129C6A0:01CBC8D7]
Subject: [MEXT] draft-bajko-mext-sod-01
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>,
<mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Feb 2011 04:04:56 -0000
In the last IETF meeting, I signed up to review this draft and provide my comments to the WG. Some may already be discussed. 1) Sect. 1: s/cellular accesses/cellular access networks/ 2) Sect. 1: "that would unnecessarily consume resources on the HA and radio resources on the access network" 3) Sect. 1: HA control is mentioned in "Furthermore, the operator of HA may have policies .. security is to be used". But later "HA has no ability to force the MN to secure user traffic". Clarify if SoD is designed to include HA control in addition to MN control. 4) Sect. 2: s/wifi_SSID/WiFi SSID/ 5) Sect. 2: Why MAC_address of the wifi network? Generally, it's the WIFI SSID. Probably better to cover general logic and not get into specific features. 6) Sect. 2: "MN has either a stored policy ... or it may be provided with such information from policy stores such as ANDSF [23.402] or AAA server ..." There is no interface between MN and AAA server. So not clear how MN is able to obtain info stored on AAA server. Also, PCRF may be another policy store. 7) Sect. 2: "HA may require that the user plane traffic be encrypted on the MN-HA link". No description of how this can be accomplished. 8) Sect. 3: 'S' bit indicates encryption for user traffic. But it's not clear how encryption can be applied? 9) Sect. 3: What happens if MN does not encrypt after HA overwrites with S bit set to one? 10) Sect. 3: What happens if MN encrypt when HA does not want that? 11) Sect. 3: There is no description of HA triggered SoD, though HA control was implied in Sect. 1. 12) Sect 4.2: What this option is in the draft? Location information can be used for many types of operation, not specific to SoD 13) Sect. 5.: Hmm, Type value reservation needs IANA. 14) Sect. 6: It's not clear if there is no impact to the security model until further explanation provided on how the encryption is applied. Overall, the I-D is a good start on the idea of SoD. It needs more clarification on how the S bit interact with the mechanism that actually provides the encryption/decryption function. Also, how does SoD work when IKE/IPSec is providing the encryption/decryption. Kent
- [MEXT] draft-bajko-mext-sod-01 Kent Leung (kleung)
- Re: [MEXT] draft-bajko-mext-sod-01 Basavaraj.Patil