Subject: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt

From: [email-masked]
Date: Sat, 11 Dec 2010 09:30:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : Port Mapping Between Unicast and Multicast RTP Sessions
	Author(s)       : A. Begen, et al.
	Filename        : draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt
	Pages           : 33
	Date            : 2010-12-11

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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Roni Even <[email-masked]>
Date: Mon, 13 Dec 2010 15:11:08 +0200

Hi,
I read this version of the draft and read all the email exchange from the
last weeks.
I will provide my view and not address a specific issue.
I am doing it as an individual

1. The introduction section just before figure 1 has the following sentence
"This solution allows receivers to choose their desired UDP ports for RTP
and RTCP in every unicast session when they are running RTP applications
using both unicast and multicast services, and offer/answer exchange is not
available.". My view and I agree with Tom on this one is that this is the
only use case. I am not sure why the Magnus added the need for offer answer
since if there is an offer answer exchange the answer can provide the
unicast address and port for receiving the unicast stream. For example if
you take the example in figure 7, the unicast m-line in the answer with
mid=2 will provide the transport address for the unicast retransmission. I
am wondering if the motivation is to have "yet another ICE"

2. A nit in section 3.1 second paragraph second sentence add "token" so it
will say "When a token request" .

3. Section 4 defines Token verification failure message. Maybe it should be
mentioned in section 3 that discuss the new messages.

4. In section 4 third paragraph you use RFC 4585 for discussion the RTCP
message scheduling, why not reference RFC 6051

5. Section 4.3 says " Currently, the following RTCP messages are REQUIRED
to be accompanied by a Token Verification Request message:". I have some
questions here"

   5.1 Is this true all the time or only if a token is used. 
   5.2 I understand that it is always required for RAMS but not always for
NACK, BYE and CCM. Some text is needed to explain when to send it.

6. A nit in section 6 second paragraph "The server first applies the its own
procedure". Delete the "the".

7. In section 6 you do not mention the case when the server expected a token
and did not get one.

8. In section 7.1 the draft suggests that the portmapping-req attribute can
be a media or session level. So if used at the session level does it relate
also to the multicast session when used in a grouping of a unicast and
multicast retransmission definition. That will be inconsistent if the
attribute provides only a port for a multicast session there is a problem
according to next section (see my next comment).  So either it MUST have the
optional address parameter if specified at the session level or only allow
it at the media level. I think that this attribute is relevant only for the
unicast session and the text should say that if used at the session level
MUST have the address parameter.

9. In section 7.1 " In the optional address value, only unicast addresses
are allowed; multicast addresses SHOULD NOT be used ...". I see this as
contradiction between the two parts of the sentence and I am not sure why
not say "multicast address MUST NOT be used".

10. In section 7.2 I have some questions on the following requirements:

   o  The RTP/AVPF profile  [RFC4585] - the current text with offer answer
which in my view is very open can allow it to work with AVT profile.

   o  The RTCP extensions for SSM sessions with unicast feedback  [RFC5760]
- The introduction says that it is relevant also for any source multicast,
so why is this required.

   o  The 'multicast-rtcp'  attribute [I-D.ietf-avt-rtcp-port-for-ssm] - can
you explain why?

11. In section 7.3 maybe rephrase the sentence "Since there is no address
indiciated in this line, the client needs to retrieve  the Token from the
address specified in the "c" line."  to  " Since there is no address
indicated in this line, the client needs to send the token request to the
address specified in the "c" line."

There is also a typo in "indiciated"

Roni Even as individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Saturday, December 11, 2010 7:30 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-
> 08.txt
> 
> receivers to choose their own ports for an auxiliary unicast session in
> RTP applications using both unicast and multicast services.  The

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 13 Dec 2010 06:22:10 -0800

Hi Roni,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Monday, December 13, 2010 8:11 AM
> To: [email-masked]
> Subject: Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt - my review
> 
> Hi,

I will let Magnus answer this, however, I think his main motivation was unless we do it here properly, it could be done improperly in the future somewhere else. 
 
> will say "When a token request" .

OK.
 
> mentioned in section 3 that discuss the new messages.

I will look into it.
 
> message scheduling, why not reference RFC 6051

6051 does not make changes on the receiver behavior that we care about here. Does it?
 
>    5.1 Is this true all the time or only if a token is used.

Of course, the 'portmapping-req' attribute has to exists. Ow, it means the server does not support it anyway.

> NACK, BYE and CCM. Some text is needed to explain when to send it.

Unless it is purely unicast app (which is not something we consider), yes, these messages require Tokens because they need to be authorized.
 
> procedure". Delete the "the".

Ok.
 
> 7. In section 6 you do not mention the case when the server expected a token

