Re: requirements and the security considerations

Jong-Hyouk Lee <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <CAB2CD_W3UJVfGQm=tJw6GRCVNeXQA6SixZ7-hx+XzOc=OzNR7Q@mail.gmail.com>
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]<[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/

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.