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: Van Caenegem, Tom (Tom) [mailto:[e-mail]]
> Sent: Thursday, October 07, 2010 6:31 PM
> To: Ali C. Begen (abegen); Magnus Westerlund
> Cc: [e-mail]; [e-mail]
> Subject: RE: [AVT] Last Call:<draft-ietf-avt-rapid-acquisition-for-rtp-15.txt> (Unicast-Based Rapid Acquisition of Multicast RTP
> Sessions) to Proposed Standard
> 
> Hi,
> 
> I have never been in favour of the "UPDATE" usage of RAMS-R, and I guess we did not think sufficiently through the corner
> cases that were created with introducing/allowing it. Possibly a sequence number field for RAMS-R (and proper usage
> definition) could have avoided the corner case Magnus mentions. The least we should do is indeed mention the risks when a
> client uses RAMS-R which could be also covered in the section "failure cases". Maybe it is also worthwhile to restrict the
> usage of sending  RAMS-R update message(s) only after the RTP RX has received a RAMS-I message for the 1st RAMS-R
> message sent.
> 
> I would be also in favour of having the possibility for a BRS to tell a RTP-Rx NOT to make use of RAMS-R update messages
> (where for the same RAMS/burst transaction, at least one TLV field is provided with a different value or at least one TLV field
> is new, compared to the original RAMS-R). Such indication could be by means of defining e.g. a 202 response code (RAMS
> request has been accepted BUT no RAMS-R update messages allowed) in the 1st RAMS-I message.

If the rams-updates is not signaled in SDP, the client is not supposed to send update messages. So, just don't put it in the SDP.

-acbegen
 
> Tom
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ali C. Begen (abegen)
> Sent: woensdag 6 oktober 2010 17:53
> To: Magnus Westerlund
> Cc: [e-mail]; [e-mail]
> Subject: Re: [AVT] Last Call: <draft-ietf-avt-rapid-acquisition-for-rtp-15.txt> (Unicast-Based Rapid Acquisition of Multicast RTP
> Sessions) to Proposed Standard
> 
> 
> 
> > -----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]
> > ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt