Re: requirements and the security considerations

When you say the DMM requirements should only be on the risks added or amplified by DMM, my understanding is that such increased risks depend on the specific DMM solution. 

Then as I read the last sentence of the text from Jong Hyeouk:
Existing security mechanisms/protocols MAY be possible to provide sufficient security protections to DMM. For instance, EAP-based authentication can be used for network access security, while IPsec can be used for end-to-end security. Note that when the existing security mechanisms/protocols are applied to DMM, security risks that MAY be introduced by DMM MUST be considered to be eliminated.

If I understand your intention correctly, one way to spell the requirement on the DMM solution may be that the DMM solution MUST not introduce new risks or amplify the existing risks in a manner that cannot be handled with the existing security mechanisms/protocols. If we rephrase the requirement something along this line, does not capture your concern? The rest of the text from Jong-Heouk (access network to DMM etc.) can be modified so as to simply examples of these existing risks as well as some existing security measures. The requirement is only not to introduce new risks other than these existing ones. 

If it is okay, the next question is whether we allow solution that does increase/introduce more risks. If so, they must also provide the security measures to handle them. I don't know whether we should allow this or not though. 

H Anthony Chan


-----Original Message-----
From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:[email protected]] 
Sent: Monday, July 29, 2013 5:33 PM
To: h chan
Cc: [email protected]; Jouni Korhonen
Subject: Re: [DMM] requirements and the security considerations

I suppose this is still related to my ticket #29 and now closed #27.
http://trac.tools.ietf.org/wg/dmm/trac/ticket/29

As I commented there, REQ6 should concern only to risked added or amplified by DMM.

The new proposed text still talks about access network security which is a separate issue, unless it means something else than commonly understood: getting on the network.. which is not DMM's concern.
As an optimization, DMM security and access network security can be tied, but I don't think we are that far along yet.

Also, End2End security is commonly understood as btw MN and CN, while here I believe the authors mean MN and DMM entities in the network. Even then, full IPsec may be overkill (with its mutual auth and all) and ephemeral security may be good enough to protect the service and the network.

e.g., It states.. "Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. MUST be required to protect DMM"

We cannot MUST "etc.", but that's just minor quibble.
Access control/Authorization can be implicit, e.g., " if allowed on the network, you can use DMM"
Authentication can be just to ensure the same MN is asking packet redirection, without knowing identity.

In short, security risks added or amplified by DMM can be discussed when we have protocol specifics. There are too much specific countermeasures here whose applicability is unknowable at this point.

Bests.

J.
AT&T Labs - Research
http://sites.google.com/site/macsbug/

On Jul 29, 2013, at 8:37 AM, h chan wrote:

