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

"Carl Wallace" <> Mon, 28 June 2010 12:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7C13B3A6989; Mon, 28 Jun 2010 05:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.847
X-Spam-Status: No, score=-4.847 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZMxYQbIhOlxq; Mon, 28 Jun 2010 05:34:14 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 610F73A659A; Mon, 28 Jun 2010 05:34:14 -0700 (PDT)
X-VirusChecked: Checked
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: []
Received: (qmail 7998 invoked from network); 28 Jun 2010 12:34:23 -0000
Received: from unknown (HELO ( by with SMTP; 28 Jun 2010 12:34:23 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB16BE.3C4E4E19"
Content-class: urn:content-classes:message
Date: Mon, 28 Jun 2010 08:34:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <>
In-Reply-To: <76AC5FEF83F1E64491446437EA81A61F7CF4A7B323@srvxchg>
Thread-Topic: secdir review of draft-stone-mgcp-vbd-07
Thread-Index: AcsS5SiAzRrqHLOYRH+RyifUiUWN1gDVoMPQACCH8CA=
References: <> <76AC5FEF83F1E64491446437EA81A61F7CF4A7B323@srvxchg>
From: Carl Wallace <>
To: Sandeep Sharma <>,
Cc: "Flemming Andreasen (fandreas)" <>,,,, Sumanth Channabasappa <>
Subject: Re: [secdir] secdir review of draft-stone-mgcp-vbd-07
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jun 2010 12:34:20 -0000

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 [] 
Sent: Sunday, June 27, 2010 5:17 PM
To: Carl Wallace;
Cc:;;; 'Flemming
Andreasen (fandreas)'; Sumanth Channabasappa
Subject: RE: secdir review of draft-stone-mgcp-vbd-07




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


-----Original Message-----
From: Carl Wallace [] 
Sent: Wednesday, June 23, 2010 9:03 AM
Cc:;;; 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



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



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.