Subject: Re: [DMM] requirements and the security considerations

From: h chan <[email-masked]>
Date: Mon, 29 Jul 2013 12:33:42 +0000

Thanks and version 06 is being updated with this REQ7.

H Anthony Chan

From: Seil Jeon [mailto:[email-masked]]
Sent: Friday, June 21, 2013 2:37 PM
To: h chan; 'Jouni Korhonen'
Cc: [email-masked]; 'KIM, BYOUNG-JO J (BYOUNG-JO'
Subject: RE: [DMM] requirements and the security considerations

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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of h chan
Sent: Friday, June 21, 2013 1:26 AM
To: Jouni Korhonen; [email-masked]<mailto:[email-masked]>; 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-masked]<mailto:[email-masked]>; '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-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Jouni Korhonen

Sent: Tuesday, June 18, 2013 2:40 AM

To: [email-masked]<mailto:[email-masked]>

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-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/dmm

_______________________________________________

dmm mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/dmm

---

From: h chan <[email-masked]>
Date: Mon, 29 Jul 2013 12:37:34 +0000

Byoung-Jo,
Are you okay with the revised text for REQ6 provided by Jong-Hyouk?

H Anthony Chan

From: Jong-Hyouk Lee [mailto:[email-masked]]
Sent: Saturday, June 22, 2013 6:17 PM
To: [email-masked]; 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-masked]<mailto:[email-masked]>> wrote:

Hi, Anthony and all,

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.

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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of h chan
Sent: Friday, June 21, 2013 1:26 AM
To: Jouni Korhonen; [email-masked]<mailto:[email-masked]>; KIM, BYOUNG-JO J (BYOUNG-JO
Cc: Jong-Hyouk Lee
Subject: Re: [DMM] requirements and the security considerations

Seil or Sergio,

H Anthony Chan

-----Original Message-----

From: h chan

Cc: 'Jong-Hyouk Lee'

H Anthony Chan

-----Original Message-----

<no co-chair cap/bowler>

Folks,

- Jouni

dmm mailing list

dmm mailing list

--
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/

---

From: h chan <[email-masked]>
Date: Mon, 29 Jul 2013 13:00:14 +0000

It looks like the suggested text from Jong-Hyouk on the motivation section of REQ6 has attempted to provide the security considerations in the DMM environment. 

H Anthony Chan

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 9:58 PM
To: h chan
Cc: [email-masked]; KIM, BYOUNG-JO J (BYOUNG-JO; Jong-Hyouk Lee
Subject: Re: [DMM] requirements and the security considerations

> There is a separate requirement earlier to cover security issues due to DMM.

In some recent requirements documents I have seen rather extensive Security Consideration sections. What I would assume to see here, is a generic discussion on the security considerations on distributed environment. That is not about requirements itself per se.

- JOuni (as an individual.. too hot here to wear any hat etc :)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Jouni Korhonen
> To: [email-masked]
> [email-masked]

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Mon, 29 Jul 2013 11:32:48 -0400

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:

> On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon <[email-masked]> wrote:
> Hi, Anthony and all,
> 
>  
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
> To: Jouni Korhonen; [email-masked]; KIM, BYOUNG-JO J (BYOUNG-JO
> Cc: Jong-Hyouk Lee
> To: 'Jouni Korhonen'; [email-masked]; 'KIM, BYOUNG-JO J (BYOUNG-JO'
> 
> Cc: 'Jong-Hyouk Lee'
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jouni Korhonen
>

---

From: h chan <[email-masked]>
Date: Mon, 29 Jul 2013 16:29:11 +0000

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-masked]] 
Sent: Monday, July 29, 2013 5:33 PM
To: h chan
Cc: [email-masked]; Jouni Korhonen
Subject: Re: [DMM] requirements and the security considerations

Bests.

J.
AT&T Labs - Research

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

> 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)
>  
> (Now I do not think we need to put text here) ======
>  
> 
> 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 
> h chan
> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living 
> somewhere between /dev/null and /dev/random
>

---

From: h chan <[email-masked]>
Date: Mon, 29 Jul 2013 17:52:43 +0000

Byoung-Jo,
Let me try to phrase your comment into the security requirement as follows. Please check and feel free to correct. 

REQ6: Security considerations
A DMM solution MUST not introduce new security risks or amplified existing security risks against which the existing security mechanisms/protocols cannot offer sufficient protection. 

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. In addition, end-to-end security measures between communicating nodes may already be used when deploying existing mobility protocols where the signaling messages travel over the Internet. For instance, EAP-based authentication can be used for network access security, while IPsec can be used for end-to-end security. When these 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. Else the security protection would be degraded in DMM versus in existing mobility protocols. 

This requirement prevents a DMM solution to introduce uncontrollable 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. 

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Monday, July 29, 2013 6:29 PM
To: KIM, BYOUNG-JO J (BYOUNG-JO)
Cc: [email-masked]
Subject: Re: [DMM] requirements and the security considerations

H Anthony Chan

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

Bests.

J.
AT&T Labs - Research

---

From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <[email-masked]>
Date: Mon, 29 Jul 2013 14:17:25 -0400

Happy as a clam..

Will close the ticket.

Best.

J.
p.s. a typo.. "amplify" instead of 'amplified'.

---

From: h chan <[email-masked]>
Date: Wed, 31 Jul 2013 08:57:23 +0000

Thanks and I have corrected the typo in version -06, which was uploaded yesterday. 

H Anthony Chan

-----Original Message-----
From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:[email-masked]] 
Sent: Monday, July 29, 2013 8:17 PM
To: h chan
Cc: [email-masked]
Subject: Re: [DMM] requirements and the security considerations

Happy as a clam..

Will close the ticket.

Best.

J.

On Jul 29, 2013, at 1:52 PM, h chan wrote:

>> 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)
>>