Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Dec 2010 15:46:23 +0100

(As WG chair)

Magnus can you indicate which of these issues you now believe are closed, and which therefore are still open and needing discussion.

Ali: When you see a response from Magnus, can you open separate threads on these and get them closed to the satisfaction of the WG.

Members of the WG, please chime in - we'd like to get these closed and issue a new version of the draft by the 10th.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ali C. Begen (abegen)
> Sent: Monday, November 29, 2010 3:37 PM
> To: Magnus Westerlund;
> [email-masked]; IETF AVT WG
> Subject: Re: [AVT]
> draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments
>
> Hi Magnus,
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf Of
> > Magnus Westerlund
> > Sent: Monday, November 29, 2010 9:38 AM
> > To:
> [email-masked]; IETF AVT
> > WG
> > Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review
> > Comments
> >
> > Hi,
> >
> > I have done a review of the document and have a number of comments.
> > The upper part will contain technical or larger editorial comments,
> > while the lower parts will be minor editorial comments.
> >
> > T1. Section 1. I am missing a discussion of the signalling
> aspects for
> > the applications using these tools. Declarative service signalling
> > seems to be one of the reasons for doing dynamic session creation.
>
> Yes, that is the primary use case. But, I am not sure whether
> I understand what you mean by "discussion of the signaling aspects".
>
> > T2. Section 3. I am missing an explicit list of the assumptions on
> > what is in place around the service when describing the
> port mapping.
>
> I am also not sure what you mean here.
>
> > T3. Section 3.2, page 9, bullet 3:
> > 3.  If the client does not have a valid Token:
>
> Actually, that line should say "if the client does not have a Token".
>
> > How does a client determine if it has a valid token or not. To my
> > understanding the following things needs to be done.
> >
> > First, it needs to check if it has a token for the server + port
> > specified by the session description. May be from a
> previous session.
> > Secondly, it checks if it hasn't expired due to age.
>
> The client can only do one reliable check based on the
> relative exp time. The client's public IP may have changed
> and it cannot necessarily know this.
>
> So, naturally, the client knows from which server/port it
> received the token and should have started a timer upon
> receiving it. Then, it can compare it with the relative exp time.
>
> > T4. Section 4. IP address for token request.
> >
> > It is not clear on how the IP address for the Token Request is
> > determined. Is this the C=? I think there is a good point
> in allowing
> > optional specification of the address information in this SDP
> > attribute, similar to the a=rtcp attribute.
>
> The address is the feedback target address in the primary
> session, which equals to the address given in the C line for
> the unicast session (as you indicated).
>
> Does it make any sense to have the token request message to
> be sent to a different address than the unicast source (which
> also means the token response could be sent by another
> entity)? This may break the Token actually since client's IP
> address might be different for different destinations, right?
>
> > T5. Section 4. Offer/Answer behavior for the "a=portmapping-req"
> > attribute. Having learned my lessong with other attributes. Lets
> > define the SDP offer/answer behavior for this attribute already now.
>
> I understand your concern about somebody else trying to use
> this attribute in an O/A setting in the future. But, if that
> were possible, we would not be needing this Token mechanism
> in the first place.
>
> Instead, I suggest we make it clear in the document saying
> the O/A behavior MUST NOT be defined or used for this attribute.
>
> >
> > T6. Section 4. Where should the signalling aspects of the
> port-mapping
> > be normatively discussed. It might be that Section 4, should be
> > expanded to cover the signalling requirements and their
> implementation
> > using SDP both declarative and offer/answer.
>
> Relating to the previous comment, lets just define the
> declarative requirements and forbid the o/a.
>
> > T7. Section 5.1: Random Nonce. It is not clear when a client should
> > generate a new nonce. My guess would be for each new Token
> request, i.e.
> > every time a new Token needs to be acquired, but that isn't stated.
>
> Yes, correct, we should add this.
>
> > T8. Section 5.2 etc: Fixed length token.
> >
> > I think this solution should abandon a fixed length token,
> and instead
> > use a variable length token. I think there are a number of
> reasons for that:
> >
> > 1. Crypto-agility: If we specify that the crypto hash
> length is to be
> > 128 bits, then that doesn't prevent using another hashing
> mechanism,
> > but it prevents going for a stronger protection by
> increasing the hash
> > output length. As it is likely that a key will be in long
> term usage
> > there is potential for needing quite strong keys. This as this
> > solution is possible to do off-line attacks. Do a token request,
> > capture the material going into the hash, then go find the key.
> >
> > 2. Freedom of implementing the token according to the needs of the
> > implementation. As there only need to be agreement between all the
> > servers using the same token. But an example implementation is good.
> >
> > 3. There is no space for indication of which key has been
> used, which
> > makes key-roll over slightly more difficult. Using only the
> expiration
> > time for which key should be used, is possible but puts
> requirements
> > on implementation to do things in the right order.
> >
> > 4. Possibility to include additional information in the token,
> > including the address for better error detection.
> >
> > Thus I would recommend that we allow for a variable token,
> and with a
> > recommended way of generating the token. We do need to be
> clear on the
> > security requirements on the token.
>
> OK, I am neutral on this and we can certainly allow for
> variable-length Tokens but for that, we will need a length
> field (like a TLV element) to carry the Token back and forth.
>
> Are you suggesting to keep section 6 as an example but not
> mandatory to follow?
>
> > T9. NTP values: I think some mentioning of the epochs for the NTP
> > clock is needed. 2032 isn't that far off, and the roll over
> needs to be handled.
>
> Seriously, you think we will be using tokens at that time :)
> if so, I guess somebody will fix it for NTP and then we can
> rev the token draft at that time.
>
> > T10. Section 5.4:
> > Why no error code in the Token Failure message. To me it seems
> > possible that a server can separate a couple of different
> failures and
> > report back on them:
> >
> > - Expired token
> > - Missmatch of address (Either by keeping state or include
> the address
> > in the token)
> > - Missmatch in Nonce.
> > - Adminstratively expired token.
>
> I don't think the server can determine which component was
> the reason for verification failure. I.e., the server
> generates a new token based on the new input and it can only
> decide whether it is a match or not. If it is not, it cannot
> determine whether the nonce or the IP was to blame.
>
> As for the expiration time, the client should not send such
> tokens anyway. If it does and it receives a failure message,
> the reason would be obvious.
>
> Overall, I don't think we can (or need anyway to) specify the
> reason for failure.
>
> > T11. Section 5.4: Why isn't the "associated Nonce" included in the
> > error response? Either that or the token needs to be
> included so that
> > the client knows which token that didn't work. This as a client may
> > have multiple outstanding requests and not necessarily with
> the same token.
>
> Normally a client would not need to send multiple different
> requests to the same FTAp to get a token. If the client puts
> a different nonce in each request, yes, the tokens will be
> different but what is the point in doing that? One token is
> enough for the client.
>
> So, I don't really see a need for this. Did I miss something
> you had in mind?
>
> Adding the nonce or the token is not a big deal anyway, so
> lets add the Token to the failure message.
>
> > T12. Section 6. More comments on token generation:
> > a. Missing recommended expiration time, or at least what is a
> > reasonable token life time.
>
> Is not this really application specific? If you were asked to
> recommend one, what would you say?
>
> > b. Make it clear that the key do need to be well generated, and not
> > use Null keying of the HMAC.
>
> Ok.
>
> > c. Why not recommend SHA-256? Even if HMAC-SHA1 isn't
> broken yet, it
> > starting to be an aging crypto mechanism.
>
> I don't have much to favor one over another. But, it is not
> like we are protecting your financial data.
>
> I would imagine you could spend less effort to hack into such
> a network to divert the traffic compared to hacking into
> somebody else's token. Remember that just stealing somebody
> else's token does not get you much.
>
> > T13. Section 10.
> > I am lacking a discussion of the security issues around the token
> > itself. As I see it factors as how long the server uses a key,
> > key-roll over requirements, off-line attack possibility and crypto
> > agility all needs discussion.
>
> I will let Dan respond to this.
>
> > Then I am missing the signalling aspect vulnerabilities on this
> > solution and the requirement that puts on the signalling
> infrastructure.
>
> You mean if somebody messes with the portmapping-req
> attribute in the SDP?
>
> > E1: 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
> >    (almost) without the need for retrieving pre-authorization."
> >
> > "I would reformulate the last part of the sentence, i.e. from
> > "(almost)". There is no meaning in differentiating between the
> > solution when this is the one we are doing.
> >
> > In addition maybe try to make the abstract a bit more
> complete in what
> > it the document covers.
> >
> > E2. Section 1, second paragraph: I would include NATs as being
> > actively considered and a reason why dynamic mappings are
> to be preferred.
> >
> > E3. Section 1, fourth paragraph:
> >    An example scenario is where the RTP packets are
> distributed through
> >    source-specific multicast (SSM) and a receiver sends unicast RTCP
> >    feedback to a local repair server (also functioning as a feedback
> >    target) [RFC5760] asking for a retransmission of the
> packets it is
> >    missing, and the local repair server sends the
> retransmission packets
> >    over a unicast RTP session [RFC4588].
> >
> > I would do the following changes to the above:
> >
> >    An example scenario is where the RTP packets are
> distributed through
> >    source-specific multicast (SSM) and a receiver sends unicast RTCP
> >    NACK feedback to a local repair server (also functioning as a
> >    ^^^^
> >
> >    unicast RTCP feedback
> >    ^^^^^^^^^^^^
> >    target) [RFC5760] asking for a retransmission of the
> packets it is
> >    missing, and the local repair server sends the
> retransmission packets
> >    over a unicast RTP session [RFC4588].
> >
> > E4. Section 3.2: Instead of jumping straight into the
> example I would
> > spend at least one paragraph on a high level description of what is
> > assumed to be happening in generic wording. Maybe something like:
> >
> > When an RTP receiver transmits an RTCP feedback message where it
> > expects the server to send unicast RTP traffic to the receiver, it
> > needs to include the acquired token from step one in a RTCP Token
> > verification request message. The server receives the RTCP compound
> > message and verifies the token. The server can then assume that the
> > RTCP message requesting a particular service, such as
> retransmission
> > or Rapid Acquisition of a Multicast session, is legit. An
> existing or
> > new unicast RTP session is used to fulfill the request.
> >
> > E5. Page 8, bullet "1":
> >  If c0=c1, the occasional (periodic) RTCP receiver
> >           reports sent from port c0 (for the multicast session) will
> >           ensure the NAT does not time out the public port
> associated
> >           with the incoming unicast traffic to port c1.
> >
> > I would suggest the following edit:
> >
> > If c0=c1, the occasional (periodic) RTCP receiver
> >           reports sent from port c0 (for the multicast session's
> >           RTCP port P3) will
> >           ^^^^^^^^^^^^
> >           ensure the NAT does not time out the public port
> associated
> >           with the incoming unicast traffic to port c1.
> >
> > E6. Page 9,
> > 2.  The client determines its port numbers (*c0, *c1 and *c2).
> >
> > I would change it to:
> > 2.  The client selects its local port numbers (*c0, *c1 and *c2).
> >
> > E7. section 3.2:
> > 2The server generates an opaque encapsulation (i.e., the
> >            Token) that conveys client's IP address
> information using a
> >            reversible transform only known to the server.
> For details,
> >            see Section 6."
> >
> > There seems to be a mismatch between this text and Section
> 6. Also see
> > tech discussion about the token.
> >
> > E8. Section 3.2, page 10, bullet 5:
> > "Note that in the
> >        unicast session the RTP and RTCP packets MUST be
> multiplexed on
> >        the (same) port c1."
> >
> > I would try to improve the clarify on the directionality in the
> > traffic in this paragraph, especially the above sentence:
> >
> > Note that in the
> >        unicast session traffic from the server to the
> receiver the RTP
> > and RTCP packets MUST be multiplexed, i.e. both RTP and
> RTCP sent from
> > P3 with the destination port c1'.
> >
> > E9. Section 8. I think this section makes sense to include as a
> > sub-section under a signalling discussion section where high level
> > requirements, SDP extensions, SDP usages including O/A and then
> > examples are included.
>
> We will get these fixed in the revision.
>
> Cheers, acbegen.
>
>
> > 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]
> >
> ----------------------------------------------------------------------
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Dec 2010 17:46:57 +0000

