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

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Apr 2009 15:56:35 -0400

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
[email-masked]
[email-masked]
[email-masked]

---

From: Brian Adamson <[email-masked]>
Date: Thu, 16 Apr 2009 13:31:08 -0400

Dave,

Thanks for your comments here.  I think the MUSTs/SHOULDs can be  
clarified and will take a shot at that for you.

The NORM spec is a transport protocol and not a security protocol as  
you point out.  The goal of the security discussion was:

1) To identify the requirements upon using lower-layer  IPSec to  
secure the protocol, and

2) Provide the EXT_AUTH header extension as a place-holder for  
applying a security mechanism as part of the NORM implementation.  And  
to this regard, the RMT working group has another working document  
"draft-ietf-rmt-simple-auth-for-alc-norm" that makes use of this  
header extension.

My question for you is whether you think we need to specify a specific  
security approach (e.g., IPSec) for implementations to have an  
interoperability spec? My personal opinion is that the spec can be  
interoperable in a "non-secure" fashion (i.e. no use of IPSec or the  
EXT_AUTH) mechanisms, but recommend that deployers SHOULD deploy NORM  
with security applied (Either the baseline IPSec approach described or  
a mechanism that uses the EXT_AUTH extension that is described in a  
follow-on spec like the "Simple Auth" document in progress).  For  
those deployments to be interoperable, of course they would need to  
specify the same security mechanism, whatever it is.

Perhaps more clearly stating these goals and cleaning up the MUSTs/ 
SHOULDs usage would satisfy you comments?  I think we can accommodate  
that in a fairly straightforward fashion.

best regards,

Brian Adamson
[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Thu, 16 Apr 2009 14:30:23 -0400

Hi,

To ensure that there is at least one mechanism that every
implementation will support in order to guarantee that
interoperability is possible between any two implementations, I think
you should specify that IPSec is REQUIRED to be supported in all
implementations. 

An alternative is to specify that all implementation MUST support
draft-ietf-rmt-simple-auth-for-alc-norm. 

Since IPSec might already be available in many stacks, and has
significant deployment experience so we know there a few unknown
gotchas yet to be discovered, I personally think the IPSec approach
makes the most sense as a mandatory-to-implement baseline.

dbh

> -----Original Message-----
> From: Brian Adamson [mailto:[email-masked]] 
> Sent: Thursday, April 16, 2009 1:31 PM
> To: David Harrington
> Cc: [email-masked]; Pasi Eronen; Tim Polk; Joe Macker; 
> [email-masked]; [email-masked]; Lorenzo Vicisano; 
> Magnus Westerlund; Brian Adamson
> Subject: Re: secdir review of draft-ietf-rmt-pi-norm-revised-09
> 
> Dave,
> 
>

---

From: Brian Adamson <[email-masked]>
Date: Thu, 16 Apr 2009 15:01:54 -0400

Thanks Dave,

I think it is reasonable to expect that IPSec compatibility can be  
REQUIRED in a compliant implementation.  I have actually run our NORM  
reference implementation with transport-mode IPSec enabled (different  
combinations of ESP and/or authentication) with pre-placed keys and  
security associations and it worked.  Since NORM is encapsulated in  
UDP as currently specified, there was nothing that really needed to be  
done to make it work with IPsec other than getting the proper mix of  
security associations into place... as a matter of fact, an  
implementor would probably have to work hard to make something that  
wasn't IPSec compatible.

I will incorporate your recommendation into the updated draft.

Brian Adamson
[email-masked]

---

From: Brian Adamson <[email-masked]>
Date: Mon, 20 Apr 2009 17:49:23 -0400

Hello,

I have posted an updated version of the NORM draft which addresses 
Spencer's GEN-ART comments and attempts to clarify the Security 
Considerations per Dave Harrington's comments and the IANA 
Consideration per comments from IANA.

This update also makes the TFMCC RFC a Normative reference per 
Magnus' request at the last RMT meeting.

best regards,

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Wed, 22 Apr 2009 21:58:07 +0000

Hi Brian,

A couple of questions about the new IANA Considerations:

- Is there an upper limit to the values available in the NORM 
Stream Control Codes registry?

- Is the NORM_CMD Message Sub-types registry open for further 
assignments? If so, what are the registration procedures and 
upper limits? Should "0" be marked "Reserved"?

Thanks,

Amanda
IANA