A good analysis. John
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: 15 April 2008 15:26 > To: Cullen Jennings; Dean Willis > Cc: SIP IETF; [EMAIL PROTECTED] > Subject: [Sip] What 4474 signs, part-1 [was: Proposal to > Revise RFC 4474] > > > > -----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 > _______________________________________________ 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
