diff options
author | Timothy B. Terriberry <tterribe@xiph.org> | 2016-02-17 18:24:35 -0800 |
---|---|---|
committer | Timothy B. Terriberry <tterribe@xiph.org> | 2016-02-17 18:26:43 -0800 |
commit | 2d5b5ddeadb1be9c48fa80ff99ce60cae0560eba (patch) | |
tree | 8cdd868dc26799bcf8a391dc5ee9ede88894e69c /doc | |
parent | c2c600725419efaa252d1acd14d20a96a7bb017f (diff) | |
download | opus-2d5b5ddeadb1be9c48fa80ff99ce60cae0560eba.tar.gz |
oggopus: Address Barry Leiba's IESG comments.
Thanks to Barry for proposing specific text for the changes.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/draft-ietf-codec-oggopus.xml | 52 |
1 files changed, 30 insertions, 22 deletions
diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml index 1b4c1313..61da699b 100644 --- a/doc/draft-ietf-codec-oggopus.xml +++ b/doc/draft-ietf-codec-oggopus.xml @@ -248,12 +248,16 @@ The first audio data page could have the 'continued packet' flag set (indicating the first audio data packet is continued from a previous page) if, for example, it was a live stream joined mid-broadcast, with the headers pasted on the front. -A demuxer SHOULD NOT attempt to decode the data for the first packet on a page - with the 'continued packet' flag set if the previous page with packet data - does not end in a continued packet (i.e., did not end with a lacing value of - 255) or if the page sequence numbers are not consecutive, unless the demuxer - has some special knowledge that would allow it to interpret this data - despite the missing pieces. +If a page has the 'continued packet' flag set and one of the following + conditions is also true: +<list style="symbols"> +<t>the previous page with packet data does not end in a continued packet (does + not end with a lacing value of 255) OR</t> +<t>the page sequence numbers are not consecutive,</t> +</list> + then a demuxer MUST NOT attempt to decode the data for the first packet on the + page unless the demuxer has some special knowledge that would allow it to + interpret this data despite the missing pieces. An implementation MUST treat a zero-octet audio data packet as if it were a malformed Opus packet as described in Section 3.4 of <xref target="RFC6716"/>. @@ -266,12 +270,17 @@ There is no reason for the final packet on the last page to be a continued packet, i.e., for the final lacing value to be 255. However, demuxers might encounter such streams, possibly as the result of a transfer that did not complete or of corruption. -A demuxer SHOULD NOT attempt to decode the data from a packet that continues - onto a subsequent page (i.e., when the page ends with a lacing value of 255) - if the next page with packet data does not have the 'continued packet' flag - set or does not exist, or if the page sequence numbers are not consecutive, - unless the demuxer has some special knowledge that would allow it to interpret - this data despite the missing pieces. +If a packet continues onto a subsequent page (i.e., when the page ends with a + lacing value of 255) and one of the following conditions is also true: +<list style="symbols"> +<t>the next page with packet data does not have the 'continued packet' flag + set OR</t> +<t>there is no next page with packet data OR</t> +<t>the page sequence numbers are not consecutive,</t> +</list> + then a demuxer MUST NOT attempt to decode the data from that packet unless the + demuxer has some special knowledge that would allow it to interpret this data + despite the missing pieces. There MUST NOT be any more pages in an Opus logical bitstream after a page marked 'end of stream'. </t> @@ -1541,14 +1550,13 @@ A brief summary of major implementations of this draft is available Implementations of the Opus codec need to take appropriate security considerations into account, as outlined in <xref target="RFC4732"/>. This is just as much a problem for the container as it is for the codec itself. -Robustness against malicious payloads is extremely important. -Malicious payloads MUST NOT cause an implementation to overrun its allocated - memory or to take an excessive amount of resources to decode. -Although problems in encoding applications are typically rarer, the same - applies to the muxer. -Malicious audio input streams MUST NOT cause an implementation to overrun its - allocated memory or consume excessive resources because this would allow an - attacker to attack transcoding gateways. +Malicious payloads and/or input streams can be used to attack codec + implementations. +Implementations MUST NOT overrun their allocated memory nor consume excessive + resources when decoding payloads or processing input streams. +Although problems in encoding applications are typically rarer, this still + applies to a muxer, as vulnerabilities would allow an attacker to attack + transcoding gateways. </t> <t> @@ -1668,8 +1676,8 @@ IANA is requested to create a new name space of "Opus Channel Mapping Families". This will be a new registry on the IANA Matrix, and not a subregistry of an existing registry. -Modifications to this registry follow the "Specification Required with Expert - Review" registration policy as defined in <xref target="RFC5226"/>. +Modifications to this registry follow the "Specification Required" registration + policy as defined in <xref target="RFC5226"/>. Each registry entry consists of a Channel Mapping Family Number, which is specified in decimal in the range 0 to 255, inclusive, and a Reference (or list of references) |