> (As WG chair)
...
> Members of the WG, please chime in - we'd like to get these closed and issue a new version of the draft by the 10th.

In general, I support this approach to port mapping, but there are a number of details that I believe need to be resolved in the draft.

- Introduction, 1st paragraph: suggest clarifying that the ports "are a shared resource that is defined declaratively"?

- Section 3.2, 1st paragraph, begins "We illustrate the second step with an example", but it's not clear what is "the second step" being referred to here.

- Section 3.2 is written as an example, but uses RFC 2119 language, and contains many normative requirements. I would suggest that Section 3 be split into two Sections: one giving the motivating example, and another giving normative requirements for use of the port mapping extensions to RTCP.

- Section 3.2, 1st bullet point on page 8 ("Port P3 denotes..."): the draft should clarify that the client may send any type of RTCP packet to the feedback target, any not just RTCP feedback messages, receiver, and extended reports. 

- Section 3.2, 3rd bullet on page 8, sub-point 1: it's not clear what is meant by "When the retransmission server sends unicast packets for a long period of time, this can exceed that timeout". Would it be clearer to say "when the gap between retransmission requests (or other traffic sent from client to server) is long, this can exceed that timeout"?

- Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It may be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for other RTP sessions until the expiration time of the tokens issued?

- Section 3.2, step 4 on page 9: the draft needs to give a normative list of which RTCP packet types require an associated token.

