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

[Sandeep Sharma <[e-mail]>]

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:[e-mail]]
Sent: Wednesday, June 23, 2010 9:03 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; Sandeep Sharma
Subject: secdir review of draft-stone-mgcp-vbd-07



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.



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



- 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.



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



- 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.



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.