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

["Ali C. Begen (abegen)" <[e-mail]>]

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Wednesday, October 06, 2010 10:21 AM
> To: Ali C. Begen (abegen)
> Cc: [e-mail]; [e-mail]
> Subject: Re: Last Call: <draft-ietf-avt-rapid-acquisition-for-rtp-15.txt> (Unicast-Based Rapid Acquisition of Multicast RTP
> Sessions) to Proposed Standard
> 
> 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

I don't think this is a good design choice. When the updates feature was desired by some folks, we only agreed to have it if it the messages still stayed "self-defining". Now, when a server receives a RAMS-U message but it does not have an ongoing burst since the first message (RAMS-R) was lost, it won't process it based on your definition.

> 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 think we can still keep the current text (about the update process) for those who are still planning to use it by putting a caution against such problems. Would that work for you?

-acbegen
 
> 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]
> ----------------------------------------------------------------------