Subject: [AVT] Comments on draft-ietf-avt-rtp-h264-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Nov 2002 15:11:52 +0100

Hi Stephan,

I have some comments on the draft:

1. I can't quite understand how the STAP and MTAP are going to be used. 
How are the fields arranged? It could also be clearer that STAP and MTAP 
are NALU headers them self with some fields of there own. My can guess 
of how STAP packet would look like:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NSI|STAP=0x18| 16 bit length field of NALU #1| NAL Header #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAL Data ...                                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | 16-bit Length Field NALU #2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NAL Header 2   | NAL DATA ...                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then it looks similar for MTAP with the only difference that each NAL 
would be prefixed with a offset field equal in size to the MTAP used. 
This would make it look like:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NSI|MTAP=0x21| 16 bit length field of NALU #1| TS offset     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  TS offset cont. 24 bits      | NAL Header #1 | NAL Data ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               | 16-bit Length Field NALU #2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  TS offset 24 bits                            |NAL Header 2   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAL DATA ...                                                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                                                               :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It seem that there can be some variations on the MTAP scheme. One could 
use one MTAP header per NALU so only the needed size would be used. 
However that would probably not, be any more efficient.

Please improve the description and add some bit field examples to 
clarify things. 

2. RTP header values. I can't understand that this specification should 
hard code the three fields of version, padding and extension. In the 
case of version, that should be set according to the RTP version used. 
And this specification will refer and be defined for version 2. Why must 
it be forbidden to pad a H.264 payload? If no concrete reason exist this 
is up to the application and should be set in accordance with the RTP 
spec. There might be requirements to pad for certain transport or 
encryption schemes. Also the use of extension header I don't see that 
the payload format has anything to do with. Let the field be set in 
accordance with RTP spec.

3. The security consideration. It should mention the fragility of the 
parameter sets. If I as an attacker of a video stream ensures that the 
PSI data is in error, that will totally destroy the quality of the 
stream. It is a point of weakness and should be authenticated and 
integrity protected.

4. Section 10.3 The packet duplication is normally due to the network 
and not the UDP.

5. For the first open issue I would like to have some clarification on 
how the MTAP is packed before giving any opinion.

6. When will we see a MIME parameter definition and how to include it in 
SDP?

Regards

Magnus

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 05 Nov 2002 20:50:00 +0100

Hi Magnus,

Thanks for your comments.  Some replies inside.

At 03:11 PM 11/4/2002 +0100, Magnus Westerlund wrote:
>[...]
>are NALU headers them self with some fields of there own. [...]

I'm not really clear on this comment, but I would certainly agree that more 
examples would be helpful.  There are also some terminology issues that 
need to be resolved.  I agree, some work is needed.  Let's have a lunch in 
Atlanta that help me to fully understand your concerns.

>hard code the three fields of version, padding and extension. In the case 
>of version, that should be set according to the RTP version used. And this 
>specification will refer and be defined for version 2. Why must it be 
>forbidden to pad a H.264 payload? If no concrete reason exist this is up 
>to the application and should be set in accordance with the RTP spec. 
>There might be requirements to pad for certain transport or encryption 
>schemes. Also the use of extension header I don't see that the payload 
>format has anything to do with. Let the field be set in accordance with 
>RTP spec.

My understanding is as follows:
Version should be hard-coded to two.  A new version of RTP (if one ever is 
designed) will very likely make this payload spec obsolete.  This is 
in-line with most other payload RFCs.
Padding and Extension: with these two it is always a tradeoff between 
implementation complexity and flexibility.  Our choice was to restrict the 
spec to the minimum to make decoder design as simple as possible -- hence 
both are off.  We are willing to relax those restrictions if this is desirable.

>parameter sets. If I as an attacker of a video stream ensures that the PSI 
>data is in error, that will totally destroy the quality of the stream. It 
>is a point of weakness and should be authenticated and integrity protected.

A damaged or lost (or intentionally altered) parameter set does not hurt 
the integrity of a well-designed system beyond the video 
reproduction.  Hence I don't see a security issue here.  And, when you read 
H.264, you will find an ample amount of language stressing the importance 
of parameter sets.  I don't believe any action is required in the draft, 
and certainly not in the Security section.

>4. Section 10.3 The packet duplication is normally due to the network and 
>not the UDP.

Packet Duplication is meant here as a tool, used intentionally, to increase 
the chances that a certain packet makes it to the receiver.  Meaning, an 
sender transmits the same RTP packet twice (with the same timestamp, 
sequence number, etc. etc.).  For the receiver this looks like as the 
duplication has occurred in the network.  But if one packet is lost, the 
other is still available.

