I wouldn't attempt to rewrite the whole 4.6 REQ6, but I feel it too generic
covering many typical security topics that may not be needed.
e.g.,
"DMM protocol solutions MUST consider security aspects, including
confidentiality and integrity."
should read
"DMM protocol solutions MUST consider security risks introduced by the DMM
service into a network."
Another example: This discussion below is probably not necessary before
understanding what kind of risk DMM adds.
"opt-in or opt-out data confidentiality to signaling messages depending on
network environments or user requirements."
I don't wanna appear pedantic (I guess that admits it already), but, something
like this
"Mutual authentication and authorization between a
mobile host/router and an access router providing the DMM
service to the mobile host/router are required to prevent
potential attacks in the access network of the DMM service."
is discussing solutions already.
Of course we don't know either way yet, but DMM may only need indirect or
direct proof of possession of past and new IP addresses, rather than full AAA,
to serve its purpose safely.
I hope this helps.
Bests.
J.
Byoung-Jo "J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/
On Apr 19, 2013, at 4:13 AM, Jong-Hyouk Lee wrote:
> Hello, Byoung-Jo
>
> Regarding your comments on the security text, for your comment 2, I do not
> quite get you. Provide clear text expressing your concern then I will review
> and try to reflect to the draft. For your comment 5, just you need to be sure
> that the given text is about the general security consideration.
>
> Cheers.
>
>
> On Wed, Apr 17, 2013 at 9:44 PM, KIM, BYOUNG-JO J (BYOUNG-JO)
> <[email protected]> wrote:
> Hi.
>
> Below are my comments on the draft-ietf-dmm-requirements-03.
>
> Overall, the draft has much to admire and agreeable on most points.
> Kudos to the authors.
>
>
> ===================
> Comment 1:
>
> REQ2: Transparency to Upper Layers when needed
>
> >> I would like to suggest that DMM must provide transparency to upper layers
> >> for a limited time only when needed. Upper layer protocols or applications
> >> that are unaware of IP layer mobility and IP address changes cannot be
> >> supported indefinitely, without compromising the purpose of DMM. How much
> >> time is of course another matter, but that can be discussed during design
> >> or even dynamic.
> In time, applications and upper layer protocols will have to be updated to
> handle IP address changes by reconnect or other means, as long as DMM
> provides temporary shield from packet losses or other disruptions and buy
> them time to make preparations.
>
> ====================
> Comment 2:
>
> REQ6: Security considerations
>
> >> I think the requirements described here may give the impression that DMM
> >> excludes ephemeral security for the purpose of routing to the correct
> >> entities, but not necessarily tied to service authorizations or
> >> identities. Also, protection requirements beyond what current ISPs deal
> >> with for their access routers seem unnecessary. DMM's own security should
> >> be limited to risks that DMM adds to the access network, not the whole
> >> access network security.
>
> =====================
> Comment 3:
> REQ7: DMM should enable multicast solutions in flexible distribution
> scenario.
>
> >> I lack the necessary knowledge on multicast but this seems like a
> >> feel-good statement without a point. 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..
>
> ====================
> Comment 4:
>
> 5. Security Considerations
> Distributed mobility management (DMM) requires two kinds of security
> considerations: First, access network security that only allows a
> legitimate mobile host/router to access the DMM service; Second, end-
> to-end security that protects signaling messages for the DMM service.
>
> >> Related to my Comment 2, "access network security" is confusing here, as
> >> it often means allowing access to the network to begin with. DMM must
> >> assume that is already done at least in the lower layer or even IP layer.
> >> It may or may not offer DMM service to anyone or only to authorized
> >> devices/users. I think DMM must cover the situation where the service is
> >> offered to anything that asks for it, while ensuring the packets are not
> >> redirected to wrong directions.
>
> ===================
>
> Bests.
>
> Byoung-Jo "J" Kim
> AT&T Labs - Research
> https://sites.google.com/site/macsbug/
>
>
> On Apr 10, 2013, at 3:19 AM, Jouni Korhonen wrote:
>
> > Folks,
> >
> > This mail starts a two week WGLC #2 for draft-ietf-dmm-requirements-03.
> > The issues, even editorials, must be recorded into the Issue Tracker,
> > otherwise they are likely to be neglected. We require minimum three
> > reviews (that are more than one liners). The more the better, though.
> >
> > The WGLC ends on Wednesday 24rd April.
> >
> > - Jouni & Julien
> > _______________________________________________
> > 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
