Draft: draft-ietf-sipping-sbc-funcs-01.txt Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: 3/30/2007 Review Deadline: 3/16/2007 Status: post-WGLC Summary: I'm very happy with almost all of the changes in this version of the document. I have a couple of items that I'm not sure were addressed, and one new typo that I flagged. Comments: Working from my previous review... > Hi, Mary and Gonzalo, > > Please find my review of draft-ietf-sipping-sbc-funcs-00.txt, as follows. > > Summary - this draft is on the right track, but has some issues that > should > be fixed before forwarding to the IESG. > > Thanks, > > Spencer > > Comments: > > 3.1.2. Architectural Issues > > This functionality is based on a hop-by-hop trust model as opposed to > an end-to-end trust model. The messages are modified without > subscriber consent and could potentially modify or remove information > about the user's privacy, security requirements and higher layer > applications which are communicating end-to-end using SIP. Either > user in an end-to-end call may perceive this as a Man In The Middle > (MitM) attack. > > Spencer: this seems understated. the text in Section 3.2.2 seems better: > "user agents do not have any way to distinguish the SBC actions from an > attack by a MitM (Man-in-the-Middle)." There's a change in the text for this comment, but it reads oddly: Neither user agent in an end-to-end call does not have any way to distinguish the SBC actions from a Man-In-The-Middle (MitM) attack. Probably should be s/does not have/has/. But this is now a nit. > Modification of IP addresses in Unifor Resource Indetifiers (URIs) > > Spencer: Nit: s/Unifor Resource Indetifiers/Uniform Resource Identifiers/ > > within SIP headers can lead to application failures if these URIs are > communicated to other SIP servers outside the current dialog. These > URIs could appear in a REFER request or in the body of NOTIFY request > as part of an event package. If these messages traverse the same > SBC, it has the opportunity to restore the original IP address. On > the other hand, if the REFER or NOTIFY message returns to the > original network through a different SBC that does not have access to > the address mapping, the recipient of the message will not see the > original address. This may cause the application function to > fail.[[Comment.1: Do we have a sane example of where this is a real > problem? It sounds somewhat contrived to me, but I agree it is a > theoretical concern - Alan.]][[Comment.2: I personally would like to > include this text, although it might be more of a theoretical > concern. - Jani]] > > Spencer: You guys are the experts, but if the SBC is acting as a B2BUA and > manages to NOT be on the path for responses, something sounds REALLY > broken > to me... especially if the SBC inserts a Record-Route with its own SIP > URI, > as shown in the example. This text changed, but the change did not address the comment. How does an SBC, acting as a B2BUA, manage to NOT receive responses to its own requests? > 3.2. Media Traffic Shaping > > 3.2.1. General Information and Requirements > > Since the media path is independent of the signaling path, the media > may not traverse through the operator's network unless the SBC > modifies the session description. By modifying the session > > Spencer: seems slightly backwards - suggest "Since the media path is > independent of the signaling path, the SBC must modify the session > description to ensure that the media traverses through the operator's > network"? > > description the SBC can force the media to be sent through a media > relay which may be co-located with the SBC. No change here, but the authors don't have to believe everything I say :-) > > 3.2.3. Example > > One problem with media traffic shaping is that the SBC needs to > understand the session description protocol and all extensions used > by the user agents. This means that in order to use a new extension > > Spencer: this "One problem" is applicable to more than just Section 3.2 - > for example, SBCs may need to understand all SIP headers in use in order > to > perform topology hiding. This is one of several broader problems. > > (e.g., an extension to implement a new service) or a new session > description protocol, SBCs in the network may need to be upgraded in > conjunction with the endpoints. Certain extensions that do not > require active manipulation of the session descriptors to facilitate > traffic shaping will be able to be deployed without upgrading > existing SBCs, depending on the degree of transparency the SBC > implementation affords. In cases requiring an SBC modification to > support the new protocol features, the rate of service deployment may > be affected. [[Comment.5: I do not think this will slow down > innovation; innovation is a distinct phase of development and > separable from operational network deployment. -Alan]][[Comment.6: I > don't quite get what you are suggesting. If you want to change the > text, go ahead. - Jani]] The text changed, but has a typo in the new text: s/is noteworthy than/is noteworthy that/ (I think). > 3.3. Fixing Capability Mismatches > > 3.3.2. Architectural Issues > > SBCs fixing capability mismatches insert a media element in the media > path using the procedures described in Section 3.2. Therefore, these > SBCs have the same concerns as SBCs performing traffic shaping: the > SBC modifies SIP messages without explicit consent from any of the > user agents. This may break end-to-end security and application > extensions negotiation. > > Spencer: IP version number splicing (as shown in the example) is one of > the > more benign mismatches; the 3GPP/Packet Cable mismatch (as mentioned in > 3.2.1) is less benign. This section should mention the fragility of fixing > capability mismatches in the long term, if over time an increasing number > of > incompatibilities are built into various network elements that the SBCs > must > then adjust in order to allow interworking. The text changed here, but the new text mentions complexity, and not fragility. I wish both concerns were mentioned explicitly. > 4. Derived Requirements > > Spencer: I wish this list appeared earlier in the document - it's almost > lost at this stage. I like the changes to the text in this section. Upon re-read, it wasn't obvious to me that these are requirements for changes/extensions to SIP, my first time through - could this be more explicit? ("Derived Requirements for SIP Working Group"?) > Spencer: of the three derived requirements, Req-2 gives me the most > heartburn - shouldn't it be "direct media traffic through intermediaries > without user consent"? I'm still wondering why "without user consent" isn't mentioned. If a user consents to media redirection for transcoding, that's different from the media streams being hijacked by a middlebox that's not visible to the end user... > 5. Security Considerations > > Spencer: just looking through the "architectural issues" subsections - > haven't most of the obvious security considerations been called out > previously in the draft? This section needs more content, but I don't > think > a lot of work is required to develop the content. The revised text in this section is a lot better - thanks!