> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Cullen Jennings > Sent: Monday, April 14, 2008 10:53 AM > > Based on the discussion I've seen so far, the primary use case for > this modification is to allow the SBC to do media steering so it can > steer the RTP through a path that provides better QoS. As you say, > this could be achieved by modifying the SDP and changing RFC 4474 to > allow that, but there are probably some other approaches we should be > considering as well, including ones that may need to be done outside > of SIP. If there's consensus that this is the problem > that needs solving, then I'll get with the SIP, SIPPING, and MMUSIC > chairs and figure out a process for how to evaluate the various > options and get this moving forward. If this isn't > the primary use case, then I think we probably need some more > discussion to get a clearer idea of what the problem is.
I think there are several problems with what 4474 signs, and SDP is only one of them, so I'll break it up into separate emails. As far as I can tell, in this world there are lots of B2BUA's - and no I'm not just talking SBC's. Most of the people on this mailing list work for companies that make some form of B2BUA or other which are not SBC's. Some of those B2BUA's change things which will break 4474. Whether 4474 *should* fail in such cases is a separate but important topic. This is part-1: Signing the Call-ID. Some of those B2BUA's change the Call-ID, even though at a higher layer it's clearly the same "request". I believe RFC 4474 signs the Call-ID to provide cut-paste attack protection such that the Verifier can detect when a SIP request is being replayed. To do that, the Verifier keeps a table of received call-id's and identity header signatures with their date. If a request is received with the same identity header value for the same call-id and date (which are both signed in that identity header value's signature), then it's a replay. Clearly valid in-dialog requests will have the same call-id, but because their date and cseq values will be different, their identity header values will be unique and not detected as a replay. I think there are actually legitimate technical reasons why this wouldn't always work right, even in a fully rfc3261-compliant world. For one, the request could get forked, but end up at the same verifier. The forked requests could have unique request-uri's or Route header lists, identifying unique final targets, but the verifier would consider all but one of them a replay. Similarly, a legitimate spiral through a verifier would be detected as a replay. For another, the request could be responded to by the UAS with a 302, which triggers an upstream proxy to recurse the request again through the same verifier but a new final target, which would be detected as a replay. Lastly, I believe that if UDP transport is used, the verifier can legitimately get retransmissions of requests, using the same cseq, which it would detect as replays but may really need to pass on. (ie, non-Invite requests) Then of course there is also a world with B2BUA's. I think a legitimate argument can be made that a 4474-signed signature *shouldn't* remain valid crossing such Call-ID-changing systems, because otherwise it opens up the door for replay attacks. [note: I am only talking Call-ID's, not other fields] But there are ways of providing such replay protection *without* signing the Call-ID field value. I can suggest two alternatives: 1) Create a new header or parameter to be signed and verified, which is unique per new out-of-dialog request the UAC creates - to be added by the UAC or Authenticator before signing. Ultimately, I believe the Call-ID was signed because it was an already existing header - it was very convenient. However, if 4474 fails to be usable in many cases were we think it should work, then it's very *inconvenient*. 2) Mandate that UAC's _STOP_ using IP Addresses in Call-ID's, with whatever new response code and mechanics we need to make that transition. If we were to re-create SIP today, I would argue for this to the end. If we want middle-boxes like SBC's to stop changing things we don't want them to change, stop putting things in which their owners feel compelled to change. This obviously can't be avoided for some things, but the Call-ID is one of my pet peeves because it didn't have to be one of them. Note that Option 2 would only work for SBC's really, not other B2BUA's who change it because they think they need to or really do need to for other reasons. And it would have a serious problem of needing some installed SBC's to be upgraded, whereas option 1 above would have a greater chance of working today. So my preference is Option 1. But doing Option 2 will also solve a lot of other problems in the future, so my real preference is to do BOTH. (Option 1 for 4474, Option 2 for general practice) -hadriel _______________________________________________ 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
