[Rmt] [Fwd: secdir review of draft-ietf-rmt-pi-norm-revised-11]

[Magnus Westerlund <[e-mail]>]

Hi,

As you see the security director reviewer is still not completely happy
with the clarity of what security functions that must be implemented and
when.

I would like to request the authors and the WG to consider how to
improve this. I especially like to see some feedback from other WG
members on what they think should be mandatory or not.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------

--- Begin Message ---

Hi,

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.

The document specifies a protocol (or an update to a protocol) that
provides end-to-end reliable transport of bulk data objects or streams

over multicast routing and forwarding services. It also provides a
congestion control scheme. It is designed to permit different
upper layer services to utilize its services in different ways.

I previousaly reviewed the -09- revision, where I asked that the 
specification tighen up requirements, ala RFC2119, especially in the
Security Considerations. That was done to a degree. 

More should be done. There are places with text like "It is expected
that ..."
that might be better expressed as SHOULDs. There are lower case
must/should/may/require uses.

Since this is a requested early review, let me also comment on
document clarity.

I found some of the paragraphs have conditionals in them, often
following a 
statement of MUST or SHOULD compliance. I think the "However ..."
conditionals
really hurt the clarity of the specification. For example:
   Large NORM group sizes will necessitate some form of key management
   that does rely upon shared secrets.  The GDOI and GSAKMP protocols
   mentioned here allow for certificate-based authentication.  It is
   RECOMMENDED these certificates use IP addresses for authentication
   although it may alternatively possible to have authentication
   associated with pre-assigned NormNodeId values.  However, it is
   likely that available group key management implementations will not
   be NORM-specific.

Is the information after "RECOMMENDED these certificates use IP
addresses for authentication" really needed here?
If I alternately have authentication associated with re-assigned
NormNodeId values, and do not support IP adresses for authentication,
am I still compliant?

A pet peeve - "it should be noted that" is almost always not needed.
Just make the statement, 
which effectively notes the point. Nothing "should" about it!

The same pet peeve variations: unnecessary introductory phrases or
clauses in sentences:

s/The principal issue is that configuration
   and operation of IPsec typically requires privileged user
   authorization./Configuration
   and operation of IPsec typically requires privileged user
   authorization./
s/It is expected that additional specifications may/
   Additional specifications MAY/

Some words to look at whether they are really necessary:
Additionally
However
Thus
It is expected that
As previously noted, 
Note that
also
as always
as mentioned in section x.x
as noted






David Harrington
[e-mail]
[e-mail]
[e-mail]

--- End Message ---