Ali C. Begen (abegen) skrev 2010-10-04 18:04: > I am glad that we are converging on something. > >>>>>> 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. >>> >>> 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 > > 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. > >> 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 > > 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. 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. > 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. > >>>>> >>>>>> 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? > >>> >>>> 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. >>>>>> 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. >>> >>> 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. > > Token provides RPF check. But, let's work on this Sec. section together. I > could use some help. > Ok -- 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 protected] ---------------------------------------------------------------------- _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
