Subject: [AVT] Review of draft-ietf-avt-ports-for-ucast-mcast-rtp-08

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Dec 2010 14:43:09 +0100

Hi,

I have re-read the whole of the draft and have the following question,
comments or suggestions for improvements. I would say that we are fare
from done. Having had the opportunity to think about this has raised a
number of questions when considering this port mapping in the wider
scope as a general RTP extension.

1. Section 3.1: "By default, Tokens are server specific.  However, the
client
   can use the same Token to communicate with different servers if these
   servers are provided with the same secret key and algorithm used to
   generate the Token and are at least loosely clock-synchronized."

How a client determine this is the case still doesn't appear to be defined.

My suggestion is that a client determines if it has a valid token based
on the port and address of where to send the token request. But this
needs to be spelled out somewhere.

2. Section 3.1:
"The
   Token becomes invalid if client's public IP address changes or when
   the server expires the Token.  In these cases, the client has to
   request a new Token."

This might be misleading as the client in a number of cases can't
determine if an address change happens to them. Thus only determining
this when failure happens.

3. Structure of section 3.

I think some clean up of the structure is needed. The following
structural issues I have detected.

- 3.2 Says Unicast Session Establishment, despite that 3.2.2 contains
steps (see step 3) that matches 3.1, like step 3.

- 3.2.2 appears to missplace and would make more sense as 3.3. That way
3.2 could be more focused on the establishment of the unicast session.

- I also wonder if the example in 3.2.1 shouldn't be part of an
introductory case.

- In general I think I would like to skip this description based on an
example and more focus on the core pieces of the technology. Thus having
a description of that rather than the example. I think it to a certain
degree is taken up aspects that aren't needed.

4. Figure 2: Can you please move up the NAT text so that it doesn't say
"NA-T"

5. Section 3.2.1: "Ports *c0, *c1 and *c2 " bullet:

There is no discussion of if C2 should be equal to C1 or not. I think
there might be actually considerations here. This have to do with the
binding of the RTCP reports to the unicast session transmission
happening P3 -> C1. If that isn't possible then the server doesn't know
for which outgoing transmission the reports are for. I think also C3 has
to be equal to C2, or the server can't match on anything on transport
level. However, if the NAT is not address and port independent mapping
also that breaks down due the NAT properties.

If one are going to enable to mapp on heuristics then I think the only
possibility for the server is to mapp on reported SSRC's and ensure to
use unique SSRC identifiers across all unicast RTP session going out
from P3.

Or have I forgotten something here?

6. Section 3.2.2:

I am missing an RTP session definitions. I would like to have something
along the following lines included. This I think is the main part of how
a unicast session is established.

Port mapping starts with a primary RTP session, where the server acting
on a port mapping request has an unidirectional flow of RTCP messages
from the client port (C1) to the server on a designated port (P3). There
MUST be no RTCP traffic related to the primary RTP session being sent
from P3 on the server to the client on port (C1).

Upon a port mapping request RTCP message in the primary session from the
client on local port (C1) to the server port (P3) a new RTP point to
point unicast RTP session is created, unless active RTP session within
this context already exist. This new session consist of one leg of
multiplex RTP and RTCP messages from the Server (P3) to the client (C1).
The client to server leg in this unicast RTP session is going from
client local port (C2 perhaps C1 if mandated to be equal) to the Server
port (P4). The server port for the unicast needs to be signaled to the
client.

The point I am trying to get across in the above is the need to make it
clear what flows of messages are considered to be different RTP sessions.

Another thing that I think is unclear is when an existing RTP session is
reused correctly. Like that a sequence of NACK messages for the same
primary RTP session shall of course continue to use the same RTP session.

A third thing is the connection of the SSRC spaces that happens between
these two sessions. That as RTCP response to requests in the primary are
going into the unicast sessions packet flow.

I have to say that this is starting more and more to trouble me as I
peel away the layers of implications. Can I please have a time machine
and go back 1.5 years and change things?

7. Section 3.2.2, bullet 4:

Until a unicast
       session is established, neither the server nor the client needs
       to send RTCP reports for the unicast session.

Well, my question based on this, is when it is considered to not any
longer be established. I see two issues around that needs to be made clear.

1. How long are the client and server going to send RTCP receiver
reports related to the RTP transmissions happening in the session. Are
this 5 reporting interval since last RTP traffic in the session, or
something else?

2. Secondly, what about RTCP BYE signaling? If either ends has sent
this, must the client select a new local port and never send any new
requests in the primary that ends up in this unicast session?

8. Section 3.2.2: RTP session question.

Are RTP packets in the direction C2->P4 forbidden? Currently there
doesn't appear to be any wording on this. Secondly, should it be
forbidden? Because I can see there is potential applications that needs
a client to server RTP stream, rather than the opposite. And as this is
a general RTP tool I think we need to work these questions out.

