Ben Campbell wrote:
To quote the attached diff:
-Implementations SHOULD reject ID headers which do not contain enough
data for
- these fields, even if they contain a valid Magic Signature.
+Implementations SHOULD reject streams with ID headers that do not
contain
+ enough data for these fields, even if they contain a valid Magic
Signature.
I don't find that in the attached diff.
I meant the one that was attached to the e-mail to which you were
responding:
https://www.ietf.org/mail-archive/web/codec/current/msg03150.html
Sorry for being unclear.
application-level assumptions I'm not sure I'm comfortable writing
normative text around. Any ideas for a better way to phrase this?
"treat as invalid"?
I can work with that.
That text looks good, except that I would avoid normative language:
s/ "IANA SHALL..."/"IANA is requested to..."
s/"All maintenance within and additions to the contents of this name
space MUST be according"/"Modifications to this registry follow..."
Normative language removed.
Either, really. But obviously the 6716 was accepted, so it would be
easier to accept due to precedent. The question I have is whether that
precedent applies here. And you will recall that there was some
tooth-gnashing over it for 6716 :-)
I remember. I think the precedent does apply, since the issue is
including the RFC with the code package, not whether or not the RFC
itself contains code.
I'm curious--are there no other RFCs distributed in Debian?
Ron may have a better idea of real numbers, but it is certainly an issue
that has come up before. See
<https://wiki.debian.org/NonFreeIETFDocuments>, which links to a list of
bugreports. As Ron points out, there are a few RFCs that are distributed
because they included additional grants (after which the original grants
in draft-ietf-codec-opus and this draft were modeled). It does not
appear as if that page has been updated since RFC 6716 was published,
though.
I'll let that (as updated) go to IETF LC. But don't be surprised if
there's further discussion to be had here.
I fully expect it.
Additional changes for the above attached. If there are no more
comments, I can publish a new version with all of these included.
>From 451cc67936db4220038221aff684be8c617c751a Mon Sep 17 00:00:00 2001
From: "Timothy B. Terriberry" <[email protected]>
Date: Tue, 12 Jan 2016 13:08:27 -0800
Subject: [PATCH 1/2] oggopus: Replace 'reject' with 'treat as invalid'.
>From AD review.
---
doc/draft-ietf-codec-oggopus.xml | 48 ++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml
index 7489c20..b343e42 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -507,27 +507,27 @@ This does not affect the behavior of pre-skip: exactly 'pre-skip' samples
initial PCM sample position is greater than zero.
</t>
<t>
On the other hand, a granule position that is smaller than the number of
decoded samples prevents a demuxer from working backwards to assign each
packet or each individual sample a valid granule position, since granule
positions are non-negative.
-An implementation MUST reject as invalid any stream where the granule position
+An implementation MUST treat any stream as invalid if the granule position
is smaller than the number of samples contained in packets that complete on
the first audio data page with a completed packet, unless that page has the
'end of stream' flag set.
It MAY defer this action until it decodes the last packet completed on that
page.
</t>
<t>
-If that page has the 'end of stream' flag set, a demuxer MUST reject as invalid
- any stream where its granule position is smaller than the 'pre-skip' amount.
+If that page has the 'end of stream' flag set, a demuxer MUST treat any stream
+ as invalid if its granule position is smaller than the 'pre-skip' amount.
This would indicate that there are more samples to be skipped from the initial
decoded output than exist in the stream.
If the granule position is smaller than the number of decoded samples produced
by the packets that complete on that page, then a demuxer MUST use an initial
granule position of '0', and can work forwards from '0' to timestamp
individual packets.
If the granule position is larger than the number of decoded samples available,
then the demuxer MUST still work backwards as described above, even if the
@@ -751,23 +751,24 @@ Its contents are specified in <xref target="channel_mapping"/>.
</t>
</list>
</t>
<t>
All fields in the ID headers are REQUIRED, except for the channel mapping
table, which MUST be omitted when the channel mapping family is 0, but
is REQUIRED otherwise.
-Implementations SHOULD reject streams with ID headers that do not contain
- enough data for these fields, even if they contain a valid Magic Signature.
+Implementations SHOULD treat a stream as invalid if it contains an ID header
+ that does not have enough data for these fields, even if it contain a valid
+ Magic Signature.
Future versions of this specification, even backwards-compatible versions,
might include additional fields in the ID header.
If an ID header has a compatible major version, but a larger minor version,
- an implementation MUST NOT reject it for containing additional data not
- specified here, provided it still completes on the first page.
+ an implementation MUST NOT treat it as invalid for containing additional data
+ not specified here, provided it still completes on the first page.
</t>
<section anchor="channel_mapping" title="Channel Mapping">
<t>
An Ogg Opus stream allows mapping one number of Opus streams (N) to a possibly
larger number of decoded channels (M + N) to yet another number of
output channels (C), which might be larger or smaller than the number of
decoded channels.
@@ -1180,19 +1181,20 @@ This field contains a single user comment string.
There is one for each user comment indicated by the 'user comment list length'
field.
</t>
</list>
</t>
<t>
The vendor string length and user comment list length are REQUIRED, and
- implementations SHOULD reject comment headers that do not contain enough data
- for these fields, or that do not contain enough data for the corresponding
- vendor string or user comments they describe.
+ implementations SHOULD treat a stream as invalid if it contains a comment
+ header that does not have enough data for these fields, or that does not
+ contain enough data for the corresponding vendor string or user comments they
+ describe.
Making this check before allocating the associated memory to contain the data
helps prevent a possible Denial-of-Service (DoS) attack from small comment
headers that claim to contain strings longer than the entire packet or more
user comments than than could possibly fit in the packet.
</t>
<t>
Immediately following the user comment list, the comment header MAY
@@ -1205,19 +1207,20 @@ This allows informal experimentation with the format of this binary data until
it can be specified later.
</t>
<t>
The comment header can be arbitrarily large and might be spread over a large
number of Ogg pages.
Implementations MUST avoid attempting to allocate excessive amounts of memory
when presented with a very large comment header.
-To accomplish this, implementations MAY reject a comment header larger than
- 125,829,120 octets, and MAY ignore individual comments that are not fully
- contained within the first 61,440 octets of the comment header.
+To accomplish this, implementations MAY treat a stream as invalid if it has a
+ comment header larger than 125,829,120 octets, and MAY ignore individual
+ comments that are not fully contained within the first 61,440 octets of
+ the comment header.
</t>
<section anchor="comment_format" title="Tag Definitions">
<t>
The user comment strings follow the NAME=value format described by
<xref target="vorbis-comment"/> with the same recommended tag names:
ARTIST, TITLE, DATE, ALBUM, and so on.
</t>
@@ -1294,28 +1297,29 @@ In the authors' investigations they were not applied consistently or broadly
<t>
Technically, valid Opus packets can be arbitrarily large due to the padding
format, although the amount of non-padding data they can contain is bounded.
These packets might be spread over a similarly enormous number of Ogg pages.
When encoding, implementations SHOULD limit the use of padding in audio data
packets to no more than is necessary to make a variable bitrate (VBR) stream
constant bitrate (CBR), unless they have no reasonable way to determine what
is necessary.
-Demuxers SHOULD reject audio data packets (treat them as if they were malformed
- Opus packets with an invalid TOC sequence) larger than 61,440 octets per
- Opus stream, unless they have a specific reason for allowing extra padding.
+Demuxers SHOULD treat audio data packets as invalid (treat them as if they were
+ malformed Opus packets with an invalid TOC sequence) if they are larger than
+ 61,440 octets per Opus stream, unless they have a specific reason for
+ allowing extra padding.
Such packets necessarily contain more padding than needed to make a stream CBR.
Demuxers MUST avoid attempting to allocate excessive amounts of memory when
presented with a very large packet.
-Demuxers MAY reject or partially process audio data packets larger than
- 61,440 octets in an Ogg Opus stream with channel mapping families 0
- or 1.
-Demuxers MAY reject or partially process audio data packets in any Ogg Opus
- stream if the packet is larger than 61,440 octets and also larger than
- 7,680 octets per Opus stream.
+Demuxers MAY treat audio data packets as invalid or partially process them if
+ they are larger than 61,440 octets in an Ogg Opus stream with channel
+ mapping families 0 or 1.
+Demuxers MAY treat audio data packets as invalid or partially process them in
+ any Ogg Opus stream if the packet is larger than 61,440 octets and also
+ larger than 7,680 octets per Opus stream.
The presence of an extremely large packet in the stream could indicate a
memory exhaustion attack or stream corruption.
</t>
<t>
In an Ogg Opus stream, the largest possible valid packet that does not use
padding has a size of (61,298*N - 2) octets.
With 255 streams, this is 15,630,988 octets and can
span up to 61,298 Ogg pages, all but one of which will have a granule
--
1.8.3.2
>From db33abdc906978dae74c7b2c54494b4a9c46707f Mon Sep 17 00:00:00 2001
From: "Timothy B. Terriberry" <[email protected]>
Date: Tue, 12 Jan 2016 13:12:22 -0800
Subject: [PATCH 2/2] oggopus: Remove normative language from IANA registry.
>From AD review.
---
doc/draft-ietf-codec-oggopus.xml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml
index b343e42..05bdae1 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -1546,20 +1546,20 @@ This document updates the IANA Media Types registry to add .opus
as a file extension for "audio/ogg", and to add itself as a reference
alongside <xref target="RFC5334"/> for "audio/ogg", "video/ogg", and
"application/ogg" Media Types.
</t>
<t>
This document defines a new registry "Opus Channel Mapping Families" to
indicate how the semantic meanings of the channels in a multi-channel Opus
stream are described.
-IANA SHALL create a new name space of "Opus Channel Mapping Families".
-All maintenance within and additions to the contents of this name space MUST be
- according to the "Specification Requried with Expert Review" registration
- policy as defined in <xref target="RFC5226"/>.
+IANA is requested to create a new name space of "Opus Channel Mapping
+ Families".
+Modifications to this registry follow the "Specification Requried with Expert
+ Review" 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)
Each Reference must point to sufficient documentation to describe what
information is coded in the Opus identification header for this channel
mapping family, how a demuxer determines the Stream Count ('N') and Coupled
Stream Count ('M') from this information, and how it determines the proper
interpretation of each of the decoded channels.
--
1.8.3.2
_______________________________________________
codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/codec