- Section 3.2, step 1-5 on pages 9 and 10: these need to be moved out of the example, into a separate normative section.

- Section 5: The RTCP extensions defined here are exchanged in order to setup a unicast session, rather than to provide feedback on an existing session. Accordingly, it's not clear that they should be sent as RTCP Feedback messages. Would it be appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport layer feedback packets (this would also avoid the problem of how to set the SSRCs)?

- Section 5: Does the nonce have to be 64 bits? If a 56 bit nonce were sufficient, the feedback packets could be packed much more efficiently.

- Section 5.3 should give a normative list of which RTCP packet types require the token verification messages. Does the RTCP BYE packet need this?

- Section 5.4: it would be useful to include the nonce from the token that failed in the verification failure message, so the client can match up the failure to the token used.

- Section 5 should discuss timings and failure modes. RTCP is not a timely or reliable protocol. What is the expected behaviour if these messages are lost and/or delayed? (e.g., that's the retransmission behaviour).

- Section 6: is this section normative, or an example of how the server can generate a token? There seems little requirement for it to be normative.

- Section 6: why base-64 encode the output? RTCP is a binary protocol.

- Section 7: it would seem appropriate to always send the verification failure RTCP message, even if another error response has been delivered. 

Cheers,
Colin

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 1 Dec 2010 17:56:39 -0800

Hi Colin,

> - Introduction, 1st paragraph: suggest clarifying that the ports "are a shared resource that is defined declaratively"?

The first paragraph is concerned about the multicast applications and it does not mention "shared" in the text. Could you clarify your comment?
 
> step" being referred to here.

Reworded.
 
> - Section 3.2 is written as an example, but uses RFC 2119 language, and contains many normative requirements. I would
> suggest that Section 3 be split into two Sections: one giving the motivating example, and another giving normative
> requirements for use of the port mapping extensions to RTCP.

Good idea, done.
 
> - Section 3.2, 1st bullet point on page 8 ("Port P3 denotes..."): the draft should clarify that the client may send any type of
> RTCP packet to the feedback target, any not just RTCP feedback messages, receiver, and extended reports.

Fixed.
 
> - Section 3.2, 3rd bullet on page 8, sub-point 1: it's not clear what is meant by "When the retransmission server sends unicast
> packets for a long period of time, this can exceed that timeout". Would it be clearer to say "when the gap between
> retransmission requests (or other traffic sent from client to server) is long, this can exceed that timeout"?

Good suggestion.
 
> - Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It may
> be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is

Yes, reworded as requested.

> used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for
> other RTP sessions until the expiration time of the tokens issued?

Not sure why we would need this.

> - Section 3.2, step 4 on page 9: the draft needs to give a normative list of which RTCP packet types require an associated

Reworded as: The client needs to provide the Token to the server using a new RTCP message, called Token Verification Request, whenever the client sends an RTCP feedback message for triggering or controlling a unicast session (See Section 5.3).

> - Section 3.2, step 1-5 on pages 9 and 10: these need to be moved out of the example, into a separate normative section.

Done.
 
> - Section 5: The RTCP extensions defined here are exchanged in order to setup a unicast session, rather than to provide
> feedback on an existing session. Accordingly, it's not clear that they should be sent as RTCP Feedback messages. Would it be
> appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport
> layer feedback packets (this would also avoid the problem of how to set the SSRCs)?

We did not do this for RAMS-R, either. I am not very keen on changing this at this stage. Does anybody feel strong about this?
 
> - Section 5: Does the nonce have to be 64 bits? If a 56 bit nonce were sufficient, the feedback packets could be packed much

Nope, it does not. Changed it to 56.
 
> - Section 5.3 should give a normative list of which RTCP packet types require the token verification messages. Does the RTCP

I don’t think BYE messages need a Token. NACKs, RAMS-R and RAMS-T require Tokens.

There could be some future packet formats or message types that might require a Token. How could we word this better? Any ideas?
 
> - Section 5.4: it would be useful to include the nonce from the token that failed in the verification failure message, so the
> client can match up the failure to the token used.

OK.
 
> - Section 5 should discuss timings and failure modes. RTCP is not a timely or reliable protocol. What is the expected
> behaviour if these messages are lost and/or delayed? (e.g., that's the retransmission behaviour).

Just before 5.1, added:

Note that RTCP is not a timely or reliable protocol. The RTCP packets might get lost or re-ordered in the network. 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 when it is eligible to do so based on the timer rules defined in RFC 4585.

> - Section 6: is this section normative, or an example of how the server can generate a token? There seems little requirement

Magnus made a similar comment. We will keep as an example.
 
> - Section 6: why base-64 encode the output? RTCP is a binary protocol.

:) Good point. Fixed. 

> - Section 7: it would seem appropriate to always send the verification failure RTCP message, even if another error response

Done.

Thanks much.
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Dec 2010 14:40:03 +0100

Hi,

I have removed the things where we are in agreement.

Ali C. Begen (abegen) skrev 2010-11-29 16:37:
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
>> To: [email-masked]; IETF AVT WG
>> Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments
>>
>> Hi,
>>
>> I have done a review of the document and have a number of comments. The
>> upper part will contain technical or larger editorial comments, while
>> the lower parts will be minor editorial comments.
>>
>> T1. Section 1. I am missing a discussion of the signalling aspects for
>> the applications using these tools. Declarative service signalling seems
>> to be one of the reasons for doing dynamic session creation.
> 
> Yes, that is the primary use case. But, I am not sure whether I understand what you mean by "discussion of the signaling aspects".

I think the general requirements on what needs to be signalled is not
sufficiently well explained in the draft. Like the need for a unicast
session with the RTP configuration for what will be transmitted. The c=
address, etc.

> 
>> T2. Section 3. I am missing an explicit list of the assumptions on what
>> is in place around the service when describing the port mapping.
> 

To me it appears there is certain assumptions around the service when
using port mapping. That the service are highly dynamic around the the
unicast sessions, and also that it uses a more declarative style of
configuration.

> Actually, that line should say "if the client does not have a Token".

Ok, or possibly your change plus:
"or the token has expired based on the time fields"?

>> specified by the session description. May be from a previous session.
> The client can only do one reliable check based on the relative exp time. The client's public IP may have changed and it cannot necessarily know this.

The first step is about the servers address and port. It is how a
receiver determine if it can reuse a token or needs to get another one.
That is not described so that one can safely implement this. But I
assume you are of interest in reusing the token for example between all
TV channels a particular RS handles.

> 
> So, naturally, the client knows from which server/port it received the token and should have started a timer upon receiving it. Then, it can compare it with the relative exp time.

Or simply save the local clock when the token was received.

>> determined. Is this the C=? I think there is a good point in allowing
>> optional specification of the address information in this SDP attribute,
>> similar to the a=rtcp attribute.
> 
> The address is the feedback target address in the primary session, which equals to the address given in the C line for the unicast session (as you indicated).
> 
> Does it make any sense to have the token request message to be sent to a different address than the unicast source (which also means the token response could be sent by another entity)? This may break the Token actually since client's IP address might be different for different destinations, right?

I think we should enable it as I find it likely that someone will use
such a setup. If the setup is a anything like homes with NATs and no
large scale NAT then I don't think there is likely that you will get
another IP address in the NAT. Even large scale NATs will do their best
to use the same IP address for the same underlying host.

>> attribute. Having learned my lessong with other attributes. Lets define
>> the SDP offer/answer behavior for this attribute already now.
> 
> I understand your concern about somebody else trying to use this attribute in an O/A setting in the future. But, if that were possible, we would not be needing this Token mechanism in the first place.
> 
> Instead, I suggest we make it clear in the document saying the O/A behavior MUST NOT be defined or used for this attribute.

NO! I think it is not that far fetched that you use SIP and O/A to
configure the receiver for a Multicast plus unicast service. For example
using SIP to invite you into a particular IP TV channel. Thus I think
there is a clear need to ensure that this works with O/A.

I tried to say, no you can't use O/A with this attribute, it has failed
miserably. So lets fix that, now rather than later when things don't
interoperate.

> 
>>
>> T6. Section 4. Where should the signalling aspects of the port-mapping
>> be normatively discussed. It might be that Section 4, should be expanded
>> to cover the signalling requirements and their implementation using SDP
>> both declarative and offer/answer.
> 
> Relating to the previous comment, lets just define the declarative requirements and forbid the o/a.

No, I think using SIP to tell a receiver to join a particular service is
very reasonable. In addition the focus of this comment is that the
signalling aspects aren't brought together in a good way discussing what
needs to be signalled.

>> I think this solution should abandon a fixed length token, and instead
>> use a variable length token. I think there are a number of reasons for that:
>>
>> 1. Crypto-agility: If we specify that the crypto hash length is to be
>> 128 bits, then that doesn't prevent using another hashing mechanism, but
>> it prevents going for a stronger protection by increasing the hash
>> output length. As it is likely that a key will be in long term usage
>> there is potential for needing quite strong keys. This as this solution
>> is possible to do off-line attacks. Do a token request, capture the
>> material going into the hash, then go find the key.
>>
>> 3. There is no space for indication of which key has been used, which
>> makes key-roll over slightly more difficult. Using only the expiration
>> time for which key should be used, is possible but puts requirements on
>> implementation to do things in the right order.
>>
>> 4. Possibility to include additional information in the token, including
>> the address for better error detection.
>>
>> Thus I would recommend that we allow for a variable token, and with a
>> recommended way of generating the token. We do need to be clear on the
> OK, I am neutral on this and we can certainly allow for variable-length Tokens but for that, we will need a length field (like a TLV element) to carry the Token back and forth.

More input is desirable on this.

> 
> Are you suggesting to keep section 6 as an example but not mandatory to follow?

I would keep it as it is a reasonable guidance on what the token need to
be for the basic functionality.

> 
>> T9. NTP values: I think some mentioning of the epochs for the NTP clock
>> is needed. 2032 isn't that far off, and the roll over needs to be handled.
> 
> Seriously, you think we will be using tokens at that time :) if so, I guess somebody will fix it for NTP and then we can rev the token draft at that time.
> 

It is not that difficult. And RTP is being used and show no clear
indication of being reduced in importance after 16 years. The NTP roll
over is only 22 years away. Time to at least mention it. The new NTP
spec has discussion of epoch, so a short text saying. Please be aware
that NTP will roll over in 2036 and that you might need to handle this
eventually. RFC 5905, section 6 is the relevant reference.

>> T10. Section 5.4:
>> Why no error code in the Token Failure message. To me it seems possible
>> that a server can separate a couple of different failures and report
>> back on them:
>>
>> - Expired token
>> - Missmatch of address (Either by keeping state or include the address
>> in the token)
>> - Missmatch in Nonce.
> I don't think the server can determine which component was the reason for verification failure. I.e., the server generates a new token based on the new input and it can only decide whether it is a match or not. If it is not, it cannot determine whether the nonce or the IP was to blame.
> 
> As for the expiration time, the client should not send such tokens anyway. If it does and it receives a failure message, the reason would be obvious.
> 
> Overall, I don't think we can (or need anyway to) specify the reason for failure.

So you are basically saying, if you get Token error, simply go request a
new one?

And you don't think there will be any difference in the client behavior
based on the reason.

Ok, I think I can live with that in the token verification step.
However, then I think we need something in the token request response
message that says, sorry, I can't give you a valid token. Otherwise the
server has no way of cleanly say no to a receiver that are not being
serviced. For example due to DoS from that address. Simply ignoring the
RTCP is clearly one possibility, but doesn't seem to be as clean as
saying  no explicitly. At least a few times.

> 
>> T11. Section 5.4: Why isn't the "associated Nonce" included in the error
>> response? Either that or the token needs to be included so that the
>> client knows which token that didn't work. This as a client may have
>> multiple outstanding requests and not necessarily with the same token.
> 
> Normally a client would not need to send multiple different requests to the same FTAp to get a token. If the client puts a different nonce in each request, yes, the tokens will be different but what is the point in doing that? One token is enough for the client.

Please note that this is the verification error message. I agree that a
sanely setup system you shouldn't use the same Feedback target
address+port shouldn't get RTCP messages related to different services
without them explicitly sharing the tokens. But, as currently defined
this is not strictly disallowed I think.

> 
> So, I don't really see a need for this. Did I miss something you had in mind?
> 
> Adding the nonce or the token is not a big deal anyway, so lets add the Token to the failure message.
> 

Ok, thanks for addressing my protocol paranoia.

>> a. Missing recommended expiration time, or at least what is a reasonable
>> token life time.
> 
> Is not this really application specific? If you were asked to recommend one, what would you say?

I agree that part of this is the application. But there are also the
security angle of it. Thus I think some general discussion of this
should be had.

I think more long lived tokens that 24 hours is not needed. Then for
usage with a lot of turn over in the receiver population I would suggest
a much shorter timer, no longer than 1 hour.

And in the extreme case you need one use tokens.

> 
>> c. Why not recommend SHA-256? Even if HMAC-SHA1 isn't broken yet, it
> I don't have much to favor one over another. But, it is not like we are protecting your financial data.
> 
> I would imagine you could spend less effort to hack into such a network to divert the traffic compared to hacking into somebody else's token. Remember that just stealing somebody else's token does not get you much.

Yes, I mostly agree. And SHA-1 is probably a good recommendation
currently. Because this needs to be a easily available algorithm. But if
we are going down the path of variable size tokens, then we can continue
using SHA-1 in the example solution and if it becomes an issue people
can roll new ones independently.

>> itself. As I see it factors as how long the server uses a key, key-roll
>> over requirements, off-line attack possibility and crypto agility all
>> needs discussion.
> 

Ok.

> 
>> Then I am missing the signalling aspect vulnerabilities on this solution
>> and the requirement that puts on the signalling infrastructure.
> 
> You mean if somebody messes with the portmapping-req attribute in the SDP?

Exactly, or c= attribute

cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Dec 2010 14:59:06 +0100

Hi,

My views on some of these comments

> Not sure why we would need this.

I think this is actually an interesting aspect of this. The draft seems
to be missing text on the issues of re-using a unicast session for
another usage. And here I think there are several aspects of this.
- Reusing a unicast session for different type of RTCP requests (which
may work
- Reusing a unicast session for different multimedia session, which I
think implies having them share the FTap.
- Reuse over time of the port for different services. (which is the one
I think Colin was going after).

> We did not do this for RAMS-R, either. I am not very keen on changing this at this stage. Does anybody feel strong about this?

I didn't want to change the messages to much, but I do agree that a new
RTCP message type would likely be cleaner. Especially considering that
none of the SSRC information in the feedback message seems to make sense
in any of the case.

> I don’t think BYE messages need a Token. NACKs, RAMS-R and RAMS-T require Tokens.

Ali, don't BYE also need it at least in the RAMS case? There a BYE
message stops all bursts.

I would say anyone that has any type of control function.

> There could be some future packet formats or message types that might require a Token. How could we word this better? Any ideas?

I would divide them up into 3 categories:

1. The ones that needs a special unicast session to work.
- NACK
- RAMS-R

2. Control messages that could use the verification that they are
comming from whom we previously has communicated with at this IP address.
- CCM messages
- RTCP Bye

3. Reports etc that no direct impact, although secondary impact can be
present.

I do note that stronger source authentication mechanisms should be
considered in all these cases.

-- 

Magnus Westerlund

---

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

Inline.

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, December 02, 2010 8:59 AM
> To: Ali C. Begen (abegen)
> Cc: Colin Perkins; IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]
> 
> Hi,
> 