>5. For the first open issue I would like to have some clarification on how 
>the MTAP is packed before giving any opinion.
>6. When will we see a MIME parameter definition and how to include it in SDP?

Soon :-)  I usually leave this stuff to the very end.  Particularly in 
projects where more then one standardization body wants to have a say how 
its stuff is called.

Again, thanks for your remarks.

Stephan

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 Nov 2002 11:15:51 +0100

Hi Stephan,

More comments inline:

Stephan Wenger wrote:

>> 1. I can't quite understand how the STAP and MTAP are going to be 
>> used. How are the fields arranged? It could also be clearer that STAP 
>> and MTAP are NALU headers them self with some fields of there own. [...]
>> It seem that there can be some variations on the MTAP scheme. One 
>> could use one MTAP header per NALU so only the needed size would be 
>> used. However that would probably not, be any more efficient.
>
>
> I'm not really clear on this comment, but I would certainly agree that 
> more examples would be helpful.  There are also some terminology 
> issues that need to be resolved.  I agree, some work is needed.  Let's 
> have a lunch in Atlanta that help me to fully understand your concerns.

Yes, we can meet in atlanta. My concerns are related to how you build up 
the payload using either MTAP or STAP. Are my bit figure examples inline 
with how you think that the payload are going to be aggregated? I made 
my figures using on of several schemes I see that are possible. 

I also seem potential problems but at the same time advantages with 
assigning the MTAP and STAP from the same number series as NALU 
identifiers. Are you going to reserve these number in the MPEG and ITU 
domain so no future collisions can occur?

>
>> 2. RTP header values. I can't understand that this specification 
>> should hard code the three fields of version, padding and extension. 
>> In the case of version, that should be set according to the RTP 
>> version used. And this specification will refer and be defined for 
>> version 2. Why must it be forbidden to pad a H.264 payload? If no 
>> concrete reason exist this is up to the application and should be set 
>> in accordance with the RTP spec. There might be requirements to pad 
>> for certain transport or encryption schemes. Also the use of 
>> extension header I don't see that the payload format has anything to 
>> do with. Let the field be set in accordance with RTP spec.
>
>
> Version should be hard-coded to two.  A new version of RTP (if one 
> ever is designed) will very likely make this payload spec obsolete.  
> This is in-line with most other payload RFCs.
> implementation complexity and flexibility.  Our choice was to restrict 
> the spec to the minimum to make decoder design as simple as possible 
> -- hence both are off.  We are willing to relax those restrictions if 
> this is desirable.

Both padding and extension header is mechanisms on RTP level and which 
must be supported by the RTP stack. There is no implementation gain in 
forbidding them for a certain payload type. All RTP stacks must be able 
to calculate the correct starting point of the payload and also be able 
to determine where it ends. The use of padding is decided by other 
factors in the system, for example transport layers or encryption. 
Therefore to achieve maximum usability of the H.264 payload format they 
should not put in unnecessary restrictions. The use of extensions header

>> parameter sets. If I as an attacker of a video stream ensures that 
>> the PSI data is in error, that will totally destroy the quality of 
>> the stream. It is a point of weakness and should be authenticated and 
>> integrity protected.
>
>
> A damaged or lost (or intentionally altered) parameter set does not 
> hurt the integrity of a well-designed system beyond the video 
> reproduction.  Hence I don't see a security issue here.  And, when you 
> read H.264, you will find an ample amount of language stressing the 
> importance of parameter sets.  I don't believe any action is required 
> in the draft, and certainly not in the Security section. 

Changing the SDP is a way of doing denial of service. This seems to be 
possible to make rather subtle when changing the parameter set. A valid 
parameter set but not the correct one for this stream will first be 
detected when you have started playing media. Therefore the SDP should 
be authenticated. Relying on that all people will read the H.264 spec to 
understand this is optimistic. If doing integration work of a codec into 
a system it can very well be enough to look at payload format. Therefore 
I see a need to include maybe redundant information in the security 
section.

> Packet Duplication is meant here as a tool, used intentionally, to 
> increase the chances that a certain packet makes it to the receiver.  
> Meaning, an sender transmits the same RTP packet twice (with the same 
> timestamp, sequence number, etc. etc.).  For the receiver this looks 
> like as the duplication has occurred in the network.  But if one 
> packet is lost, the other is still available. 

Yes, I understand this, but I believe the language can be more correct.

Best Regards

Magnus Westerlund