Last Call Review of draft-ietf-dmm-requirements-14
review-ietf-dmm-requirements-14-secdir-lc-meadows-2014-02-27-00

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: 202-767-3490

fax: 202-404-7942

email:

catherine.meadows at nrl.navy.mil