9. Section 4:
When a client sends a
   Port Mapping Request or Token Verification Request message but it
   does not receive a response back from the server (either a Port
   Mapping Response or Token Verification Failure message), it MAY
   resend its request by following the timer rules defined for RTCP
   feedback messages in Section 3.5 of [RFC4585] as a good practice.

What are the criteria the client shall use to determine when a packet it
sent is lost?

10. Section 4: Why does the fields for the messages say that they are
mandatory when none is optional to include?

11. Section 4.2:
   o  Token Element (Variable size):  Mandatory element that is used to
      carry the Token generated by the server.  This element is a
      Length-Value element.  The Length field, which is 8 bits,
      indicates the length (in octets) of the Value field that follows
      the Length field.  The Value field carries the Token (or more
      accurately, the output of the encoding process on the server).

I am missing a discussion about the 32-bit word aligment requirement
that RTCP messages has. This needs to be ensured and currently it
appears that the token is the only one that has variable length. Thus I
think it needs a requirement on being 32-bit aligned.

12. Section 4.2:
   o  Token Element (Variable size):  Mandatory element that is used to
      carry the Token generated by the server.  This element is a
      Length-Value element.  The Length field, which is 8 bits,
      indicates the length (in octets) of the Value field that follows
      the Length field.  The Value field carries the Token (or more
      accurately, the output of the encoding process on the server).

I don't think there is need for a length field in this field. One can
use the RTCP message length field to derive the length of this field.

13. Section 4.3:

I think the below text should be its own subsection somewhere.

Currently, the following RTCP messages are REQUIRED to be accompanied
   by a Token Verification Request message:

   o  Messages that trigger a new unicast session:

      *  NACK messages [RFC4585]

      *  RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp]

   o  Messages that control an existing unicast session associated with
      a multicast session:

      *  BYE messages [RFC3550]

      *  RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp]

      *  CCM messages [RFC5104]

   Other RTCP messages defined in the future, which could be abused to
   cause packet amplification attacks, SHOULD also be authenticated
   using the mechanism described in this document.  The Token
   Verification Request message might also be bundled with packets
   carrying RTCP receiver or extended reports.  While such packets do
   not have a strong security impact, a specific application might
   desire to have a more controlled reporting scheme from the clients.

14. Section 4.3:

   Other RTCP messages defined in the future, which could be abused to
   cause packet amplification attacks *, SHOULD also be authenticated
   using the mechanism described in this document.

at the * I think one should include "other types of denial of service
attacks"

15. Section 6:
A
   client that received a Token Verification Failure message can request
   a new Token from the server.

I am missing discussion one when there is persistent errors. I think
there should be some recommendation about exponentially backing off ones
tries to retrieve a new token and then use it.

One may also need to consider if one after a period should try to
retrieve fresh declaration information for the service one tries to
access to see if the error is there?

15. Section 7.1:

If used at a media level, the attribute MUST be used in a unicast
   media block.

I think this sentence should go. Because this is in conflict with the
current semantics. I think it is better to include the a=portmapping-req
attribute at the places where one needs to send token verification
requests in RTCP. Rather than consider this to be derived implicitly.

This would make the SDP example in Figure 7 look like this:

       v=0
        o=ali 1122334455 1122334466 IN IP4 nack.example.com
        s=Local Retransmissions
        t=0 0
        a=group:FID 1 2
        a=rtcp-unicast:rsi
        m=video 41000 RTP/AVPF 98
        i=Multicast Stream
        c=IN IP4 233.252.0.2/255
        a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1   ; Note 1
        a=rtpmap:98 MP2T/90000
        a=multicast-rtcp:41500                                 ; Note 1
        a=rtcp:42000 IN IP4 192.0.2.1                          ; Note 2
        a=rtcp-fb:98 nack                                      ; Note 2
        a=portmapping-req:30000                                ; Note 6
        a=mid:1
        m=video 42000 RTP/AVPF 99                              ; Note 3
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux                                             ; Note 4
        a=rtcp:42500                                           ; Note 5
        a=fmtp:99 apt=98; rtx-time=5000
        a=portmapping-req:30000                                ; Note 7
        a=mid:2

The line with Note 7 would only be needed if we actually use RTCP bye in
the nack context to kill of the unicast session. Otherwise I don't think
it is needed here in Nack. But if the unicast session was for RAMS, then
it would be needed.

16. RTCP bandwidth used for Token requests?

How does one signal the RTCP bandwidth used for controlling how often
one is allowed to send the Token Requests?

17. Section 8:

If you have an discussion of address pooling NATs I think the mentioning
on the on-path attacks that is possible should also be mentioned.

18. Section 9.1:

