Subject: [secdir] Review of draft-ietf-payload-rtp-ancillary-06

From: Shawn M Emery <[email-masked]>
Date: Tue, 8 Nov 2016 01:10:50 -0700

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 draft specifies a Real-time Transport Protocol (RTP) payload format
for ancillary data; including time code, Closed Captioning, and Active
Format Description (AFD).

The security considerations section does exist and refers to the base
protocol specification of RTP and any profile utilized for consideration.
The section continues that RTP does not require a single media solution,
referencing RFC 7202, and references RFC 7201 for various mechanisms to
secure RTP.  I agree with this assertion.  The section goes on to discuss
the specific payload data and how to mitigate against attack by first
sanity checking said data.  I'm OK with this assertion, except for the
integrity check using Checksum_Word.  The nine bit checksum based on
summing the nine least significant bits of four out of dozens of possible
data fields doesn't seem to provide sufficient coverage for this check.

General comments:

None.

Editorial comments:

Abstract: Does RTP and SMPTE need to be expanded first?
Abstract: Is SMPTE ST 291-1 a normative reference?
s/an SDI/a SDI/

Shawn.
--

---

From: Thomas Edwards <[email-masked]>
Date: Wed, 16 Nov 2016 05:26:25 +0000

Shawn,

Thanks again for the Security Directorate review of of draft-ietf-payload-rtp-ancillary-06!

Please see below for a list of your comments, my responses, and my suggested draft changes.

Comment: “The [security considerations] section goes on to discuss the specific payload data and how to mitigate against attack by first sanity checking said data.  I'm OK with this assertion, except for the integrity check using Checksum_Word.  The nine bit checksum based on summing the nine least significant bits of four out of dozens of possible data fields doesn't seem to provide sufficient coverage for this check.”
Response: Indeed, the nine bit checksum word does not provide sufficient coverage for a check against attack.
Draft change: To "Also the Checksum_Word should be checked against the ANC data packet to ensure that its data has not been damaged in transit" add ", "but the Checksum_Word is unlikely to provide a payload integrity check in case of a directed attack."

Comment: Abstract: Does RTP and SMPTE need to be expanded first?
Response: Agreed.
Draft change: Expand RTP and SMPTE in Abstract

Comment: Is SMPTE ST 291-1 a normative reference?
Response: I believe yes, due to specific definitions of ST 291-1 data fields specified in the payload, and DID/SDID info in the Media Type parameter.
Draft change: No change

Comment: s/an SDI/a SDI/
Response: SDI is an initialism.  The Chicago Manual of Style states "When an abbreviation follows an indefinite article, the choice of a or an is determined by the way the abbreviation would be read aloud."
Draft change: No change

-Thomas

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[email-masked]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035

On 11/8/16, 12:10 AM, "Shawn M Emery" <[email-masked]> wrote:

    
    
    General comments:
    
    None.
    
    Editorial comments:

    Shawn.
    --

---

From: Shawn M Emery <[email-masked]>
Date: Tue, 22 Nov 2016 00:41:52 -0700

Hi Thomas,

Sorry for the late reply, was out of the office last week. Comments 
in-line...

> Draft change: To "Also the Checksum_Word should be checked against the ANC data packet to ensure that its data has not been damaged in transit" add ", "but the Checksum_Word is unlikely to provide…

I think that this addition more clearly states the limitations of 
Checksum_Word.

> Draft change: Expand RTP and SMPTE in Abstract

Thanks.

> Response: I believe yes, due to specific definitions of ST 291-1 data fields specified in the payload, and DID/SDID info in the Media Type parameter.

Other standards track RFCs have referenced SMPTE standards as 
informative.  If you want this to be a normative reference then you will 
need to call this out in the IETF LC.  This allows the community to 
determine if the standard being referenced meets the criteria of a 
stable and vetted point of reference.  Please see RFC 4897.

> Response: SDI is an initialism.  The Chicago Manual of Style states "When an abbreviation follows an indefinite article, the choice of a or an is determined by the way the abbreviation would be rea…

OK.

Regards,

Shawn.
--