Subject: [DMM] requirements and the security considerations

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Jun 2013 10:39:47 +0300

<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

---

From: h chan <[email-masked]>
Date: Fri, 21 Jun 2013 00:14:49 +0000

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]] On Behalf Of Jouni Korhonen
Sent: Tuesday, June 18, 2013 2:40 AM
To: [email-masked]
Subject: [DMM] requirements and the security considerations

<no co-chair cap/bowler>

Folks,

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]
https://www.ietf.org/mailman/listinfo/dmm

---

From: h chan <[email-masked]>
Date: Fri, 21 Jun 2013 00:25:43 +0000

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]; 'KIM, BYOUNG-JO J (BYOUNG-JO'
Cc: 'Jong-Hyouk Lee'
Subject: RE: [DMM] requirements and the security considerations

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, June 18, 2013 2:40 AM
To: [email-masked]
Subject: [DMM] requirements and the security considerations

<no co-chair cap/bowler>

Folks,

- Jouni

---

From: h chan <[email-masked]>
Date: Fri, 21 Jun 2013 00:37:46 +0000

Can anyone please reply to this:

Text suggested by Byoung-Jo:

          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

For comparison, text in version 5 is
   REQ6:  Security considerations

          DMM protocol solutions MUST consider security risks introduced
          by DMM into the network.  Such considerations may include
          authentication and authorization mechanisms that allow a
          mobile host/router to use the mobility support provided by the
          DMM solution; measures against 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.

          Signaling messages can be subject to various attacks since
          they carry critical context information about a mobile node/
          router.  For instance, 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, end-to-end security between communicating hosts must

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of h chan
Sent: Thursday, June 20, 2013 7:15 PM
To: Jouni Korhonen; [email-masked]; KIM, BYOUNG-JO J (BYOUNG-JO
Cc: Jong-Hyouk Lee
Subject: Re: [DMM] requirements and the security considerations

H Anthony Chan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: Tuesday, June 18, 2013 2:40 AM
To: [email-masked]
Subject: [DMM] requirements and the security considerations

<no co-chair cap/bowler>

Folks,

- Jouni

---

From: "Seil Jeon" <[email-masked]>
Date: Fri, 21 Jun 2013 13:36:59 +0100

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

Seil or Sergio,

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

   REQ7:  DMM SHOULD enable multicast packet delivery during mobility events
as needed.

H Anthony Chan

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

From: h chan 

To: 'Jouni Korhonen';  <mailto:[email-masked]> [email-masked]; 'KIM, BYOUNG-JO J
(BYOUNG-JO'

Cc: 'Jong-Hyouk Lee'

The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were the
following:

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.

H Anthony Chan

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

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

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

<no co-chair cap/bowler>

Folks,

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

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

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

dmm mailing list

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

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

---

From: Jong-Hyouk Lee <[email-masked]>
Date: Sun, 23 Jun 2013 01:16:34 +0900

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]> wrote:

> Hi, Anthony and all,****
> ** **
> implicitly included it. But it's ok to me.****
>
> ** **
>
> @Jouni, we respond to the ticket #22 as well.****
>
> 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
> (tunnel) interface on multicast-capable access routers.****
>
> and extensions have been followed, by “patching-up” procedure, thus leading
> traffic delivery.****
> ** **
> p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie’s
> comment. Check it, please.****
>
> ** **
>
> ** **
>
> Regards,****
>
> Seil****
>
> ** **
>
> ** **
>
> ** **
> Seil or Sergio,****
> Can you reply to the following:****
>
> ** **
>
> The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows:****
>
> ** **
>
> 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]; '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:****
>
> ****
> ** **
> 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****
>
> ****
>           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]<[email-masked]>]
> On Behalf Of Jouni Korhonen****
>
> Sent: Tuesday, June 18, 2013 2:40 AM****
>
> To: [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.****
>
> ** **
>
> 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
> (somehow) how the DMM protocol functions?****
>
> ** **
>
> - Jouni****
>
> _______________________________________________****
>
> dmm mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/dmm****
>
> _______________________________________________****
>
> dmm mailing list****
>
> [email-masked]****
>
> 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/

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 25 Jun 2013 22:46:58 +0300

Sorry for the slow response. I am supposed to be on my summer vacation ;)

On Jun 21, 2013, at 3:36 PM, Seil Jeon <[email-masked]> wrote:

> p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie’s comment. Check it, please.

Probably. However, this issue was not recorded by me so I have not
cleared it either automatically.

@Charlie: does -05 address your concern on #33 ?

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 25 Jun 2013 22:58:22 +0300

> 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: Jouni Korhonen <[email-masked]>
Date: Tue, 25 Jun 2013 23:07:51 +0300

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

The above would work for me.. at least better than the current text
in the I-D.

- Jouni