Subject: [secdir] secdir review of draft-stone-mgcp-vbd-07

From: "Carl Wallace" <[email-masked]>
Date: Wed, 23 Jun 2010 11:02:54 -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.

This document defines new MGCP packages.  This document is pretty far
outside my sandbox, but I did have a couple of questions and comments.

- Why is this an Informational document instead of Standards track?  It
seems to be defining new packages that are not already defined
elsewhere.
- I struggled with the presentation a bit and found myself reading
references to understand some of the shorthand in this document.  For
example, in section 3.1 the column headers are not described in this
draft. 
- The security considerations section is brief and primarily references
RFC 3435, which essentially has two security considerations: use IPSec
and use SDP encryption keys.  The latter is not recommended in the
current SDP draft.  This section should directly state the security
considerations it wants to assert.

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 28 Jun 2010 08:34:21 -0400

Informational track is fine, I was just asking why it was chosen.  

If you and the ADs are satisfied that the presentation of things like
the table in 3.1 is sufficiently descriptive that's fine with me (though
I'd prefer at least an explicit reference for some of the shorthand).  

I have no other items to add to security considerations, your proposed
changes sound good.

From: Sandeep Sharma [mailto:[email-masked]] 
Sent: Sunday, June 27, 2010 5:17 PM
To: Carl Wallace; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; 'Flemming
Andreasen (fandreas)'; Sumanth Channabasappa
Subject: RE: secdir review of draft-stone-mgcp-vbd-07

Carl,

Thanks for the review comments. I consulted with the co-authors and
Flemming and our responses are indicated below.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]] 
Sent: Wednesday, June 23, 2010 9:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Sandeep Sharma
Subject: secdir review of draft-stone-mgcp-vbd-07

elsewhere.

SJS> MGCP (RFC 3435) and other MGCP packages are Informational RFCs, so
it seems consistent to have this one being informational as well.

draft. 

SJS> This is a standard MGCP package format as defined in RFC 3435
(Section 6, and in this case Section 6.6 in particular)

SJS> We agree with your comments about SDP encryption keys (RFC 3435
Section 5.1). We will call out IPsec specifically and then add a few
paragraphs about ways to more adequately protect RTP media streams these
days (SRTP which should probably have at least a "SHOULD" recommendation
here) as well as some of the specific issues that may arise if an
attacker is able to modify/inject VBD data in the RTP media stream. We
would also greatly appreciate if you can provide additional
guidance/considerations (if any) that you believe should be addressed.

---

From: Sandeep Sharma <[email-masked]>
Date: Sun, 27 Jun 2010 15:16:48 -0600

Carl,

Thanks for the review comments. I consulted with the co-authors and Flemming and our responses are indicated below.

-----Original Message-----
From: Carl Wallace [mailto:[email-masked]]
Sent: Wednesday, June 23, 2010 9:03 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Sandeep Sharma
Subject: secdir review of draft-stone-mgcp-vbd-07

elsewhere.

SJS> MGCP (RFC 3435) and other MGCP packages are Informational RFCs, so it seems consistent to have this one being informational as well.

draft.

SJS> This is a standard MGCP package format as defined in RFC 3435 (Section 6, and in this case Section 6.6 in particular)

SJS> We agree with your comments about SDP encryption keys (RFC 3435 Section 5.1). We will call out IPsec specifically and then add a few paragraphs about ways to more adequately protect RTP media streams these days (SRTP which should probably have at least a "SHOULD" recommendation here) as well as some of the specific issues that may arise if an attacker is able to modify/inject VBD data in the RTP media stream. We would also greatly appreciate if you can provide additional guidance/considerations (if any) that you believe should be addressed.