Subject: Re: Last Call: <draft-ietf-avt-rapid-acquisition-for-rtp-15.txt> (Unicast-Based Rapid Acquisition of Multicast RTP Sessions) to Proposed Standard

From: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Oct 2010 13:59:33 +0200

Hi,

Responses inline.

Ali C. Begen (abegen) skrev 2010-09-29 17:32:
> Hi Magnus,
> 
> We are all glad to have you back. Comments are inline. We will get these into the revision. See inline.
> 
>> I have the following comments on this document, I think version 7 or 8
>> was the last version I read before my parental leave.
>>
>>
>> 1. Applicability statement: I think this document should have an
>> applicability statement making clear that this is only for engineered
>> environments due to the traffic bursts.
> 
> We already put a lot of effort to explain the precautions for using this in BE networks. I don't think there is a strong argument here that this will only work in engineered networks. So, personally I don't think we should put such a statement.

I can agree that it works in certain type of best-effort networks.
However, I don't think at all it is suitable for any best-effort
network. However, as this is mostly bound by the requirement to also
support SSM in the same network the deployment cases are usually meeting
the assumptions about network capacity. However, if one runs an
multicast overlay and a client starts up with not congestion or network
capacity information and does a RAMS-R it can severely congest a network
for a few seconds.

There are a number of assumptions in where this will work most of the
time and with very few exceptions have any large scale impact on the
network. I think these should be documented in an applicability statement.

>  
>> 2. Section 6.2, bullet 5: I don't think the document is clear on that
>> the BRS is expected to determine if a RAMS-R is a retransmission or an
>> update based on if any content of the message has been changed.
> 
> The statement over there implies this. And naturally it is the server's job to figure that out. Based on this discussion, we even wrote the new CNAME guidelines document so that the server's job would get easier.

Exactly the document implies rather than being explicit. I am not
certain that I have understood all the mechanism you expect me to use to
determine if a RAMS-R is a retransmission or a new request. Based on
that it is uncertain for a client to know what effect an RAMS-R message
will have. I also think it makes sense to mandate that servers do have
retransmission detection, otherwise you end up in a situation where a
client don't dare retransmit a request for the fear of getting two bursts.

>  
>> 3. I worried that what is intended to be an RAMS-R update from the
>> client will be interpreted as new RAMS-R request. The reason is the only
>> that separates these two cases are timing, does it arrive before the
>> burst ends or not. Relying on this heuristics is quite weak and error
>> prone. I still wished that an sequence number had been added to RAMS-R.
> 
> I gave enough arguments why we should not use a seqnum for the RAMS-R messages earlier. It is not justified IMO. Based on the SSRC of the primary and the requesting client's CNAME, things are pretty straightforward.

Yes, I know I am in the rough here. From my perspective, it makes the
use of update RAMS-R uncertain to use. Maybe not a big issue if most
doesn't implement updates. But if one finds need for it then there will
be issues. Consider the AD and IESG notified about the potential issue.

>  
>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally
>>         unique CNAME identifier."
>>
>> I don't think this is a statement that can either be fulfilled nor
>> tested. You can mandate a method for selecting CNAMEs that has low risk
>> of producing CNAME collisions, but nothing can guarantee it unless a
>> entity is coordinating the CNAME space for all clients. Can you mandate
>> the method instead?
> 
> The new CNAME draft has ways to ensure they are unique. If the client uses one of them, we are all set.

Yes, but in that case mandate the implementation and usage of one of
these instead of statement that can't be ensured.

>  
>> If I understand the impact of a CNAME collision is that the collision
>> clients request will be mixed up, for example terminating each others
>> request, or update the values in the RAMS-R.
> 
> When they are unique, this won't happen.

Just checking, but if that is the case then I am missing a discussion of
hijacking attacks in the security consideration section by guessing your
targets CNAME.

>  
>> 5. Section 6.4 and others: The draft has a tendency of formulating
>> itself as everything is guaranteed to work as long as one keep within
>> given limits for bandwidth etc. An example from Section 7.2 Max Receive
>> Bitrate TLV:
> 
> We don't assume things will sure work or guarantee that they will work if everything is satisfied. These are simple rules that both sides must comply with.

