Dan, >there is high comfort in the working group that proxies and SBCs do not
>go rogue. This is really not surprising given that nobody in the meeting was prepared to report on _measured_ incidents vs. voicing opinions. I share your concern since a stateful SBC, that also handles media is the ideal target for evil doers on the Internet. Where else would someone intercept phone calls and the signaling, all conveniently in one place? Now with peering, a questionable chain of trust develops that is even more likely to break. If there were only a way to collect incident reports... But maybe we are barking up the wrong tree: The purpose here is not security but usage billing and whenever possible, collecting roaming charges. Henry -----Original Message----- From: Dan Wing [mailto:[EMAIL PROTECTED] Sent: Monday, August 13, 2007 6:10 PM To: 'Dean Willis'; 'sip List' Cc: 'Sandy Murphy' Subject: RE: [Sip] Question on SIP Security considerations for futureextensions ... > what do you folks think? > > 1) Could a reasonable "How you could be violated by trusted proxies > that turn rogue" boilerplate be drafted? > 2) Would the practice of repeating this in drafts help or hurt us? > 3) Would it be useful for us to document how each extension could be > used by a rogue proxy? In Chicago when I presented draft-wing-sip-identity-media, Cullen said transitive trust of the entire SIP network for Identity was fine, and RFC4474 was sufficient even with SBCs in the network. At the meeting, only Hadriel Kaplan said transitive trust for identity was not desirable with SBCs in the network. If identity can be spoofed by any trusted proxy in the SIP network you're connected to, you're going to be unable to gain strong identity that's needed for sip-answermode (defense mechanism #1 identified in section 7.3 of draft-ietf-sip-answermode-04) or even the strong identity needed to reliably display Caller-ID. However, based on the tepid response to sip-identity-media in Chicago, my conclusion is there is high comfort in the working group that proxies and SBCs do not go rogue. I found this surprising, and I continue to find this surprising. To your questions, I think such text would be valuable, but to really be useful we'd need an I-D that analyzed RFC3261 itself under the same microsocope. Such a document could start with the examples from your original post. -d _______________________________________________ Sip mailing list https://www1.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://www1.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