The Token, which is generated based on a client's IP address and
   expiration date, provides protection against denial-of-service (DoS)
   attacks.

To be correct I think one should add "off-path" before denial-of-service.

19.Section 10.3:

This registry
   is to be managed by the IANA according to the Specification Required
   policy of [RFC5226].

I wonder if this is the correct policy for this. I would like to have
some sanity checking proposals in this area. I would either say:

Expert review with a restriction that any registration request must have
a specification.

or

IETF Review

20. Section 10.3, the table seems to have spurious tab for 5-30.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 14 Dec 2010 06:32:00 -0800

As usual thanks for the detailed comments. I tried to give a good answer or response to each of the comments. However, I think some of the comments you made do not belong to this spec since they are related to behavior of general RTP and RTCP. See inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, December 14, 2010 8:43 AM
> To: IETF AVT WG; [email-masked]
> Subject: [AVT] Review of draft-ietf-avt-ports-for-ucast-mcast-rtp-08
> 
> Hi,
> 

The client does not need to know anything besides it is the same address (explicit or implicit from the c line) and the port.
 
> needs to be spelled out somewhere.

I think this is pretty obvious.
 
> this when failure happens.

If you read carefully, the text does not imply that the client knows when its address changes. It simply says "when client's address changes". 
 
> steps (see step 3) that matches 3.1, like step 3.

We can fix this.
 
> degree is taken up aspects that aren't needed.

We will check this part again, however, a number of people including myself find such introductory examples fairly useful to put everything into a context. 

It had some normative/informative parts mixed up (Colin's earlier comments) but the recent version does a decent job to explain the steps.
 
> 4. Figure 2: Can you please move up the NAT text so that it doesn't say

Done.

> There is no discussion of if C2 should be equal to C1 or not. I think

They could be the same as the text says.

> happening P3 -> C1. If that isn't possible then the server doesn't know

C2 is the port client uses to send the RTCP reports for the unicast session. They go to port P4, which is different than P3. Since P4 cannot be the same as P3, it does not matter what you choose for c2.

> also that breaks down due the NAT properties.

We don’t have a c3 in the figure or text.

> Or have I forgotten something here?

See my response above and let me know whether it addresses your concerns (which I probably did not get).
 
> from P3 on the server to the client on port (C1).

This agrees with figure 2.

> multiplex RTP and RTCP messages from the Server (P3) to the client (C1).

Correct.

> port (P4). The server port for the unicast needs to be signaled to the

Correct.

> clear what flows of messages are considered to be different RTP sessions.

This is what we convey with Figure 2. If you look at it, the sessions are properly separated and each session has a number of flows with directions and port numbers clearly identified. It is concrete and clear.

If further text is needed, we can put additional wording.
 
> primary RTP session shall of course continue to use the same RTP session.

Indeed, here we introduce nothing new. The regular RTP rules are still valid. If the session has timed out or was ended by a BYE, it ended. A subsequent NACK will open a new session. Ow, the existing session will continue.
 
> and go back 1.5 years and change things?

Probably you cannot. However, IMO, you are overthinking things in the sense some of the issues you raise above do not even belong to this spec. The SSRC behavior for example will be defined with the unicast application you are running. It could be RAMS, retransmission, multi-layer video, etc. They define their behavior individually.
 
> longer be established. I see two issues around that needs to be made clear.

Requesting and receiving Tokens does not create the unicast session. That is it.
 
> this 5 reporting interval since last RTP traffic in the session, or

Why define new rules here? This is just another RTP session and is supposed to follow the RTP rules.
 
> requests in the primary that ends up in this unicast session?

No, why would it mean that? BYE does not have such semantics.
 
> a general RTP tool I think we need to work these questions out.

Yes, they are forbidden. This was the choice since the beginning. If you need a full bi-directional RTP session on the unicast side, you can do a full offer/answer exchange to set up that session. It does not fit into this context anyway.
 
To make this crystal clear, we can say that no rtp traffic must flow from client to server.

> What are the criteria the client shall use to determine when a packet it

Seriously? The client is ruled by the timer rules. It has a min waiting time. Then, it can resend or give up. What is there to define here?
 
> mandatory when none is optional to include?

We can delete the "mandatory" words.
 
> think it needs a requirement on being 32-bit aligned.

Good point.
 
> use the RTCP message length field to derive the length of this field.

Since we plan to use padding, it is better to be explicit.
 
>    desire to have a more controlled reporting scheme from the clients.

Ok.
 
> at the * I think one should include "other types of denial of service

Sounds good.
 
> tries to retrieve a new token and then use it.

Would not 4585 scheduling algorithms take care of this? This is not different than sending broken NACKs for example. 
 
> access to see if the error is there?

If a server has given me a token valid for the next 12 hours, I can use it for the next 12 hours. If the service gets disabled in the mean time say after 6 hours, I will eventually get an error. So what? I can try to get a new token. Or, as you suggest I can be conservative and check with the server every hour to see whether I can get a valid token (because if the service got disabled, I won't get a valid token). This behavior is something up to the implementation. Either is fine and has pros/cons for different scenarios.

> requests in RTCP. Rather than consider this to be derived implicitly.

It is already gone since we currently switched to media-level attributes only. And the text simply says "The 'portmapping-req' attribute SHALL be used as a media-level attribute."

>         a=portmapping-req:30000                                ; Note 6

As I explained a few times before, putting this attribute here is a mistake. It needs to be in the unicast session associated with the multicast session. 

> it is needed here in Nack. But if the unicast session was for RAMS, then

I respectfully disagree that the attribute will be repeated in the multicast block. It does not make sense.
 
> one is allowed to send the Token Requests?

See the text just before section 4.1. 
 
> on the on-path attacks that is possible should also be mentioned.

Is this something different the ones already in section 9.1? I think the last sentence in the 1st paragraph is what you are looking for.
 
> To be correct I think one should add "off-path" before denial-of-service.

OK.
 
> Expert review with a restriction that any registration request must have

This is fine with me.
 
> 20. Section 10.3, the table seems to have spurious tab for 5-30.

Looks like IANA uses "Unassigned". I will change this accordingly.

-acbegen

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 14 Dec 2010 16:51:43 +0100

Magnus, Ali,

I concur with Ali's comments. I add a few more comments:
(delineated by <>Tom<>)

There is no discussion of if C2 should be equal to C1 or not. I think there might be actually considerations here. This have to do with the binding of the RTCP reports to the unicast session transmission happening P3 -> C1. If that isn't possible then the server doesn't know for which outgoing transmission the reports are for. I think also C3 has to be equal to C2, or the server can't match on anything on transport level. However, if the NAT is not address and port independent mapping also that breaks down due the NAT properties.

If one are going to enable to mapp on heuristics then I think the only possibility for the server is to mapp on reported SSRC's and ensure to use unique SSRC identifiers across all unicast RTP session going out from P3.

<>Tom: you seem to suggest two things here:
-mandate that C2 is equal to C1  (iso C3 and C2 in your text, I guess that was a mistake?). This is to enable a server to easily correlate the RTCP messages sent by the same client in the SSM and in the port mapped unicast session, right? I see no issue with that.
-mandate that the server uses unique SSRCs in each port mapped unicast session, across all port mapped unicast sessions that are sourced by the server. This does not work as with retransmission sessions, the SSRC is imposed by the SSM SSRC.

Because c1=c2 client ports are chosen at random, the server will need to do correlation across sessions and clients based on IP addresses, port and/or CNAMEs. Can we consider that the client must also choose its SSRC in the unicast session the same as the one used in the SSM session (which violates though the SSRC randomness principle)  
<> 

6. Section 3.2.2:

I am missing an RTP session definitions. I would like to have something along the following lines included. This I think is the main part of how a unicast session is established.

Port mapping starts with a primary RTP session, where the server acting on a port mapping request has an unidirectional flow of RTCP messages from the client port (C1) to the server on a designated port (P3). There MUST be no RTCP traffic related to the primary RTP session being sent from P3 on the server to the client on port (C1).

Upon a port mapping request RTCP message in the primary session from the client on local port (C1) to the server

<>Tom: you probably mean: "upon a token verification request RTCP message.."?
For the rest I am fine with this text proposal on what a (new) unicast session establishment means...
<>

 port (P3) a new RTP point to point unicast RTP session is created, unless active RTP session within this context already exist. This new session consist of one leg of multiplex RTP and RTCP messages from the Server (P3) to the client (C1).
The client to server leg in this unicast RTP session is going from client local port (C2 perhaps C1 if mandated to be equal) to the Server port (P4). The server port for the unicast needs to be signaled to the client.

The point I am trying to get across in the above is the need to make it clear what flows of messages are considered to be different RTP sessions.

Another thing that I think is unclear is when an existing RTP session is reused correctly. Like that a sequence of NACK messages for the same primary RTP session shall of course continue to use the same RTP session.

<>Tom: a session stays "alive" as long as no RTCP BYE is issued (and responded upon with BYE)
<>

A third thing is the connection of the SSRC spaces that happens between these two sessions. That as RTCP response to requests in the primary are going into the unicast sessions packet flow.

<>Tom: for the RAMS case the sender SSRCs are the same because of RFC 4588
What is the problem for the more generic (non RAMS or retransmission) case?
<>

I have to say that this is starting more and more to trouble me as I peel away the layers of implications. Can I please have a time machine and go back 1.5 years and change things?

<>Tom
Let me know please if you do find that time machine..