If there is no token, there is nothing to validate. 
 
> MUST have the address parameter.

I would be ok to define it at media level only. But, in the last meeting or the one earlier, we kinda agreed to have it at session level, too.

I don't see why not specifying an address at session level would be a problem. If the address does not exist, you get it from the c line (in the respective unicast block.
 
> not say "multicast address MUST NOT be used".

If somebody wants to use it, they can use it if and only if they are aware of the potential problems and solutions for them.
 
> which in my view is very open can allow it to work with AVT profile.

So, should we remove 4585 from requirements?
 
> - The introduction says that it is relevant also for any source multicast,

Right, I guess we can remove this, too.
 
>    o  The 'multicast-rtcp'  attribute [I-D.ietf-avt-rtcp-port-for-ssm] - can

This could be removed, too, although it is much better to be explicit about the RTCP port rather than being implicit.
  
> There is also a typo in "indiciated"

Sure. Thanks.
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 13 Dec 2010 15:47:19 +0100

> I will let Magnus answer this, however, I think his main motivation was unless we do it here properly, it could be done improperly in the future somewhere else. 

Hmmm, people seem to be failing to understand my case. I have a scenario
where A provides a multicast service, with Retransmission. B is watching
content provided by A. B then want to invite C to also look at the
content provided by A. So A does not do offer/answer. But B and C does.
So B use SIP to invite C into content provided by A. Thus, there is no
O/A between C and A, so they need to be use the Token.

Does this make it clear why I wanted O/A behavior specified for the SDP
attribute?

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: Roni Even <[email-masked]>
Date: Mon, 13 Dec 2010 18:01:01 +0200

Hi Magnus,
So this is still for the declarative case yet the last three paragraph of
section 7.1 talk about a general offer answer that may look like another
ICE. The issues are having an offer without port and address and having a
port in the answer fir receiving TCP token requests.

Roni Even

> Sent: Monday, December 13, 2010 4:47 PM
> To: [email-masked]
> > I will let Magnus answer this, however, I think his main motivation
> was unless we do it here properly, it could be done improperly in the
> future somewhere else.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Mon, 13 Dec 2010 18:17:10 +0200

Hi Ali,
Inline
Roni

> Ali C. Begen (abegen)
> Sent: Monday, December 13, 2010 4:22 PM
> To: Roni Even; [email-masked]
> I will let Magnus answer this, however, I think his main motivation was
> unless we do it here properly, it could be done improperly in the
> future somewhere else.

Currently it looks like there is inconsistency between the text in the
introduction and section 7.1 specifying offer answer. Once the offer answer
is resolved, the text in section 1 should follow the decision. 

> 6051 does not make changes on the receiver behavior that we care about

The text is section 4 talk about when to send a new port mapping request, I
think that this is what RFC 6051 talk about, see section 2.1.2

> the server does not support it anyway.

It does not say it currently

> Unless it is purely unicast app (which is not something we consider),
> yes, these messages require Tokens because they need to be authorized.
> 

This is related to offer answer case, where currently I did not see any text
that prevents it from being used in a regular unicast call.

> If there is no token, there is nothing to validate.

So what will the server send as a failure in the case when there was no
token and he expected one?

