Re: AD Evaluation: draft-ietf-dmm-requirements

Le 01/02/2014 01:13, h chan a écrit :
> Alex, There are some examples in the motivation following REQ6. Do
> you think the rouge route example is included in the "redirecting
> traffic from its legitimate path" or should it be added as a separate
> example?

Thanks for the remark, I didnt know that.  Please see some comments below.

IMHO, it would be good to see first sentences about the particular DMM
risks, and maybe following risks which are relevant to other protocols
more generally.

> REQ6:  Security considerations
>
> A DMM solution MUST NOT introduce new security risks, or amplify
> existing security risks, that cannot be mitigated by existing
> security mechanisms or protocols.

Generic.

> Motivation: Various attacks such as impersonation, denial of service,
> man-in-the-middle attacks, and so on, may be launched in a DMM
> deployment.

Generic.

> For instance, an illegitimate node may attempt to access a network
> providing DMM.

GEneric - it relates to access control, EAP and AAA.

> Another example is that a malicious node can forge a number of
> signaling messages thus redirecting traffic from its legitimate path.

Right.

But in addition, in the case of a PMIP-like solution (or route updates 
with BGP) it may be that the mobile node does not forge anything, but 
some fixed nodes running PMIP or BGP are attacked by some BGP or PMIP 
specific attackers maybe from far away.

Would we be concerned by such risks?  Should we list them?

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

I agree.

Alex

> This requirement prevents a DMM solution from introducing
> 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 the users.
>
> H Anthony Chan
>
> -----Original Message----- From: dmm [mailto:[email protected]] On
> Behalf Of Alexandru Petrescu Sent: Friday, January 31, 2014 5:45 AM
> To: [email protected] Subject: Re: [DMM] AD Evaluation:
> draft-ietf-dmm-requirements
>
> Le 31/01/2014 00:18, Jouni Korhonen a écrit :
>>
>> On Jan 29, 2014, at 5:56 AM, Brian Haberman
>> <[email protected]> wrote:
>>
>> [snip]
>>
>>>
>>> The above seems a little clunky.  Does this work for everyone?
>>>
>>>
>>> A DMM solution MUST NOT introduce new security risks, or amplify
>>> existing security risks, that cannot be mitigated by existing
>>> security mechanisms or protocols.
>>
>>
>> Would work for me.
>
> To me this is too hig-level.
>
> IT's a good principle that we apply everywhere and it works.
>
> But I wonder there is some detail about it.
>
> Like for example: any new DMM solution involving route updates will
> not allow rogue routes to be inserted in the system.
>
> Alex
>
>>
>> - Jouni
>>
>>
>>>
>>>
>>> Regards, Brian
>>>
>>
>> _______________________________________________ dmm mailing list
>> [email protected] https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>
>
> _______________________________________________ dmm mailing list
> [email protected] https://www.ietf.org/mailman/listinfo/dmm
>
>