Re: [DMM] Requirements

Alper Yegin <alper.yegin@yegin.org> Wed, 06 November 2013 02:31 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9563421F9D94 for <dmm@ietfa.amsl.com>; Tue, 5 Nov 2013 18:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikPIyLxmGTEG for <dmm@ietfa.amsl.com>; Tue, 5 Nov 2013 18:31:53 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id AB19A21E8113 for <dmm@ietf.org>; Tue, 5 Nov 2013 18:31:44 -0800 (PST)
Received: from [10.119.8.3] (178-211-44-68.turkrdns.com [178.211.44.68]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MF4yZ-1VOjYo0oA7-00GOMw; Tue, 05 Nov 2013 21:31:43 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_35DD3948-4B52-4B62-9F66-4F35CBB94EE0"
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <6E31144C030982429702B11D6746B98C370D776E@szxeml557-mbx.china.huawei.com>
Date: Wed, 06 Nov 2013 04:31:37 +0200
Message-Id: <101C778B-D174-40D6-BA06-54AC51B97A32@yegin.org>
References: <660E41D7-7F6A-47B4-86CE-C00ECA136DA8@yegin.org> <6E31144C030982429702B11D6746B98C370D7705@szxeml557-mbx.china.huawei.com> <E11B6E84-6BD7-4E9D-B8DE-25BCEA6E30C9@yegin.org> <6E31144C030982429702B11D6746B98C370D776E@szxeml557-mbx.china.huawei.com>
To: h chan <h.anthony.chan@huawei.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:B3CT1tc7wYoBlikANg202CJKuCiP9CeJCrKwTkJy5fa bQLB8ZG8Ryi2oIzKv1mIV2V+eZqX28VqjRg2+H5VZBWvj36oZQ C9KOQh3RKQ+9KP1E7PcG5rwlT5d8oicIeBpZ6pPWLk3eXs/dhG +CXoFfrvtBiSlc7U+zmT7zQqZ3/uBrSwqwe3pNFaI/xcdpfc0R AmK7w6TKqJAshMuiD4eUlE/wn/AfsStf7lciXfYefNcWkTwntX 2YYBGq8D3wH5QNht7g17PTK7XyhtDbxgOP1Imr/y259QPwEEcQ pI4SCDIzJ+4SDX6QBOIgg3QNj3QD8cd5BQc7JDTAWYb20nhrCC ZmtycTrPcO5vxqvOzFRghhYoRyRurepgCrtZ3eTgS
Cc: dmm <dmm@ietf.org>
Subject: Re: [DMM] Requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 02:31:59 -0000

Anthony,



> Alper,
> The sentence in question is not in the requirement but rather one of the sentences in the motivation of the requirement.

Unfortunately it's using normative language. Hence it reads like a requirement. 

 When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated. [1]



> When deleting that sentence, it affects the rest of the motivation and the requirement, which will not flow.
>  
> The security requirement is:
> [2] A DMM solution MUST not introduce new security risks
> or amplify existing security risks
> against which the existing security mechanisms/protocols
> cannot offer sufficient protection.
>  

This is a good requirement. We shall keep that. No problem with that.

My problem was with another statement ([1])



> This text was agreed upon by Byoung-Jo Kim.
> Do you have problem with it? Or do you have better wording?
>  
> My understanding is that a design that increases security risks is indeed a problem. Is that right?
>  


No problem with [2].

[1] seems to be broken, like I explained. 

Alper




> H Anthony Chan
>  
> From: Alper Yegin [mailto:alper.yegin@yegin.org] 
> Sent: Tuesday, November 05, 2013 5:08 PM
> To: h chan
> Cc: dmm
> Subject: Re: [DMM] Requirements
>  
> Hello Anthony,
>  
>  
>  
> Regarding:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
> My understanding of the intention is that it is sufficient to apply the existing security mechanisms/protocols to protect the DMM entities.
> Ideally, we don’t want DMM to add new security risks.
> Yet, DMM can introduce new DMM entities, which can be vulnerable to security risks, and it is necessary to protect the new DMM entities.
> So we basically don’t want DMM to introduce new security risks that cannot be handled with the existing security mechanisms.
>  
> If the wording “considered to be eliminated” does not clarify the above, how about the following:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be eliminated."
>  
> Or, can you come up with better text prior to Friday. I am trying to close all requirements issues prior to the meeting on Friday to enable the wg to move to the next step.
>  
> I recommend we delete that sentence. It's not easy to understand. And if I try hard to understand, what I understand does not make sense.
> It sounds like the following:
> - There are already security solutions applied to legacy/existing/non-DMM solutions.
> - Those solutions must be sufficient for securing DMM solutions.
> - In other words, DMM solutions must be designed in such a way that they must not require any new security solutions.
>  
> That does not make sense, IMHO.
> Obviously, we'd like to minimize the work. We prefer not having to design additional stuff to secure DMM solutions.
> But we cannot mandate that.
> We shall not block solutions that may require additional security mechanisms. We can discourage that, but not prohibit.
>  
>  
>  
> Regarding your comment on the helpful references, I understand that there are many other individual drafts in the solution space. I did recently accept a prior comment to add the coloring reference. Yet now if we continue to respond to requests to add references to the individual drafts, it will not end. With the many individual drafts in the solution space, I hope the wg will have drafts that will merge/incorporate many solution drafts in future. May I now ask all the authors of the individual drafts to kindly wait for such future wg draft to consider what solutions to include/exclude?
>  
> I'm fine with that.
> I saw two drafts referenced in the I-D which are complemented by two other drafts, hence I proposed them. It's OK if you don't add them.
>  
> Alper
>  
>  
>  
>  
> 
> 
>  
> H Anthony Chan
>  
> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
> Sent: Monday, November 04, 2013 10:20 AM
> To: dmm
> Subject: [DMM] Requirements
>  
> Hello folks,
>  
> Here I have two comments on this document.
>  
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
>  
> I don't quite understand what that means. 
>  
> "Infrequent node mobility coupled with
> application intelligence suggest that mobility support could be
> provided selectively such as in [I-D.bhandari-dhc-class-based-
> prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
> the amount of context maintained in the network."
>  
> Two more related work references that are complementary to the ones already provided are:
> - draft-yegin-dmm-ondemand-mobility-00
> - draft-liu-dmm-mobility-api-01
>  
> I recommend we include these references as well.
>  
> Alper
>  
>