> I would be ok to define it at media level only. But, in the last
> meeting or the one earlier, we kinda agreed to have it at session
> level, too.
> 
> I don't see why not specifying an address at session level would be a
> problem. If the address does not exist, you get it from the c line (in
> the respective unicast block.

So does it mean that the session level address is applicable only to the
unicast lock, or do we need to say that in this case you take the address
from the unicast block and not the multicast block which will be the typical
behavior for a session level attribute. 
> If somebody wants to use it, they can use it if and only if they are
> aware of the potential problems and solutions for them.
> 
But the first part of the sentence says that only uncast addresses are
allowed.

> So, should we remove 4585 from requirements?

If we support general offer answer than it should work also for AVP.

> This could be removed, too, although it is much better to be explicit
> about the RTCP port rather than being implicit.
> 
> 
> >
> >
> > Roni Even as individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 13 Dec 2010 09:35:57 -0800

...
> is resolved, the text in section 1 should follow the decision.

Fair enough. I suppose Magnus will offer any text replacement for intro or 7.1 as needed.

> think that this is what RFC 6051 talk about, see section 2.1.2

IMO, 6051 is concerned about the synchronization issues, which has a specific requirement from a delay viewpoint. Using its rules in the Token context does not make much sense. 4585 rules seem to be a better fit.
 
> It does not say it currently

It is obvious, no? If the SDP does not have it, you don't need to do the Token stuff. I can add this anyway.
 
> that prevents it from being used in a regular unicast call.

I am fine with making changes as needed for the O/A stuff here and elsewhere. However, I will need the text.
 
> token and he expected one?

Token Verification Failure message. See 4.4.

> behavior for a session level attribute.

We could say that. But, looks like it is getting unnecessarily complicated here.

If nobody objects, I think we can remove the session level from the text. Would you agree?

> But the first part of the sentence says that only uncast addresses are

We can fix that by putting "unless" somewhere in the text.
 
> If we support general offer answer than it should work also for AVP.

I will remove AVPF requirement from that section along with the other two. Only muxing and grouping will stay as a requirement.
 
-acbegen

---

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

On 13 Dec 2010, at 17:35, Ali C. Begen (abegen) wrote:
> ...
>> Currently it looks like there is inconsistency between the text in the introduction and section 7.1 specifying offer answer. Once the offer answer is resolved, the text in section 1 should follow the decision.
> 
>>>> 4. In section 4 third paragraph you use RFC 4585 for discussion the RTCP message scheduling, why not reference RFC 6051
>>> 
>> The text is section 4 talk about when to send a new port mapping request, I think that this is what RFC 6051 talk about, see section 2.1.2
> 

Agreed. 6051 doesn't seem a good fit.

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

---

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

> port in the answer fir receiving TCP token requests.

So the offer/answer text does talk about the slightly more generalized
case. And that is because I don't like to leaves gapping holes in the
specifications when it appears rather straight forward how you would
handle the case, even if the direction is the reverse. Which can occur
in my little scenario if C needs to re-invite (offerer) and B is the one
providing A's declarative information.

So yes it tries to be a complete O/A spec but for something that clearly
has declarative usage of this particular information piece, rather than
being negotiated.

And I don't quite understand where you make the connection towards ICE.
ICE is a methodology for establishing media streams. It requires
signalling between the two media end-points. So, yes port mapping (even
in its basic form without any token) is clearly also a methodology for
establishing a media flow. The token is a security mechanism trying to
prevent a number of off-path attacks in that communication.

Port mapping is clearly a case of NAT traversal method usually called
latching or late binding. Where the destination of the media from a
server is determined based on traffic from the client.

>From the above text I might think you are talking about STUN, in that
the token request could return the seen address and port. But why would
you, when there is STUN. Secondly, the token is doing something else and
are opaque. I don't understand where TCP comes in.

If you think this is trying to squeeze out ICE from the market due to
O/A specification I think you have a bit to wild imagination. Because
port mapping is clearly limited in the topologies where it works. It
happens to work quite fine in the constrained deployment models of IP TV
for example. On a server sitting completely exposed to the whole
Internet you clearly have some security concerns to consider, like that
source address validation is not present. It is also hard to estimate
how difficult it is for someone to be an on-path attacker.

Cheers

Magnus Westerlund

---

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

> Fair enough. I suppose Magnus will offer any text replacement for intro or 7.1 as needed.

I still don't quite get the inconsitency. There is still no O/A
signalling between the multicast service and its repair or RAMS unicast
session, it is only between the inviter and the invitee which are
separate entities.

Maybe one can stress the point that there are no O/A signalling between
the one consuming the SDP and the actuall service providing hosts. That
can be made clear in the offer/answer section I think, possibly in the
introduction also.

Cheers

Magnus Westerlund

---

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

Hi Magnus,

I understand your scenario as written in your previous mail:  entity A provides a multicast service, with Retransmission. B is watching content provided by A. B then want to invite C to also look at the content provided by A. So A does not do offer/answer. But B and C does. So B use SIP to invite C into content provided by A. Thus, there is no O/A between C and A, so they need to be use the Token.

..but in this scenario C will get its content straight from A, right?  In that case, why must the token usage be "negotiated" between B and C ?  C simply needs to know A uses the token mechanism, and this can be declared without offer/answer in the SDP that B sends to C along with the SIP invite?

What even more (still) confuses me is that in your proposed text the tokens are exchanged between offerer and answerer (between B and C).

("An offerer that desires the answerer to use tokens in any RTCP message sent to the offerer, i.e. received by the offerer, the attribute is included." 

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: dinsdag 14 december 2010 10:45
To: Ali C. Begen (abegen)
Cc: [email-masked]; Roni Even
Subject: Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt - my review

Ali C. Begen (abegen) skrev 2010-12-13 18:35:
> ...
>> Currently it looks like there is inconsistency between the text in 
>> the introduction and section 7.1 specifying offer answer. Once the 
>> offer answer is resolved, the text in section 1 should follow the decision.
> 

I still don't quite get the inconsitency. There is still no O/A signalling between the multicast service and its repair or RAMS unicast session, it is only between the inviter and the invitee which are separate entities.

Maybe one can stress the point that there are no O/A signalling between the one consuming the SDP and the actuall service providing hosts. That can be made clear in the offer/answer section I think, possibly in the introduction also.

Cheers

Magnus Westerlund

---

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

> ..but in this scenario C will get its content straight from A, right?  In that case, why must the token usage be "negotiated" between B and C ?  C simply needs to know A uses the token mechanism, a…

It is not negotiated, but if one uses SIP with SDP to do the invite, the
SDP will be interpreted in an Offer/Answer context. Thus we need to have
a definition for how it is interpreted. And as you see it isn't truly
negotiated. The current rules are only specify for a declarative usage.
I might be overly clear on this. If we only say "declarative" in the
offer/answer, then it would likely work. However, the contra include
with empty port would not be present so that the invitee could verify
the understanding of the portmapping attribute from the invitee's side.

> What even more (still) confuses me is that in your proposed text the tokens are exchanged between offerer and answerer (between B and C).

Ok, that can be rewritten. However, it is really with the specified
address and port that the token exchange happens. We can

> ("An offerer that desires the answerer to use tokens in any RTCP message sent to the offerer, i.e. received by the offerer, the attribute is included." 

But, it is the offerer that indicates where the service is, so it is the
offerer by proxy. But lets change that to say "server requiring port
mapping" or something like this to make it clear.

Cheers

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Tue, 14 Dec 2010 12:24:13 +0200

Magnus,
The TCP is  typo, it should have been RTCP
Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 11:40 AM
> To: Roni Even
> Cc: [email-masked]

---

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

The 6th paragraph in section 7.1 now says:

<text>
When using this attribute in SDP offer/answer exchanges [RFC3264] the following needs to be considered. This attribute is used declaratively, and there are no offer/answer exchanges between the client consuming the SDP description and the actual server providing the service. If included at session level, this applies to all media lines that uses RTP. If included at media level, it applies to the RTCP feedback messages declared by this media block.
</text>

Roni, Magnus, please confirm whether this removes the confusion you raised. I did not make changes in the intro since the text over there is rather general.

-acbegen

> Sent: Tuesday, December 14, 2010 4:45 AM
> Cc: Roni Even; [email-masked]

---

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

> Roni, Magnus, please confirm whether this removes the confusion you raised. I did not make changes in the intro since the text over there is rather general.

Yes, that makes it clear. But I would maybe clarify to "port mapping
based service" instead of simply service.

Then I would point at there are more occurrences in the later paragraphs
that are unclear which entity is refereed to as pointed out by Tom.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Tue, 14 Dec 2010 15:31:01 +0200

Hi Ali,
I am OK with the first part I am still not clear about the session level. 

If we take the example in figure 7 and move the a=portmapping-req:30000 to
the session level it now applies for both m-lines carrying RTP. How does the
client decide to which address to send the Token request?  c=IN IP4
233.252.0.2/255 or c=IN IP4 192.0.2.1

Can it send to both or either, will the token be the same and if not how
does it get validated when used.

Roni

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 2:53 PM
> To: Magnus Westerlund
> Subject: RE: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-
> 08.txt - my review
> 
> When using this attribute in SDP offer/answer exchanges [RFC3264] the
> following needs to be considered. This attribute is used declaratively,
> and there are no offer/answer exchanges between the client consuming
> the SDP description and the actual server providing the service. If
> included at session level, this applies to all media lines that uses
> RTP. If included at media level, it applies to the RTCP feedback
> messages declared by this media block.
> </text>
> 
> Roni, Magnus, please confirm whether this removes the confusion you
> raised. I did not make changes in the intro since the text over there
> is rather general.
> 
> -acbegen
> 
> the

---

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

Hi Roni,

The last sentence should be removed if we agree on the attribute being used only at media level. I believe this is also what you want to have, right?

So, it will only say:

"When using this attribute in SDP offer/answer exchanges [RFC3264] the
following needs to be considered. This attribute is used declaratively,
and there are no offer/answer exchanges between the client consuming
the SDP description and the actual server providing the service."

Cheers, acbegen.

> From: Roni Even [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 8:31 AM
> To: Ali C. Begen (abegen); 'Magnus Westerlund'
> Cc: [email-masked]
> Subject: RE: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-08.txt -my review
> 
> Hi Ali,

---

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

> So, should we remove 4585 from requirements?

I think it is needed to get the signaling support required by this
solution to get reasonable response rates and error message. Forcing
RTCP message transmission to be on average around 5 seconds apart is not
making this work well.

> This could be removed, too, although it is much better to be explicit about the RTCP port rather than being implicit.

Well, but this is the in multicast session RTCP port. That is not
necessarily having any impact at all on the estalbishment of unicast
session.

Cheers

Magnus Westerlund