This is not a problematic case.

> think implies having them share the FTap.

This is not a problematic case, either.
> I think Colin was going after).

OK, this is interesting. Lets discuss it. Remember that the PT port (server side) is advertised in the SDP at media or session level.

If advertised at the media level, PT is the port where the clients (who plan to start that particular unicast session with the server) send their token request message. This is illustrated in the SDP example in the draft.

If advertised at the session level, PT will be the port for obtaining a Token for any unicast session that is run between the server(s) and clients. Recall that existence of the 'portmapping-req' attribute indicates that a Token is required for all unicast sessions. Note that different unicast session may have different server addresses, the attribute above only indicates the common port for them.

Maybe, we should add the following SDP example to the draft. Here there are two SSMs with unicast feedback (4 "m" lines), the 'portmapping-req' is used at the session level. Each SSM has a different feedback target address.

        v=0
        o=ali 1122334455 1122334466 IN IP4 nack.example.com
        s=Local Retransmissions
        t=0 0
        a=group:FID 1 2
        a=group:FID 3 4
        a=rtcp-unicast:rsi
        a=portmapping-req:30000
        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 
        a=rtpmap:98 MP2T/90000
        a=multicast-rtcp:41500
        a=rtcp:42000 IN IP4 192.0.2.1
        a=rtcp-fb:98 nack
        a=mid:1
        m=video 42000 RTP/AVPF 99
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.1
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux                            
        a=rtcp:42500
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:2
        m=video 51000 RTP/AVPF 98
        i=Multicast Stream
        c=IN IP4 233.252.0.3/255
        a=source-filter:incl IN IP4 233.252.0.3 198.51.100.2 
        a=rtpmap:98 MP2T/90000
        a=multicast-rtcp:51500
        a=rtcp:52000 IN IP4 192.0.2.2
        a=rtcp-fb:98 nack
        a=mid:3
        m=video 52000 RTP/AVPF 99
        i=Unicast Retransmission Stream
        c=IN IP4 192.0.2.2
        a=sendonly
        a=rtpmap:99 rtx/90000
        a=rtcp-mux                            
        a=rtcp:52500
        a=fmtp:99 apt=98; rtx-time=5000
        a=mid:4 
 
I also added the following to the SDP section for the 'portmapping-req' attribute:

" If used at a media level, the attribute MUST be used for a unicast media stream."

> >> - Section 5.3 should give a normative list of which RTCP packet types require the token verification messages. Does the
> RTCP
> >> BYE packet need this?
> >

You are right. Somebody else may prematurely end your burst. This is true even in normal retransmission scenarios.
 
> I would say anyone that has any type of control function.

Right.
 
> comming from whom we previously has communicated with at this IP address.

These are the BYEs sent for the unicast sessions not multicast sessions which we do not need to use Token for. Agree?
 
> considered in all these cases.

Thanks, will change the text accordingly.

-acbegen

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Thu, 2 Dec 2010 16:40:44 +0100

Magnus, Colin,

-On using the RTCP FB message format, yes or no: 
We do allow that for higher "security", the tokens may have to be requested/refreshed very often. Ultimately, that may come down to having the client requesting a new token with the portmapping request message prior to sending e.g. a RAMS-R (e.g. with every channel change). In that case, we do want the messages to be sent out as fast as possible, and hence RFC4585 seems appropriate (similar as we did for RAMS).

-On which messages need tokens. 
I have not a strong opinion here. I hinted Ali to use as selection criterium: any RTCP FB message that is issued by a receiver to a server, where the reception of that RTCP message is expected to result in unicast RTP packet(s) transmission from that server to that receiver 

Including the "bye" -for the unicats session- would let it go beyond RTCP FB messages, and would also include messages that stop the ongoing transmission of RTP packets. That is OK for me. But I am not sure on the "report" messages. Does this include RR?
Related to this discussion, I think it would make sense that when the sender receives a RTCP message that requires a token verification company message, but which is missing, the server then responds with a port mapping response message indicating invalid/missing token.

Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: donderdag 2 december 2010 14:59
To: Ali C. Begen (abegen)
Cc: Colin Perkins; IETF AVT WG
Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]

Hi,

Ali C. Begen (abegen) skrev 2010-12-02 02:56:

>> - Section 3.2, 4th bullet on page 8: the discussion of how the token 
>> may remain valid for multiple sessions is unclear. It may be clearer 
>> to say that the token is valid for that port on the server until its 
>> expiration time, irrespective of what that port is
> 
>> used for. Following on from this, would it be appropriate to add a 
>> warning that the server port SHOULD NOT be reused for other RTP sessions until the expiration time of the tokens issued?
> 

