Subject: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-08

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 11 Dec 2010 09:28:51 -0800

This revision changes the packet formats for port mapping. We are no longer using the RTCP feedback packet format, instead we defined a new RTCP control packet format. This was brought up by Colin and Magnus.

I checked the registry (for RTCP packet types) and grabbed the first available number (210) for TOKEN. If anybody else is using it for something else or planning to use it for something else, now is a good time to let us know. We don't want any surprises later.

For diff:
https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp/history/

Regarding the final remaining open issue, Magnus and I would like to hear from others. See the thread here:
http://www.ietf.org/mail-archive/web/avt/current/msg14028.html

It is about whether the SDP should somehow signal what RTCP packets/messages need to carry a Token (and where the 'portmapping-req' attribute should be placed - in the multicast or unicast block in the SDP. As the authors, we believe the current text in section 4.3 is sufficient and in addition there is no clear way of doing this in the SDP without introducing new issues. At the end, the cost for a client who was supposed to use a Token but did not is merely a small delay, which is not necessarily an additive delay. Thus, we think the additional complexity does not justify getting rid of this cost.

We would appreciate your views on this.

Thanks,
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Saturday, December 11, 2010 12:18 PM
To: Ali C. Begen (abegen)
Cc: Dan Wing (dwing); [email-masked]
Subject: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-08 

A new version of I-D, draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt has been successfully submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-ietf-avt-ports-for-ucast-mcast-rtp
Revision:	 08
Title:		 Port Mapping Between Unicast and Multicast RTP Sessions
Creation_date:	 2010-12-11
WG ID:		 avt
Number_of_pages: 33

Abstract:
This document presents a port mapping solution that allows RTP
receivers to choose their own ports for an auxiliary unicast session
in RTP applications using both unicast and multicast services.  The
solution provides protection against denial-of-service attacks that
could be used to cause one or more RTP packets to be sent to a victim
client.

The IETF Secretariat.

---

From: David R Oran <[email-masked]>
Date: Sat, 11 Dec 2010 15:05:52 -0500

> This revision changes the packet formats for port mapping. We are no longer using the RTCP feedback packet format, instead we defined a new RTCP control packet format. This was brought up by Colin…
Looks good.

> It is about whether the SDP should somehow signal what RTCP packets/messages need to carry a Token (and where the 'portmapping-req' attribute should be placed - in the multicast or unicast block in the SDP. As the authors, we believe the current text in section 4.3 is sufficient and in addition there is no clear way of doing this in the SDP without introducing new issues.
Whether this adds complexity issues probably depends on exactly what the semantic is. For example, if the SDP represents a "hint" to the client to try to use a token request as opposed to a requirement that his request won't work otherwise, I don't see a big problem. Clients that don't take the hint still work, with the extra RTT.

> At the end, the cost for a client who was supposed to use a Token but did not is merely a small delay, which is not necessarily an additive delay. Thus, we think the additional complexity does not justify getting rid of this cost.
> 
On balance I think this is a small point and would be happy either with or without the extra SDP signaling. There is a small advantage to being explicit in the SDP signaling about everything that is in use in the RTP session, but we are not consistent about this throughout the RTP architecture so this would not be the first time that RTP behavior was not completely captured by the corresponding SDP.

DaveO.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 11 Dec 2010 16:46:12 -0800

> > It is about whether the SDP should somehow signal what RTCP packets/messages need to carry a Token (and where the
> 'portmapping-req' attribute should be placed - in the multicast or unicast block in the SDP. As the authors, we believe the
> current text in section 4.3 is sufficient and in addition there is no clear way of doing this in the SDP without introducing new
> issues.
> Whether this adds complexity issues probably depends on exactly what the semantic is. For example, if the SDP represents a
> "hint" to the client to try to use a token request as opposed to a requirement that his request won't work otherwise, I don't
> see a big problem. Clients that don't take the hint still work, with the extra RTT.

The existing attribute is already stronger than a "hint", why would we need something "weaker" here? Or, do we wanna make the existing attribute weaker so that it is indeed a hint and those who ignore it will incur an RTT delay?
 
> > At the end, the cost for a client who was supposed to use a Token but did not is merely a small delay, which is not
> necessarily an additive delay. Thus, we think the additional complexity does not justify getting rid of this cost.
> >
> On balance I think this is a small point and would be happy either with or without the extra SDP signaling. There is a small
> advantage to being explicit in the SDP signaling about everything that is in use in the RTP session, but we are not consistent
> about this throughout the RTP architecture so this would not be the first time that RTP behavior was not completely captured
> by the corresponding SDP.

Good point. 

As a wild idea, how would you react if actually any client that implemented Token tried to get a Token regardless of whether they would use/need or not? If the server does not implement Token, the request will be ignored and the client will be fine anyway. If the server implements Token, it will return a Token to the client and the client can use it as long as it is valid. There is no visible cost to the client in doing this. The cost on the server is the effort spent to generate the Token.

This could save the RTT delay Magnus is worried about.

-acbegen

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Dec 2010 13:44:13 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> David R Oran
> Sent: Saturday, December 11, 2010 12:06 PM
> Cc: [email-masked]
> Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-
> ports-for-ucast-mcast-rtp-08
> 
> 
> > This revision changes the packet formats for port mapping. We are no
> longer using the RTCP feedback packet format, instead we defined a new
> RTCP control packet format. This was brought up by Colin and Magnus.
> >
> Looks good.
> 
> > I checked the registry (for RTCP packet types) and grabbed the first
> available number (210) for TOKEN. If anybody else is using it for
> something else or planning to use it for something else, now is a good
> time to let us know. We don't want any surprises later.
> >
> > For diff:
> > It is about whether the SDP should somehow signal what RTCP
> packets/messages need to carry a Token (and where the 'portmapping-req'
> attribute should be placed - in the multicast or unicast block in the
> SDP. As the authors, we believe the current text in section 4.3 is
> sufficient and in addition there is no clear way of doing this in the
> SDP without introducing new issues.
> Whether this adds complexity issues probably depends on exactly what
> the semantic is. For example, if the SDP represents a "hint" to the
> client to try to use a token request as opposed to a requirement that
> his request won't work otherwise, I don't see a big problem. Clients
> that don't take the hint still work, with the extra RTT.
I like that.  It would always up to the server (not the SDP) to decide 
if the server needs a token, anyway; this would just codify it that the 
SDP is a hint to avoid a round trip.  This is better than an idea I
was kicking around, which was for the client to just always include
a token in every RTCP message (which has no computational burden to
the client).

-d

> > At the end, the cost for a client who was supposed to use a Token but
> did not is merely a small delay, which is not necessarily an additive
> delay. Thus, we think the additional complexity does not justify
> getting rid of this cost.
> >
> On balance I think this is a small point and would be happy either with
> or without the extra SDP signaling. There is a small advantage to being
> explicit in the SDP signaling about everything that is in use in the
> RTP session, but we are not consistent about this throughout the RTP
> architecture so this would not be the first time that RTP behavior was
> not completely captured by the corresponding SDP.
> 
> DaveO.
> 
> 
> > Thanks,
> > -acbegen
> >
> > A new version of I-D, draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt
> has been successfully submitted by Ali Begen and posted to the IETF
> repository.
> >

---

From: Colin Perkins <[email-masked]>
Date: Mon, 13 Dec 2010 22:55:09 +0000

Looks good.

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Dec 2010 10:47:04 +0100

> a token in every RTCP message (which has no computational burden to

I think that is fine with me. A hint is all I ever wanted as I did
consider this as a potential interop issue. If you have a hint from the
server that you should send tokens on the following message types or I
will likely send an error that resolves that concern for me.

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: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 14 Dec 2010 11:24:49 +0100

Magnus, Ali, Dan,

My interpretation of below expressed thoughts is that the "hint" is not an per RTCP message basis. So, the port mapping attribute indicates token support at the server side, it does not (necessarily) say that each RTCP message must be accompanied with atoken. It would be still up to the server to decide whether it services a RTCP message that is sent by the client without a token. This can be a decision on the basis of the kind of RTCP message that was sent (triggering a dedicated action at the server side). If the server does need a token, and there was none, there is the additional round trip time penalty for the client, as the server will send the token verification reponse message. This can be avoided by the client when it always sends a token with every RTCP message, or it can be avoided for the next time as the client learns on the fly which messages require tokens.  I am in favour of this.

Tom

> if the server needs a token, anyway; this would just codify it that 
> the SDP is a hint to avoid a round trip.  This is better than an idea 
> I was kicking around, which was for the client to just always include 

I think that is fine with me. A hint is all I ever wanted as I did consider this as a potential interop issue. If you have a hint from the server that you should send tokens on the following message types or I will likely send an error that resolves that concern for me.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Dec 2010 11:32:28 +0100

> My interpretation of below expressed thoughts is that the "hint" is not an per RTCP message basis. So, the port mapping attribute indicates token support at the server side, it does not (necessaril…

Hmm, I thought that the hint was formulated like this:

The RTCP message types listed in the a=portmapping-req attribute are by
the server expected to contain tokens when sent by the client.

But I don't think we have a common understanding of that being the case
from your text above.

Cheers

Magnus Westerlund

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 14 Dec 2010 11:34:58 +0100

..let's wait for Dan/Ali to shed their light..
Tom 

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: dinsdag 14 december 2010 11:32
To: Van Caenegem, Tom (Tom)
Cc: Dan Wing; 'David R Oran'; [email-masked]
Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-08

The RTCP message types listed in the a=portmapping-req attribute are by the server expected to contain tokens when sent by the client.

But I don't think we have a common understanding of that being the case from your text above.

Cheers

Magnus Westerlund

---

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, December 14, 2010 5:32 AM
> Cc: Dave Oran (oran); [email-masked]; Dan Wing (dwing)
> Subject: Re: [AVT] FW: NewVersion Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-08
> 
> > My interpretation of below expressed thoughts is that the "hint" is not an per RTCP message basis. So, the port mapping
> attribute indicates token support at the server side, it does not (necessarily) say that each RTCP message must be
> accompanied with atoken. It would be still up to the server to decide whether it services a RTCP message that is sent by the
> client without a token. This can be a decision on the basis of the kind of RTCP message that was sent (triggering a dedicated
> action at the server side). If the server does need a token, and there was none, there is the additional round trip time penalty
> for the client, as the server will send the token verification reponse message. This can be avoided by the client when it
> always sends a token with every RTCP message, or it can be avoided for the next time as the client learns on the fly which
> messages require tokens.  I am in favour of this.

Yes, this is pretty much it. One small correction. Yes, it is up to the server but it is not like the server can do whatever it wants to do. The individual specifications can define the behavior. For example, in the RAMS draft, we said Token was required. So, a RAMS client would be stupid not to acquire a Token after seeing the 'portmapping-req' line in the SDP and knowing that RAMS requires Tokens. It will incur the RTT delay or will not get the service.

For NACK-based applications, suppose the server has the attribute in the SDP, the client better gets the Token beforehand.

In applications using CCM, it might be up to the application or policy to require the tokens. If the hint is given in the SDP, the client may try getting a token and use them for the CCM messages.
 
> the server expected to contain tokens when sent by the client.

I still think this adds unneeded complexity and complications. The visible profit is negligible (just saves some delay in certain - not all - cases).

Our proposal is to replace the "MUST"s in the 1st paragraph of 7.1 (and elsewhere if any) to something softer so that the attribute indicates a "hint" rather a "requirement".

-acbegen

---

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

> I still think this adds unneeded complexity and complications. The visible profit is negligible (just saves some delay in certain - not all - cases).

Ok, I still think one should express this explicitly. But I can live
with not having an explicit list. However, I would like it to be very
clear that a client MUST have the capability to include the token with
any RTCP message type. So that in cases where a you get an error back
you have the capbability to include the token also for these messages.

Secondly, I would like to point out that it is not obvious unless we add
additional information in the error message which RTCP message type(s)
and sub-type(s) that caused an error message. That as there exist no
strong binding between a particular RTCP message and the error message.
So in cases multiple ones where sent in a short time frame the client
may be unable to determine which ones was refused.

> Our proposal is to replace the "MUST"s in the 1st paragraph of 7.1 (and elsewhere if any) to something softer so that the attribute indicates a "hint" rather a "requirement".

Stop, don't run away here. This is two different cases. The current MUST
semantics is to my understanding, if the a=portmapping-req attribute is
present then there are something in this session requiring tokens to
use, i.e., you must have support for tokens to be able to participate. I
am strongly against changing that semantics unless it is to be more
specific on what is being required more than support for for port based
mapping. That is why I think the SDP attribute shall be included in all
media blocks (m=) where one sends RTCP messages requiring tokens.

The second part which I though we where discussing was the explicit
listing of messages that require token to be included. What the
semantics are of such a list is a different question from what the
general presence of the attribute is.

Cheers

Magnus Westerlund

---

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

> Sent: Tuesday, December 14, 2010 8:02 AM
> Cc: Van Caenegem, Tom (Tom); Dave Oran (oran); [email-masked]; Dan Wing (dwing)

A client may or may not have the capability. It is not something SDP describes. If it has implemented Token, it has the capability.

> you have the capbability to include the token also for these messages.

If the client has implemented, it will do so.
 
> strong binding between a particular RTCP message and the error message.

Correct, there is no such binding. The Token Verification Failure message has a field for the nonce. So, if the token was invalid, the client can figure out which token was invalid. If there was no token and the server sends this failure message, the client infers that it was missing the token. For which message? The client would not be able to infer that in case there were multiple outstanding RTCP messages sent to the server.

> may be unable to determine which ones was refused.

Correct, it cannot. If this is important to warrant a field in the failure message, we can add a field to indicate the packet type (8 bits) of the RTCP message that was supposed to have a token (e.g., 205 for NACK or RAMS, 206 for PSFB). If further desired, we can put a 5-bit field following this to indicate FMT values (nack vs rams or pli vs sli). For messages that do not have FMT, the 5 bits will be naturally set to 0.
 
> > Our proposal is to replace the "MUST"s in the 1st paragraph of 7.1 (and elsewhere if any) to something softer so that the
> attribute indicates a "hint" rather a "requirement".
> 

Looks like we are agreeing to use the attribute only at the media-level. The "hint" semantics could be a better fit than "requirement" semantics when the attribute is used at media level, but you are disagreeing with it.

I think when we use the attribute only at the media level with the additional field that we will introduce in the failure message to identify the RTCP message that was supposed to have a token, we have a winner.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 14 Dec 2010 17:22:16 +0100

> A client may or may not have the capability. It is not something SDP describes. If it has implemented Token, it has the capability.

Yes, I mean in the Token draft. If you implement Tokens, then you MUST
be able to send Tokens with any type of RTCP message.

> If the client has implemented, it will do so.

Well, for me that is far from obvious. IF you implemented with a
particular use case in mind, it might not be so that you can actually
include it with another message type and the initial use case.

> Correct, there is no such binding. The Token Verification Failure message has a field for the nonce. So, if the token was invalid, the client can figure out which token was invalid. If there was no…

Exactly, this becomes a potential problem. So from my perspective, you
either have explicit signaling at setup time what is expected of a
client, or you have inband signalling that allows the client to resolve
the situation.

> Correct, it cannot. If this is important to warrant a field in the failure message, we can add a field to indicate the packet type (8 bits) of the RTCP message that was supposed to have a token (e.…

Yes, I tink either that or SDP signalling should be in place.

> Looks like we are agreeing to use the attribute only at the media-level. The "hint" semantics could be a better fit than "requirement" semantics when the attribute is used at media level, but you a…

Yes, as I see it inclusion of the attribute in a media block is at least
as strong as saying. There is some RTCP messages here that will require
Token to be accepted by the server.

> I think when we use the attribute only at the media level with the additional field that we will introduce in the failure message to identify the RTCP message that was supposed to have a token, we…

I think that works. But we are clearly not agreeing on where the
attribute should be in relation to where tokens are being used. I think
it is logical and matching the semantics if one include the attribute in
all media blocks that defines RTCP destinations that needs Tokens.

See also 15B in the 08 review by me.

Cheers

Magnus Westerlund

---

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

> Sent: Tuesday, December 14, 2010 11:22 AM

OK, new text after the 1st paragraph of 3.2.2:

First of all, a client compliant with this specification MUST be able to include a Token with any type of RTCP message (as described below) when it is needed. That is, clients MUST NOT implement this specification with only a specific use case in mind.
 
> > Correct, there is no such binding. The Token Verification Failure message has a field for the nonce. So, if the token was
> invalid, the client can figure out which token was invalid. If there was no token and the server sends this failure message, the
> client infers that it was missing the token. For which message? The client would not be able to infer that in case there were
> multiple outstanding RTCP messages sent to the server.
> 
> > Correct, it cannot. If this is important to warrant a field in the failure message, we can add a field to indicate the packet
> type (8 bits) of the RTCP message that was supposed to have a token (e.g., 205 for NACK or RAMS, 206 for PSFB). If further
> desired, we can put a 5-bit field following this to indicate FMT values (nack vs rams or pli vs sli). For messages that do not
> have FMT, the 5 bits will be naturally set to 0.
> 

I certainly prefer the additional field in the failure message. More robust and cleaner.
 
> > Looks like we are agreeing to use the attribute only at the media-level. The "hint" semantics could be a better fit than
> "requirement" semantics when the attribute is used at media level, but you are disagreeing with it.
> 

Cool.
 
> >
> > I think when we use the attribute only at the media level with the additional field that we will introduce in the failure
> message to identify the RTCP message that was supposed to have a token, we have a winner.
> 

Saw and responded in the same way ;)

I will update the packet format for the failure message.

-acbegen