> Byoung-Jo,
> Are you okay with the revised text for REQ6 provided by Jong-Hyouk?
>  
> H Anthony Chan
>  
> From: Jong-Hyouk Lee [mailto:[email protected]]
> Sent: Saturday, June 22, 2013 6:17 PM
> To: [email protected]; h chan
> Cc: Jouni Korhonen
> Subject: Re: [DMM] requirements and the security considerations
>  
> Hi all,
>  
> Here is text for security. Apologize for being late, Anthony.
>  
> ======
> 5.6.  Security
>  
> REQ6: DMM MUST be protected by security mechanisms/protocols in terms of network access security and end-to-end security. Network access security is required between the mobile host/router and the access network deploying DMM, to allow only a legitimate mobile host/router to use DMM. End-to-end security is required between nodes that participate in DMM, to protect DMM signaling messages. Existing security mechanisms/protocols MAY be possible to provide sufficient security protections to DMM. For instance, EAP-based authentication can be used for network access security, while IPsec can be used for end-to-end security. Note that when the existing security mechanisms/protocols are applied to DMM, security risks that MAY be introduced by DMM MUST be considered to be eliminated. 
>  
> A security mechanism/protocol that provides proof of possession of past and new IP addresses of a mobile host/router MAY be needed.
>  
> Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, MAY be launched against DMM. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. MUST be required to protect DMM. For instance, an illegitimate node attempts 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. As signaling messages MAY travel over the Internet, the end-to-end security between communicating nodes MUST be required.
>  
> This requirement addresses the problems of potentially insecure 
> mobility management protocols which make deployment infeasible because 
> platforms conforming to the protocols are at risk for data loss and 
> numerous other dangers, including financial harm to users. (I leave it 
> to be modified or improved by Anthony)
>  
> 6.  Security Considerations
> (Now I do not think we need to put text here) ======
>  
> 
> On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon <[email protected]> wrote:
> Hi, Anthony and all,
> 
>  
> 
> Actually, when it comes to reviewing BJ's comment, it seems touching very fundamental statement by mentioning the need of IP layer mobility support for multicast session (if needed), though this requirement itself has implicitly included it. But it's ok to me.
> 
>  
> 
> @Jouni, we respond to the ticket #22 as well.
> 
> As you know, we have tried to identify and discuss the meaning of flexible distribution in the list. If we unfold the meaning hidden in the abstract words, it would be fit to what you said. But the reworded sentences were mostly copied from "Motivation" paragraph and arranged. Overall, the Motivation was reworded.
> 
>  
> 
> By taking into account two comments, the revised text is as follows.
> 
>  
> 
> REQ7: DMM SHOULD consider multicast early so that solutions can
> 
> be developed not only to provide IP mobility to keep IP multicast 
> sessions when it is needed, but to avoid network inefficiency issues 
> in multicast traffic delivery (such as duplicate multicast 
> subscriptions towards the downstream tunnel entitiesy). The multicast 
> solutions should therefore avoid restricting the management of all IP 
> multicast traffic to a single host through a dedicated
> (tunnel) interface on multicast-capable access routers.
> 
> Motivation: Existing multicast deployment have been introduced after completing the design of the reference mobility protocol, then optimization and extensions have been followed, by "patching-up" procedure, thus leading to network inefficiency and non-optimal routing. The multicast solutions should therefore be required to consider efficiency nature in multicast traffic delivery.
> 
>  
> 
> p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie's comment. Check it, please.
> 
>  
> 
>  
> 
> Regards,
> 
> Seil
> 
>  
> 
>  
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> h chan
> Sent: Friday, June 21, 2013 1:26 AM
> To: Jouni Korhonen; [email protected]; KIM, BYOUNG-JO J (BYOUNG-JO
> Cc: Jong-Hyouk Lee
> Subject: Re: [DMM] requirements and the security considerations
>  
> 
> Seil or Sergio,
> 
> Can you reply to the following:
> 
>  
> 
> The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows:
> 
>  
> 
> I suggest to drop this requirement or make a clearer statement like "DMM should allow multicast to survive IP layer mobility without packet loss", or more modestly, "DMM should not foreclose multicast support during IP layer mobility.", etc..
> 
>  
> 
>  
> 
> His suggested text is to replace REQ7 with something like the following:
> 
>  
> 
>    REQ7:  DMM SHOULD enable multicast packet delivery during mobility events as needed.
> 
>  
> 
> H Anthony Chan
> 
>  
> 
>  
> 
> -----Original Message-----
> 
> From: h chan
> 
> Sent: Thursday, June 20, 2013 7:15 PM
> 
> To: 'Jouni Korhonen'; [email protected]; 'KIM, BYOUNG-JO J (BYOUNG-JO'
> 
> Cc: 'Jong-Hyouk Lee'
> 
> Subject: RE: [DMM] requirements and the security considerations
> 
>  
> 
> The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were the following:
> 
> There are too much text in the security REQ6 that are vague and too wide.
> 
>  
> 
> And Section 6. Security considerations should say "none", 'cause that's usually the section that discusses security considerations related to the draft itself. Since this is a requirement draft, there is no such thing.
> 
> There is a separate requirement earlier to cover security issues due to DMM.
> 
>  
> 
> REQ6:  Security considerations
> 
>  
> 
>           DMM protocol solutions MUST consider security risks 
> introduced
> 
>           by DMM into the network.  Examples of such risks to be
> 
>           considered may include authentication and authorization 
> mechanisms
> 
>           that allow a mobile host/router to use the mobility
> 
>           support provided by the DMM solution; redirecting traffic to
> 
>           the wrong host when providing DMM support; signaling message
> 
>           protection for authentication, integrity and confidentiality.
> 
>  
> 
>           Motivation: Various attacks such as impersonation, denial of
> 
>           service, man-in-the-middle attacks, and so on, may become 
> newly
> 
>           possible or easier to mount due to the introduction of DMM.  
> Proof
> 
>           of possession of past and new IP addresses may be needed.
> 
>  
> 
> H Anthony Chan
> 
>  
> 
>  
> 
> -----Original Message-----
> 
> From: [email protected] [mailto:[email protected]] On Behalf Of 
> Jouni Korhonen
> 
> Sent: Tuesday, June 18, 2013 2:40 AM
> 
> To: [email protected]
> 
> Subject: [DMM] requirements and the security considerations
> 
>  
> 
> <no co-chair cap/bowler>
> 
>  
> 
> Folks,
> 
>  
> 
> I have been reading Section 6 Security Considerations:
> 
>  
> 
>    It is necessary to provide sufficient defense against possible
> 
>    security attacks, or to adopt existing security mechanisms and
> 
>    protocols to provide sufficient security protections.  For 
> instance,
> 
>    EAP-based authentication can be used for access network security,
> 
>    while IPsec can be used for end-to-end security.
> 
>  
> 
> I think this text still deserves some tweaking. First, "provide sufficient defense against possible security attacks".. against whom?
> 
>  
> 
> Second, should the text say something that the DMM protocol itself must not be usable as a tool to launch an attack by a malicious mobile node that happens to know that it is attached to a network implementing DMM and knows (somehow) how the DMM protocol functions?
> 
>  
> 
> - Jouni
> 
> _______________________________________________
> 
> dmm mailing list
> 
> [email protected]
> 
> https://www.ietf.org/mailman/listinfo/dmm
> 
> _______________________________________________
> 
> dmm mailing list
> 
> [email protected]
> 
> https://www.ietf.org/mailman/listinfo/dmm
> 
> 
> _______________________________________________
> dmm mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmm
> 
> 
> 
>  
> --
> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living 
> somewhere between /dev/null and /dev/random
>  
> #email: jonghyouk (at) gmail (dot) com
> #webpage: http://sites.google.com/site/hurryon/