I think this is actually an interesting aspect of this. The draft seems to be missing text on the issues of re-using a unicast session for another usage. And here I think there are several aspects of this.
- Reusing a unicast session for different type of RTCP requests (which may work
- Reusing a unicast session for different multimedia session, which I think implies having them share the FTap.
- Reuse over time of the port for different services. (which is the one I think Colin was going after).

>  
>> - Section 5: The RTCP extensions defined here are exchanged in order 
>> to setup a unicast session, rather than to provide feedback on an 
>> existing session. Accordingly, it's not clear that they should be 
>> sent as RTCP Feedback messages. Would it be appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport layer feedback packets (this would also avoid the problem of how to set the SSRCs)?
> 

I didn't want to change the messages to much, but I do agree that a new RTCP message type would likely be cleaner. Especially considering that none of the SSRC information in the feedback message seems to make sense in any of the case.

>> - Section 5: Does the nonce have to be 64 bits? If a 56 bit nonce 
>> were sufficient, the feedback packets could be packed much more efficiently.
> 

>  
>> - Section 5.3 should give a normative list of which RTCP packet types 
>> require the token verification messages. Does the RTCP BYE packet need this?
> 
> I don't think BYE messages need a Token. NACKs, RAMS-R and RAMS-T require Tokens.
> 

Ali, don't BYE also need it at least in the RAMS case? There a BYE message stops all bursts.

2. Control messages that could use the verification that they are comming from whom we previously has communicated with at this IP address.
- CCM messages
- RTCP Bye

3. Reports etc that no direct impact, although secondary impact can be present.

I do note that stronger source authentication mechanisms should be considered in all these cases.

-- 

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Dec 2010 08:38:06 -0800

Hi Magnus,

We are almost there. A few points are left below. I also removed a few issues (such as O/A stuff) and I will discuss them separately.

> session with the RTP configuration for what will be transmitted. The c=

I hope the new version will address this. If not, we will try again.

> unicast sessions, and also that it uses a more declarative style of

Also, I will let you read the revision first.

Right.
 
> > Does it make any sense to have the token request message to be sent to a different address than the unicast source (which
> also means the token response could be sent by another entity)? This may break the Token actually since client's IP address
> might be different for different destinations, right?
> 

True, it really increases the number of failure modes. Do we really need this?

> > I don't think the server can determine which component was the reason for verification failure. I.e., the server generates a
> new token based on the new input and it can only decide whether it is a match or not. If it is not, it cannot determine
> whether the nonce or the IP was to blame.
> >

Right. 
 
> And you don't think there will be any difference in the client behavior

The client always needs to make sure that the token has not expired. Beyond that its behavior does not matter.

> server has no way of cleanly say no to a receiver that are not being

We already have this. The server sends the Port Mapping Response with relative expiration time set to 0. 

> > Normally a client would not need to send multiple different requests to the same FTAp to get a token. If the client puts a
> different nonce in each request, yes, the tokens will be different but what is the point in doing that? One token is enough for
> the client.
> 

We added the nonce to the verification failure message.

> > You mean if somebody messes with the portmapping-req attribute in the SDP?

Ok, added this to the new security section.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Dec 2010 18:20:10 +0100

> This is not a problematic case.

No, I don't expect it to be, unless there is some strange interworking
between the different RTCP messages. But that would be present even
without the dynamically created unicast session.

> This is not a problematic case, either.

I am not agreeing fully. There need to be some consideration here for
it. Because you need to know which session the incomming UDP data
relates to. For example if one has an ongoing RAMS burst for one channel
and then sends a NACK request or another RAMS request and request to use
the same unicast session it is not obvious that the data is
distinguishable from one channel to the other. Thus clearly
consideration should be done here. like alternating between two
different unicast sessions with RAMS requests to avoid overlap.

> If advertised at the session level, PT will be the port for obtaining a Token for any unicast session that is run between the server(s) and clients. Recall that existence of the 'portmapping-req' a…

Yes, I agree that all the tools are available for getting things to
work. However, there needs text to point out when a client should use
new local ports to create new unicast sessions to an server. This
becomes more or less important dependent on how much co-locating is
happening on the server side when it comes to the RTCP feedback port.
Preferably none.

I also feel that you are missing the issue with time. If a service exist
for 2 hours on friday between 18-20. Then another service is started at
21.00 on friday and happens to reuse the port numbers, but is actually
another service instance. Then the token from service one may or may not
still be valid depending if service 1 and 2 share token generator and
key or not.

In this case it would be best if the token generation for service one is
set so that the token will not last beyond the service it intends to
service.

There is also a security perspective, if one expect clients to be of a
non all ways on kind, then a particular IP address may first used by
host A and later by host B. Thus potentially allowing A to DoS host B
unless the token is short lived. But I think I brought this up otherwise.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 2 Dec 2010 18:30:08 +0100

> We are almost there. A few points are left below. I also removed a few issues (such as O/A stuff) and I will discuss them separately.

Ok, see below

> True, it really increases the number of failure modes. Do we really need this?

Yes, it does increase the number of failure modes if wrongly used. Used
in deployment where it makes sense to have the token generator in one
host and then use that for a number of servers it will not. But that
assumes you know have some knowledge about your deployment infrastructure.

As I see the benefit of allowing optionally to specify a token request
address and not only port is to allow re-use of tokens across several
servers. I don't have a strong view on the need for this, however if we
don't add it now, it will be difficult to introduce.

> We already have this. The server sends the Port Mapping Response with relative expiration time set to 0. 

Ok, forgot about that. Then I guess it works.

Cheers

Magnus Westerlund

---

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

> different unicast sessions with RAMS requests to avoid overlap.

Such considerations are discussed in the RAMS draft. If the (feedback) port on the server is shared among multiple RTP sessions, then the client has to know the SSRC of the media stream(s) it wants to acquire. If SSRCs are not available in the SDP, that port cannot be shared.

I don't think that discussion belongs in here.
 
> > If advertised at the media level, PT is the port where the clients (who plan to start that particular unicast session with the
> server) send their token request message. This is illustrated in the SDP example in the draft.
> >
> > If advertised at the session level, PT will be the port for obtaining a Token for any unicast session that is run between the
> server(s) and clients. Recall that existence of the 'portmapping-req' attribute indicates that a Token is required for all unicast
> sessions. Note that different unicast session may have different server addresses, the attribute above only indicates the
> common port for them.
> >
> 

The local port management is a client issue. The client follows the conventional rules of using the same port for different RTP sessions. If there is a risk that the traffic will still leak, it has naturally to use a different local port.

> happening on the server side when it comes to the RTCP feedback port.

Server ports are declarative and it does not matter what the client does on its own side.
 
> still be valid depending if service 1 and 2 share token generator and

It is simple. If it is a new service and the server wants the client to get a new token, it will reject the current one. Or, the server could have issued the token in such a way that it would  expire by 6pm.

> set so that the token will not last beyond the service it intends to

Indeed. Added this.
 
> unless the token is short lived. But I think I brought this up otherwise.

Indeed and I think we covered this sufficiently.

Thanks.
-acbegen

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Dec 2010 21:23:28 +0000

Most of my comments have been covered in the discussion. Just some minor points inline.

Colin

On 2 Dec 2010, at 17:47, Ali C. Begen (abegen) wrote:
>> I am not agreeing fully. There need to be some consideration here for it. Because you need to know which session the incomming UDP data relates to. For example if one has an ongoing RAMS burst for one channel and then sends a NACK request or another RAMS request and request to use the same unicast session it is not obvious that the data is distinguishable from one channel to the other. Thus clearly consideration should be done here. like alternating between two different unicast sessions with RAMS requests to avoid overlap.
> 

I suspect this can happen with services other than RAMS, so the general issue should be highlighted.

>> Yes, I agree that all the tools are available for getting things to work. However, there needs text to point out when a client should use new local ports to create new unicast sessions to a server. This
> 
>> I also feel that you are missing the issue with time. If a service exist for 2 hours on friday between 18-20. Then another service is started at 21.00 on friday and happens to reuse the port numbers, but is actually another service instance. Then the token from service one may or may not still be valid depending if service 1 and 2 share token generator and key or not.
> 

Sure, but the draft needs to say this.

>> In this case it would be best if the token generation for service one is set so that the token will not last beyond the service it intends to service.
> 
> Indeed. Added this.
> 
>> There is also a security perspective, if one expect clients to be of a non all ways on kind, then a particular IP address may first used by host A and later by host B. Thus potentially allowing A to DoS host B unless the token is short lived. But I think I brought this up otherwise.
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 2 Dec 2010 21:25:18 +0000

> We do allow that for higher "security", the tokens may have to be requested/refreshed very often. Ultimately, that may come down to having the client requesting a new token with the portmapping req…

It's fine to use the RTP/AVPF timing rules, but the packet formats don't seem appropriate (similarly, they weren't the right choice for RAMS). We should really consider defining new packet formats here, rather than trying to kludge this into the feedback packet formats.

Colin

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Dec 2010 13:36:20 -0800

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, December 02, 2010 4:23 PM
> Cc: Magnus Westerlund; IETF AVT WG
> >> I am not agreeing fully. There need to be some consideration here for it. Because you need to know which session the
> incomming UDP data relates to. For example if one has an ongoing RAMS burst for one channel and then sends a NACK
> request or another RAMS request and request to use the same unicast session it is not obvious that the data is distinguishable
> from one channel to the other. Thus clearly consideration should be done here. like alternating between two different unicast
> sessions with RAMS requests to avoid overlap.
> >
> > Such considerations are discussed in the RAMS draft. If the (feedback) port on the server is shared among multiple RTP
> sessions, then the client has to know the SSRC of the media stream(s) it wants to acquire. If SSRCs are not available in the
> SDP, that port cannot be shared.
> >

Probably yes. Correct if I am wrong but this does not relate to the Token AFAICT. Here we are discussing the PT port which is used to acquire a Token from, whereas the concern Magnus has raised is related to sharing the feedback target port among multiple RTP sessions (which is the a=rtcp line in the multicast session).

Maybe, this belongs to 5760?
 
> >> Yes, I agree that all the tools are available for getting things to work. However, there needs text to point out when a client
> should use new local ports to create new unicast sessions to a server. This
> >
> > The local port management is a client issue. The client follows the conventional rules of using the same port for different
> RTP sessions. If there is a risk that the traffic will still leak, it has naturally to use a different local port.
> >
> >> I also feel that you are missing the issue with time. If a service exist for 2 hours on friday between 18-20. Then another
> service is started at 21.00 on friday and happens to reuse the port numbers, but is actually another service instance. Then the
> token from service one may or may not still be valid depending if service 1 and 2 share token generator and key or not.
> >
> > It is simple. If it is a new service and the server wants the client to get a new token, it will reject the current one. Or, the
> server could have issued the token in such a way that it would  expire by 6pm.
> 

-05 (not uploaded yet) has this text.

Thanks, acbegen.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Dec 2010 10:12:56 +0100

> Maybe, this belongs to 5760?

I think it belongs in the port mapping draft. Because without it what we
are discussing here is not really possible. The port mapping allows one
to do late binding between a receiver local port and a specific feedback
target address that relates to a specific SSM session. If there is some
overloading ongoing for the FT Adress plus port then re-using the
receivers local port creates an issue of separation. This would not
likely happen if one had to pre-establish the unicast sessions. It
becomes the receivers choice to re-use a specific local port, and that
is really what the discussion here is about.

>From my point of view a receiver really should use different local ports
when submitting RTCP requests related to different SSM sessions. That
way you avoid the whole mess, even if there is some overloading happening.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 3 Dec 2010 05:15:44 -0800

...
> > Probably yes. Correct if I am wrong but this does not relate to the Token AFAICT. Here we are discussing the PT port which
> is used to acquire a Token from, whereas the concern Magnus has raised is related to sharing the feedback target port
> among multiple RTP sessions (which is the a=rtcp line in the multicast session).
> >

OK, not about the server side - which I wanted to convey.
 
> way you avoid the whole mess, even if there is some overloading happening.

Yes, clearly a client cannot keep using the same local (receive) port for different unicast (retransmission, RAMS, etc.) sessions since the unless the source packets are distinct in their media source SSRCs, there could be leakage when switching from one session to another. OTOH, the client does not necessarily need a totally different port for every session, either.

I guess what implementations will do is that they will select N local ports when the system boots up and will rotate the port as they switch from one session to another. N should be chosen such that the probability of still receiving RTP/RTCP packets from an old session is almost zero when the client starts using the same port for a new session. N is application and usage dependent. For typical IPTV applications, a value of 10 or even 5 should be sufficient to satisfy the requirement above.

Is something along the lines above what you were looking for?

Cheers, acbegen.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 3 Dec 2010 16:24:25 +0100

> Is something along the lines above what you were looking for?

Yes, making clear the need to use separate local ports to get different
unicast sessions to avoid reuse to quickly.

Cheers

Magnus Westerlund