Re: [secdir] Secdir review of draft-ietf-dmm-requirements-14

["H Anthony Chan" <[e-mail]>]

Catherine,

Thanks for the comments and suggestions.

I am going through them one by one as follows:

The revised abstract is as follows:

Abstract:
   This document defines the requirements for Distributed Mobility
   Management (DMM) at the network layer.  The hierarchical structure in
   traditional wireless networks has led primarily to centrally deployed
   mobility anchors.  As some wireless networks are evolving away from
   the hierarchical structure, it can be useful have a distributed model
   for mobility management in which traffic does not need to traverse
   centrally deployed mobility anchors far from the optimal route.  The
   motivation and the problems addressed by each requirement are also
   described.

I agree "distributed processing" is open-ended. The following suggested revision tries to spell out what to enable. 

   REQ1:  Distributed mobility management

          IP mobility, network access and routing solutions provided by
          DMM MUST enable traffic to avoid traversing single mobility
          anchor far from the optimal route.

Thanks for the suggestion to clarify what the specific node mean. 

I also agree that "can be used to protect" is not the proper word. The intention of this requirement is that the dmm solution MUST be designed properly (in terms of security) such that the use of the security protocols that are already used to protect the existing network and the existing mobility protocols is able to provide sufficient protection to the dmm entities. Please check the following revision:

   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.

          Motivation: Various attacks such as impersonation, denial of
          service, man-in-the-middle attacks, and so on, may be launched
          in a DMM deployment.  For instance, an illegitimate node may
          attempt 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 or nodes to which the traffic
          is redirected may be 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. should be used to protect the DMM entities as they are
          already used to protect against existing networks and existing
          mobility protocols defined in IETF.  Yet if a candidate DMM
          solution is such that even the proper use of these existing
          security mechanisms/protocols are unable to provide sufficient
          security protection, that candidate DMM solution is causing
          uncontrollable security problems.

   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


From: Catherine Meadows 
Sent: Tuesday, February 25, 2014 3:27 PM
To: [e-mail] ; [e-mail] ; [e-mail] 
Cc: Catherine Meadows 
Subject: Secdir review of draft-ietf-dmm-requirements-14


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments. 


This draft gives high-level requirements for distributed mobility management at the network layer. 
 It also gives definitions of key concepts and motivation for replacing or augmenting current standards for centralized mobility management (in which information 
about location of a mobile node is kept at a centralized mobility anchor) with distributed mobility management, in which
this information is distributed.  This latter includes a list of the problems that can be addressed with DMM.


Although the motivation for distributed mobility management is not the main point of this document, it is very helpful
in helping the reader understand the requirements and their importance, so I am glad to see it there.  Since this, including the
problem statement, is quite important and useful, I’d suggest mentioning it in the abstract.


The requirements are for the most part well-written and at the appropriate level of detail.  However, I have
a few suggestions:


1)  REQ 1 is for distributed processing, but “distributed processing is a rather open-ended term.  It would be a good
idea to include some indication of what is meant by distributed processing here.


2)  There are a couple of points in REQ6: Security considerations that need to be clarified:


2a) 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.


It’s not made clear what the specific node is.  It would be better to have something like


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 or nodes to which the traffic is redirected may be under a denial of service
attack, whereas other nodes do not receive their traffic.


2b) 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.


“can be used to protect” seems  awfully weak.  Is there any reason why you don’t want to say SHOULD or MUST?
Or, if you don’t want to make this and IETF SHOULD or MUST, you might want to say  something like “we recommend”. 

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: [phone]
fax: [phone]
email: [e-mail]