[secdir] secdir review of draft-ietf-rmt-pi-norm-revised-09

"David Harrington" <ietfdbh@comcast.net> Fri, 10 April 2009 19:55 UTC

From: David Harrington <ietfdbh@comcast.net>
To: secdir@ietf.org, Pasi.Eronen@nokia.com, tim.polk@nist.gov
Date: Fri, 10 Apr 2009 15:56:35 -0400
Message-ID: <03a101c9ba16$74bf49f0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: Acm6FnPhmb2bGw/9SquiIT3AtmLbSg==
Cc: 'Magnus Westerlund' <magnus.westerlund@ericsson.com>, 'Lorenzo Vicisano' <lorenzo@vicisano.net>, adamson@itd.nrl.navy.mil, M.Handley@cs.ucl.ac.uk, cabo@tzi.org, macker@itd.nrl.navy.mil
Subject: [secdir] secdir review of draft-ietf-rmt-pi-norm-revised-09
Precedence: list

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 got to this review late, so I went straight to the security
considerations first. I found the security requirements wishy-washy. 

Per BCP61, MUSTs are for implementers, SHOULDs are for deployers. 

There are few MUSTs or REQUIREDs to guide implementators what MUST be
present for interoperable security capabilities in an compliant
implementation. There are lots of SHOULDs, RECOMMENDEDs, MAY, can be,
is possible, is expected, optionally, etc. in the "Baseline Secure
NORM Operation".

On the other hand, there are lots of SHALLs and REQUIREDs for how
deployers MUST configure their security.

I am not sure how interoperable the security for this "standard" will
be because there are so many allowable options for how one does
security. 

This protocol is not a security protocol. It is a protocol that
utilizes lower layer security services, so maybe this "wishy-washy"
approach is the correct approach to serve the real-world needs of NORM
implementers and deployers. But I would feel more comfortable with
something a bit more solid in terms of what MUST be present for
security capabilities in compliant implementations.

It might help a lot to separate the security considerations into what
MUST be implemented for interoperability, and how deployments SHOULD
be configured, and then talk about optional extensions or
alternatives. As currently written, I am not sure I could figure out
just what an implementer MUST support.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com

[secdir] secdir review of draft-ietf-rmt-pi-norm-… David Harrington
Re: [secdir] secdir review of draft-ietf-rmt-pi-n… Brian Adamson
Re: [secdir] secdir review of draft-ietf-rmt-pi-n… David Harrington
Re: [secdir] secdir review of draft-ietf-rmt-pi-n… Brian Adamson
[secdir] Update: draft-ietf-rmt-pi-norm-revised-10 Brian Adamson
[secdir] [IANA #236966] Re: Last Call: draft-ietf… Amanda Baber via RT