No, but a certain view point is clear in the text. Lets call it
optimistic that it will work, while I would write from a more
pessimistic view.

>  
>>       If specified, the total bitrate of the unicast burst(s) plus any
>>       payload-specific information MUST NOT be larger than this value.
>>       Otherwise, congestion and packet loss may occur.
>>
>> The last sentence I would formulate as:
>> "Otherwise, congestion and packet loss are much likelier to occur"
> 
> How about "more likely to occur"?

Sure.

>  
>> Even if one stays within this value congestion and packet loss may
>> occur. This is not the only case, but when I actually decided this seems
>> to be an issue, I hadn't taken note of all examples I seen.
>>
>> 6. Section 7:
>>
>> Each feedback message has a fixed-length field for version, padding,
>>    feedback message type (FMT), payload type (PT), length, SSRC of
>>    packet sender, SSRC of media sender as well as a variable-length
>>    field for feedback control information (FCI).
>>
>>
>> What is called "Payload type" is actually "Packet Type" in RTCP packet
>> headers.
> 
> We followed the definition from 4585 but "packet type" makes more sense to me as well.

Well, section 6.1 of RFC 4585 is wrong.

>  
>> 7. Section 7.3:
>> "The MSN value SHALL
>>       be set to zero only when a new RAMS request is received."
>>
>> How is that actually known? And why reset it at all? Why not increase if
>> for each new RAMS-I message with new content, independently if it is an
>> update or a new request.
> 
> If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same. 

I fully agree with the need for separating retransmissions from updates.
However, I wonder over the reset of the field for each new RAMS-R. It
appears to me to be more robust to simply increment it rather than
reset. Otherwise you can send RAMS-R(1) resulting in RAMS-I MSN = 0.
Then a RAMS-R(2) that is intended to be an update but becomes an new
request results in an RAMS-I with MSN = 0. The client will not know if
this is an retransmission of RAMS-R(1) info. The updated should result
in MSN=1. So without comparing the RAMS-I you can't determine if there
is new information. Going my way (no reset) does not allow a client to
determine if an RAMS-R was treated as update or new request, but it will
correctly know that it is new RAMS-I information.

>  
>> 8. Section 7.3:
>> "When the RTP_Rx receives a RAMS-I message with a response code
>>       that it does not understand, the RTP_Rx MUST send a RAMS-T message
>>       immediately to the BRS."
>>
>> Which media sender SSRC should the client direct this request to if it
>> hasn't been signalled in SDP nor any RTP/RTCP packets received?
> 
> The rules in the RAMS-T section applies. You received a RAMS-I so you know the SSRC.

Yes, you are correct. My mistake.

>  
>> 9. Section 7.3, Media Sender SSRC TLV:
>> " While this
>>       information is already available in the message header, it can be
>>       useful to repeat it in an explicit field."
>>
>> This sentence seems out of place compared to the rest of the text.
> 
> If I recall correctly, this was something you asked for. I am not sure whether there is a better place to put it. Maybe in parentheses? 

I think we can remove that sentence. I think you now have text making
clear when it needs to be included and when it shouldn't.

>  
>> 10. Section 7.3, RTP Seqnum of the First Packet TLV:
>>
>> How is this TLV bound to the SSRC number if is for? This is not
>> explicitly explained.
> 
> What do you mean? The SSRC comes from the RAMS-I's SSRC. There is one (not multiple) stream per RAMS-I.

Yes, something that I apparently have forgotten.
>  
>> 11. Section 7.4:
>>  Each of these RAMS-T messages has
>>    the appropriate media sender SSRC populated in its message header.
>>
>> Instead of writing "appropriate" cant you simply write " Each of these
>> RAMS-T message's media sender SSRC SHALL BE populated with the SSRC of
>> the Media Stream to be terminated."
> 
> Good suggestion.
>  
>> 12. Section 8.3:
>> "This section provides a declarative SDP [RFC4566] example for
>>    enabling rapid acquisition of multicast RTP sessions."
>>
>> Can you make clear that this an example of an SDP to be provided to a
>> client?
> 
> OK.
>  
>> 13. Section 9, bullet b:
>> Be configured to forward certain ports (e.g., using HTML
>>        configuration and UPnP IGD [UPnP-IGD]).
>>
>> Shouldn't the "and" be an "or"?
> 
> Yes, good catch.
>  
>> 14. Section 10:
>>
>> Shouldn't the security consideration make it clear that RAMS-R are
>> especially suspectible to Replay attacks as there is no information in
>> the packet that one can use to detect that it is out of sequence.
> 
> There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-specific replay attack here? 

Yes, I am considering that it is easy to target RAMS-R specifically for
an replay attack. Especially when sent in a reduced size RTCP packet
only containing RAMS-R and SDES CNAME. That has no time specific
information and all replay detection must happen in the security protocol.

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: Magnus Westerlund <[email-masked]>
Date: Mon, 04 Oct 2010 17:38:13 +0200

Ali C. Begen (abegen) skrev 2010-10-04 14:57:
>>> We already put a lot of effort to explain the precautions for using this in BE networks. I don't think there is a strong
>> argument here that this will only work in engineered networks. So, personally I don't think we should put such a statement.
>>
> That is a bit stretch :)
> Well we have rules how the server is supposed to send the burst (rate, timing, etc.) documented in the text. It explains what the server does.
>  
> At the end of intro, I think we can put a few sentences about this.

Ok, I guess I have to live with that.

>>> The statement over there implies this. And naturally it is the server's job to figure that out. Based on this discussion, we
>> even wrote the new CNAME guidelines document so that the server's job would get easier.
>>
> Actually, I re-read it and it is pretty explicit. The text says it checks client's CNAME (which must be unique). If the server is already processing a request from the same client for the same SSRC, then it is a update. Ow, it is a new request.
> 
> I can repeat the above in the text if you think it is necessary.
> 
> OK what if the text said:
>  
>         Updated Request:  The RTP_Rx MAY send an updated RAMS-R message
>         (as unicast feedback in the primary multicast RTP session) with
>         a different value for one or more fields of an earlier RAMS-R
>         message. The RS MUST be able to detect whether a burst is already planned for or being transmitted to this particular RTP_Rx for this particular media source SSRC. If there is an existing burst planned for or being transmitted, the newly arriving RAMS-R is an updated request; otherwise it is a new request...
>      

Better.

>>> I gave enough arguments why we should not use a seqnum for the RAMS-R messages earlier. It is not justified IMO. Based
>> on the SSRC of the primary and the requesting client's CNAME, things are pretty straightforward.
>>
> Is the updated text above good for you?

Not, really, because it has only clarified the issue. The issue is
really the uncertainty for the client how its request will be
interpreted, either as updated request or a new request, all depending
on timing. The biggest issue is the updated request which might be
interpreted as new request, when the client is likely satisfied and
might even have gone one to join the multicast group when the
RAMS-R(update) is processed as a new RAMS-R. Then causing congestion and
unwanted traffic. The client that detects this can surely terminate the
burst, but that will be after some delay, and traffic has arrived.

> Personally, this is one what I did initially but then we agreed that one could come up with an alternative method that would produce unique CNAMEs. In other words, methods for producing unique CNAMEs are not unique. So, we rather put the "MUST" in the sentence above not for the specific implementation.

Okay, I might be nit picking then to request that the text is changed to
"Thus, the RTP_Rx MUST use a method that ensure it uses an unique CNAME
identifier." I don't think globally is the correct scope, it is
unnecessary big, when only needs to be unique within this particular
instance of a system.

> We should probably mention this but I am not sure how the server can deal with this. Hijacking is not easy since the attack must take place at the same instant (more or less) with the request from the authentic client. One of your family members can probably do this :)

The real solution is where you have an more permanent id system in place
that you can connect through source authentication of the requests.

In an SSM session that uses simple feedback model the RTP_Rx cname may
leak as they are redistributed.

Based on that you could bombard a BRS with RAMS-T for example for all
known CNAMES and do that in a round-robin fashion across channels and
time. Depending on source address spoofing you will more or less easy to
find. But I do agree that it becomes a little bit more a brute force
attack, but an attacker could gain knowledge about an important piece of
information to mount the attack at all.

> Things may go wrong anytime, and we do ack that in the paper and have solutions. But if one does not comply with the rules, more things will likely go wrong.
>  

It is a writing style thing and I think we can stop the discussion.

> OK, "packet type" it is then.
>  

Great.

>>> If this is relating to a new burst request, then it is reset. Ow, what is the point of having a seqnum? If something has
>> changed compared to the previous RAMS-I, then MSN is incremented. If it is just a re-xmit, MSN stays the same.
>>
> I think we discussed this before. The RAMS-R numbers are no way correlated with the RAMS-I numbers. You are still trying to correlate them.

Nope, the number here are still only to indicate that they are different
to get the sequence right. My point is that the client can determine
based on MSN if it is an repeat or a new RAMS-I based on a new request.

> The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from the server until an updated RAMS-I is received. This is how the protocol works.

As I try to explain there is a case where you can get two RAMS-I with
MSN=0 in a row with different information. Thus not providing any
relieve for the client in the need to compare the whole request with the
previous one.

> The server cannot keep state information (i.e. tracking RAMS-R numbers) across different sessions. Furthermore, requests for different streams can go to different servers.
>  

No, I am not talking about RAMS-R number here. I am talking about RAMS-I
MSN numbers, that they shouldn't be kept. But I see your point in that
you don't want to keep CNAME,SSRC => MSN counter mappings.

But in that case, I think we should make it clear that a client that has
sent a RAMS-R (update) must check if the RAMS-I information is same or
different to determine if the server interpreted the update as a new
request.

> The Token stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path check). Beyond that is not SRTCP a good solution to avoid this?

SRTCP is if keyed correctly a good solution yes.

 My point is that one normally document the vulnerability and then
ensure that one has a remedy for it. When it comes to the token stuff I
am not certain that it helps against a replay attack. Unless the token
has expired on the server you still will get traffic to the target. That
is why I think a reverse path check when you start delivering should
happen. Because first in that case if there is no listener at the
indicated address and port will you find out that you are attempting a
delivery not intended.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 4 Oct 2010 05:57:58 -0700

Hi Magnus,

That is a bit stretch :)

 

 

 

 

 

 
> clear when it needs to be included and when it shouldn't.

Ok.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 4 Oct 2010 09:04:52 -0700

I am glad that we are converging on something.

> interpreted as new request, when the client is likely satisfied and

Why is this a problem? For this to happen, the initial request must have been lost. And if it is lost and the second makes it, the client still gets what it wants. I don't see a problem here.

> RAMS-R(update) is processed as a new RAMS-R. Then causing congestion and

Are you saying this:
1- The client makes a request but it gets lost. In the mean time, the client sends an update and the server thinks it is a new request and starts sending the burst
2- In the mean time, client gives up and joins the multicast anyway.
3- Burst + mcast creates a congestion.

> burst, but that will be after some delay, and traffic has arrived.

OK, so you are saying what I wrote above. Well, the client has to send a RAMS-T and upon receiving it, the server stops the burst. So that is not a big deal. If you are concerned about RAMS-T being lost (which is repeated if the bust is not stopped), then I will just remind you that this is a protocol where control messages are not fully reliable (they are just repeated for redundancy as frequently as 4585 allows). If you are really this unlucky, you will have a problem but it will be only temporary. 

I don't think there is anything here that requires for us to burn our energy. FWIW, your proposal would not solve this problem entirely, either.
 
> > Personally, this is one what I did initially but then we agreed that one could come up with an alternative method that would
> produce unique CNAMEs. In other words, methods for producing unique CNAMEs are not unique. So, we rather put the
> "MUST" in the sentence above not for the specific implementation.
> 

Fine with me.
 
> > We should probably mention this but I am not sure how the server can deal with this. Hijacking is not easy since the attack
> must take place at the same instant (more or less) with the request from the authentic client. One of your family members
> can probably do this :)
> 

SRTCP?
 
> based on MSN if it is an repeat or a new RAMS-I based on a new request.

When the client receives a RAMS-I with MSN=0, it knows that RAMS-I was sent for a RAMS-R message that was received the first time by the server or an identical repeat of the initial RAMS-I message. 

But even if the client sends an updated request, the server may ignore it, may ignore the changes and subsequently repeat the earlier RAMS-I with no changes in it, which will have the previous MSN. The server may not send anything at all or the message may get lost. The client cannot assume the changes it requested were honored by the server UNLESS there was an updated RAMS-I from the server. Even in that case, the RAMS-I changes may be due to other things the server has observed - not the changes the client asked.

So, the client should not really read too much in to the MSN values received. That is what I have been trying to explain in this discussion.
 
> > The client checks the RAMS-I seqnum to see whether it is a repeat or new info. If RAMS-I MSN is zero, that is the first
> RAMS-I anyway so it must be fully parsed. Does not matter which RAMS-R actually generated it since that is the info from the
> server until an updated RAMS-I is received. This is how the protocol works.
> 

So what? If you made a single request and received two RAMS-I messages with MSN=0, that means they are identical. No need to compare them. If you made two requests and received two RAMS-I messages with MSN=0, they are different messages and you need to fully read them anyway.
 
> > The server cannot keep state information (i.e. tracking RAMS-R numbers) across different sessions. Furthermore, requests
> for different streams can go to different servers.
> >
> 
> >>> There is a wording about this in that section (which simply refers the reader to 5760). Are you considering a RAMS-
> specific
> >> replay attack here?
> >>
> >>
> > The Token stuff (or the cookie stuff) will avoid request messages from being sent by others (it will do at least a reverse path
> check). Beyond that is not SRTCP a good solution to avoid this?
> 

Token provides RPF check. But, let's work on this Sec. section together. I could use some help.

Thanks.
-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 05 Oct 2010 10:28:44 +0200

> Why is this a problem? For this to happen, the initial request must have been lost. And if it is lost and the second makes it, the client still gets what it wants. I don't see a problem here.

No, if you intended to send an update and that gets handled as new
request, then you get the unintended consequence of getting a second burst.

> 1- The client makes a request but it gets lost. In the mean time, the client sends an update and the server thinks it is a new request and starts sending the burst

No,
1. the client sends a request intended to update an ongoing burst.

2. The RAMS-R (update) arrive to late. Thus triggering a second burst.

3. In the mean time, client gets an RAMS-I and joins the multicast group

4. Burst + mcast creates a congestion.

> OK, so you are saying what I wrote above. Well, the client has to send a RAMS-T and upon receiving it, the server stops the burst. So that is not a big deal. If you are concerned about RAMS-T being…

I will agree that you can stop the burst, but you have biased your
protocol by design against sending any RAMS-R with the purpose of
updating the parameter because other things happens than what you
intended to. Thus it will in most cases be better to not send an RAMS-R
update message and avoid the risk of tripping a second burst.

> I don't think there is anything here that requires for us to burn our energy. FWIW, your proposal would not solve this problem entirely, either.

I agree that a RAMS-R sequence number would not resolve the issue you
described. However, it resolves the issue I have tried to describe, I
hope the above makes it clear.

>>>>>>         unique CNAME identifier."
[snip]

>> information to mount the attack at all.

SRTCP keyed with unique keys for each client will prevent anyone else to
send RAMS-T to terminate a burst you have initiated.

> So, the client should not really read too much in to the MSN values received. That is what I have been trying to explain in this discussion.

Also in this case I don't think we have been considering the same case.
My case was the following.

1. C->S RAMS-R
2a. S->C RAMS-I (MSN=0)
2b. S->C Burst starts
3. C->S RAMS-R(Intended to update first RAMS-R)
4. S: Burst ends
5. S: RAMS-R from step 3 arrives in server and trigger new burst
6. S->C RAMS-I (MSN=0)
7. S->C Second burst transmitted

When the RAMS-I message from step 6 arrives the client may think this is
the same as the one in 2a.

Are you assuming that there is a 4b RAMS-I message which indicates that
the first burst will be terminated that has MSN=1? What if that is lost
or not sent?

> So what? If you made a single request and received two RAMS-I messages with MSN=0, that means they are identical. No need to compare them. If you made two requests and received two RAMS-I messages…

Okay, so your point is that as soon you have sent more than one RAMS-R
message to a BRS you will need to look at all RAMS-I and the MSN becomes
completely useless. But, then I think the document needs to point out
that MSN is only reliable to detect repeat transmissions as long as you
have sent no additional RAMS-R messages during a minute or so.

> Token provides RPF check. But, let's work on this Sec. section together. I could use some help.

Ok

-- 

Magnus Westerlund