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

[Magnus Westerlund <[e-mail]>]

Hi,

I would say that it is a failure of the design, to not make RAMS-R
updates work well. I see one fix that would seem easy to avoid these
problems. Create a new message type RAMS-U that is identical to RAMS-R
except the message type and restrict it to work on a ongoing burst. The
other way is to rip out update for now to avoid having this obviously
broken mechanism stay in there. And if someone needs it in the future
then define it properly.

I do want this finished up and published, but not with serious issue
part of the spec.

Magnus




Ali C. Begen (abegen) skrev 2010-10-06 10:09:
> Dropping the ietf list off.
> 
>>> 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
>>
>> 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.
> 
> Oh, Ok. Now I see your scenario (update arriving late and causing a new burst to start). Well, this is an ill scenario with mid-session updates. While the chances are pretty slim for this happen, it can happen. For this to happen, the client must really send an update close to the join time and then the RAMS-R gets delayed for some reason.
> 
> The only solution for this is that the client will send a RAMS-T for the second burst as soon as it detects it. Furthermore, if the primary stream packets have a higher priority than the burst packets (and they should if the network supports this), mcast stream won't be hurt.
> 
> FWIW, mid-sessions updates are not problem-free. So if someone wants to implement it, they will have to live with the complications.
>  
>> 3. In the mean time, client gets an RAMS-I and joins the multicast group
>>
>> 4. Burst + mcast creates a congestion.
>>
>>>
>>>> unwanted traffic. The client that detects this can surely terminate the
>>>> 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 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.
> 
> Personally, I don't see the much benefit in using the RAMS-R updates. That's why they are optional for those who want to implement them.
>  
>>
>>> 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.
>>
>>>
>>>>>
>>>>>>>
>>>>>>>> 4. Section 6.2, bullet 5: " Thus, the RTP_Rx MUST choose a globally
>>>>>>>>         unique CNAME identifier."
>> [snip]
>>
>>>>>
>>>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> SRTCP?
>>
>> SRTCP keyed with unique keys for each client will prevent anyone else to
>> send RAMS-T to terminate a burst you have initiated.
> 
> OK.
>  
>>>
>>>>>>>
>>>>>>>> 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.
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>> 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?
> 
> Well that RAMS-I is not necessarily sent. And if sent, it may get lost. Again, this is an ill scenario with RAMS-R updates. But here the problem is the second burst not failing to identify the second RAMS-I. When the 2nd burst starts, the client will figure out, things were screwed up.
>  
>>>
>>>>>
>>>>>> 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
>>>>>
>>>>> 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.
>>>
>>> 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.
>>
>> 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.
> 
> We should put some text about this. IF the client sent RAMS-R update(s), it should probably check every RAMS-I regardless of MSN values.
> 
> -acbegen
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------