Re: francois' comments and why RFC4474 not used in the field
Dean Willis <[email protected]>
| Newsgroups | gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
On Apr 13, 2009, at 1:38 PM, Dan Wing wrote: > > That is because, ** in conjunction with media-path validation ** > (which is the important point), the attack is prevented. Well, the attack is not so much "prevented" as it is "detected". It is detectable when the media-path validation fails. But though detectable, the attack is not attributable. You may know that an attack has occurred, but you don't know whether it was enabled by modification of the media or by modification of the signaling. If you had the original signed signaling and could see that the signaling had been altered, then you might reasonably suspect that the attacker was on the signaling path. Without this, all you know is that somebody tweened your media somehow. Now, is this really useful if the original signed media description (SDP) has been replaced by new signed SDP? Not really; as we then would not be able to decide whether the attack was a compromised intermediary authentication server or a a direct attack on the media. So a model wherein no intermediary replaces and resigns the SDP is preferred, as it allows the media to always match the signaling, thereby reducing the uncertainty. We don't have such a model yet AFAIK, as outbound, STUN, and relays give us only two steering points, and I've heard it claimed we need more. I might argue that this problem is due to the separation of signaling and media, which I hold to be one of the prime "complicators" in this whole house of cards. But it might well be possible to extend the relay-discovery model of ICE to be able to express an entire graph of candidate sequences, including n-relay paths. On the otehr hand, I find it difficult to propose such a mechanism that would be backward compatible with the SIP devices I currently use, and if we have to breal backward compatibility, I'd just as soon do it cleanly and on a large scale. -- Dean _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip