[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] What 4474 signs, part-1 [was: Proposal to Revise RFC 4474]
A good analysis.
John
> -----Original Message-----
> From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On
> Behalf Of Hadriel Kaplan
> Sent: 15 April 2008 15:26
> To: Cullen Jennings; Dean Willis
> Cc: SIP IETF; jon.peterson at neustar.biz
> Subject: [Sip] What 4474 signs, part-1 [was: Proposal to
> Revise RFC 4474]
>
>
> > -----Original Message-----
> > From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip