Subject: [AVT] Meeting minutes for the Token call (Dec. 16th)

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 16 Dec 2010 07:37:09 -0800

We had a call today to discuss the open issues in the Token draft. I would like to thank those who attended: Keith, Roni, Colin, Glen and Dan.

Below, I will list the issues and the proposals suggested by the folks above. We need your comments on these by Monday (20th), and then we will proceed with a revision, which will hopefully be a stable version ready for the WGLC. The co-chairs will update the list about the WGLC schedule considering the holiday break.

Thanks,
-acbegen

1) The place where to put the SDP attribute in the description:

There was a disagreement about where to put the "a=portmapping-req" line. Here is the proposal. We will create a new attribute for the multicast block (a=portmapping) and use the existing attribute only in the unicast block (a=portmapping-req:port). The attribute in the multicast block will tell the clients that the unicast session(s) associated with this multicast session will require token for certain messages. The attribute in the unicast block tells the clients where to get the token from.

The association of the two attributes will be inferred from the a=group line. I.e., if the m lines are grouped together, the portmapping and portmapping-req attributes of those media streams will be correlated. See the example below.

        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=portmapping
        a=mid:1
        m=video 42000 RTP/AVPF 99                              
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.1
        ...
--->  a=portmapping-req:30000                             
        a=mid:2

2) Which packets require token:

There was a comment asking the SDP attribute to explicitly specify the messages that will require token. Doing this in the SDP proves to be difficult. The syntax is error prone (kinda messy). And the packet types the server may require a token with may change over time (suppose the server gets suspicious of an attack and now may want authentication via tokens).

Proposal: The server will list the packet types that it will require a token for in the Port Mapping Response (when it sends the token). We will add a new field (more likely to be a length-value field) that will list the RTCP packet types explicitly. For example, if transport-layer feedback messages require a Token, it will include 205. If BYE requires a token, it will include 203, as well.

Do we need to consider feedback message types separately? For example, 205 would cover for NACK, CCMs, RAMS, etc. I think listing only the packet types (8 bits) is sufficient since it is pretty unlikely that all kinds of feedback messages (RAMS + CCM or others) will be used within a single unicast session. Comments?

If the server changes his mind during the session (suppose a XYZ message did not require a token initially but now it does), the server SHALL NOT send a new Port Mapping Response. Client will learn about it when and if it gets a failure message. Servers SHOULD NOT change their minds until the expiration time.

3) Whether messages controlling a unicast session require a token or not:

See Roni's earlier email. Proposal is that such messages (listed in 4.3.1) will not require a token if there is another authentication method in place for that specific application (like SRTCP). However, tokens will always be needed for the unicast session establishment.

4) Limiting the RTP flow direction to server-> client only

This was agreed. If there will be RTP traffic flowing from the client to the server, the token approach does not apply anyway.

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 17 Dec 2010 11:39:40 +0100

Ali,

I have a comment on item 2. See below.

I also think the offer/answer paragraph is still confusing and incorrect:

There is text now that says:

  "An offerer that desires the answerer to use Tokens in RTCP messages
   sent to the server, i.e., received by the server, the attribute is
   included.  In case an offerer desires to declare support for using
   Tokens as defined in this specification but do not need Tokens to be
   included for any RTCP messages to be received by the server, it can   
include the 'portmapping-req' attribute without any parameters,
   neither port nor address."

..I realise the text still needs to be updated to take into account the fact there are two attributes now, but what is bothering me is that in the non- offer/answer model, whenever the attributes are there, tokens MUST be used. Period. How can an offerer now "desire to declare support for using tokens as defined in this specification, but do NOT need Tokens to be included (..)" ?? This is conflicting! Other fragment texts in the offerer/answer need to be modified as well if everyone agrees there is a contradiction here..

Items 1 ,3 and 4 are OK.
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: donderdag 16 december 2010 16:37
To: [email-masked]
Cc: [email-masked]; DRAGE, Keith (Keith); Colin Perkins; [email-masked]
Subject: [AVT] Meeting minutes for the Token call (Dec. 16th)

Thanks,
-acbegen

        a=group:FID 1 2
        a=rtcp-unicast:rsi

