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.
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
2- In the mean time, client gives up and joins the multicast anyway.
3- 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 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.
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.
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.
Fine with me.
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?
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.
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.
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.
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.
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.
Thanks.
-acbegen
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf