[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