Re: requirements and the security considerations

"Seil Jeon" <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <[email protected]>
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';  <mailto:[email protected]> [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:  <mailto:[email protected]> [email protected] [
<mailto:[email protected]> mailto:[email protected]] On Behalf Of
Jouni Korhonen

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

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

 <mailto:[email protected]> [email protected]

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

_______________________________________________

dmm mailing list

 <mailto:[email protected]> [email protected]

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

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