Re: [DMM] Requirements

[Alper Yegin <[e-mail]>]

Looks good, thank you Anthony.

Alper

On Nov 6, 2013, at 4:47 AM, h chan wrote:

> Motivation:
> Various attacks such as impersonation, denial of service,
> man-in-the-middle attacks, and so on,
> may be launched in a DMM deployment.
> For instance,
> an illegitimate node
> may attempt to access a network providing DMM.
> Another example is that
> a malicious node can forge a number of signaling messages
> thus redirecting traffic from its legitimate path.
> Consequently,
> the specific node is under a denial of service attack,
> whereas other nodes do not receive their traffic.
> Accordingly,
> security mechanisms/protocols providing access control,
> integrity, authentication, authorization,
> confidentiality, etc.
> can be used to protect the DMM entities
> as they are already used to protect
> against existing networks
> and existing mobility protocols defined in IETF.
>  
>  
> H Anthony Chan
>  
> From: Alper Yegin [mailto:[e-mail]] 
> Sent: Tuesday, November 05, 2013 6:32 PM
> To: h chan
> Cc: dmm
> Subject: Re: [DMM] Requirements
>  
> 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 MUSTbe 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:[e-mail]] 
> 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: [e-mail] [mailto:[e-mail]] 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
>  
>