Tom: as an example given the fact that e.g. a bye message can be sent in the unicast and the multicast session, one may start arguing that indicating the RTCP packet type is not enough, also a session indication would be needed. But I am not in favour of that. I would like that we just define the fields that allow to signal in the port mapping response message (just) the RTCP packet types. This would not be mandatory. But if a server needs to have a token for a certain RTCP message, and it was missing, the server MUST send the token verification failure message, the way you defined it in the current version (packet type and FMT field). Related to that: in section 4.4. (token verification failure message), we should write  explicitly that this message  must be sent back to the client in the same session in which the client sent the RTCP message with missing or incorrect token verification request, triggering the server to send this token verification failure messsage.   

Plus: it would make sense to state that RTCP messages with the token Packet Type, shall never require a token.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 17 Dec 2010 08:13:33 -0800

Hi Tom,

> From: Van Caenegem, Tom (Tom) [mailto:[email-masked]]
> Sent: Friday, December 17, 2010 5:40 AM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: Dan Wing (dwing); DRAGE, Keith (Keith); Colin Perkins; [email-masked]
> Subject: RE: Meeting minutes for the Token call (Dec. 16th)
> 
> Ali,
> 
> ..I realise the text still needs to be updated to take into account the fact there are two attributes now, but what is bothering
> me is that in the non- offer/answer model, whenever the attributes are there, tokens MUST be used. Period. How can an
> offerer now "desire to declare support for using tokens as defined in this specification, but do NOT need Tokens to be
> included (..)" ?? This is conflicting! Other fragment texts in the offerer/answer need to be modified as well if everyone
> agrees there is a contradiction here..

I will work on the text you sent offline. 
 
> There was a comment asking the SDP attribute to explicitly specify the messages that will require token. Doing this in the
> SDP proves to be difficult. The syntax is error prone (kinda messy). And the packet types the server may require a token with
> may change over time (suppose the server gets suspicious of an attack and now may want authentication via tokens).
> 
> Proposal: The server will list the packet types that it will require a token for in the Port Mapping Response (when it sends the
> token). We will add a new field (more likely to be a length-value field) that will list the RTCP packet types explicitly. For
> example, if transport-layer feedback messages require a Token, it will include 205. If BYE requires a token, it will include
> 203, as well.
> 
> Do we need to consider feedback message types separately? For example, 205 would cover for NACK, CCMs, RAMS, etc. I
> think listing only the packet types (8 bits) is sufficient since it is pretty unlikely that all kinds of feedback messages (RAMS +
> CCM or others) will be used within a single unicast session. Comments?
> 
> If the server changes his mind during the session (suppose a XYZ message did not require a token initially but now it does),
> the server SHALL NOT send a new Port Mapping Response. Client will learn about it when and if it gets a failure message.
> Servers SHOULD NOT change their minds until the expiration time.
> 
> Tom: as an example given the fact that e.g. a bye message can be sent in the unicast and the multicast session, one may start
> arguing that indicating the RTCP packet type is not enough, also a session indication would be needed. But I am not in favour

We all need to remember that the messages that might need a Token all have something to do with the unicast session. So, a BYE sent for the multicast session does not qualify for this and thus does not need a Token. I think it is important to realize this.

> of that. I would like that we just define the fields that allow to signal in the port mapping response message (just) the RTCP
> packet types. This would not be mandatory. But if a server needs to have a token for a certain RTCP message, and it was
> missing, the server MUST send the token verification failure message, the way you defined it in the current version (packet

Right.

> type and FMT field). Related to that: in section 4.4. (token verification failure message), we should write  explicitly that this
> message  must be sent back to the client in the same session in which the client sent the RTCP message with missing or
> incorrect token verification request, triggering the server to send this token verification failure messsage.

Example, if NACK did not have a Token. The failure message needs to go from P3 to c1, no? If RAMS-R did not have a Token, failure message (and the RAMS-I with the new error code) needs to go from P3 to c1, too, no?

And since this pair is used in both sessions, I am not sure how we can write what you say above.
 
> Plus: it would make sense to state that RTCP messages with the token Packet Type, shall never require a token.

We can add this.

-acbegen