Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments
draft-ietf-sipping-sbc-funcs-09

[Ballot discuss]
I think the draft is not detailed enough of the architectural implications of modifying the media path so that the SBC or a SBC controlled device perform relaying of the media. As evident from the TURN discussion relaying packets are not that simple, and it usually requires specific support at the lower layer to carry IP and transport header information correctly between the incomming and outgoing part in relay. Resulting in that relay functions make commonly break functionality such as ECN, PMTUD (due to DF bit setting errors), QoS (Type of service).

I would like this to be better reflected in the text in the relevant sections. I think 1 or 2 paragraphs on this, not more. The main point is relays easily break IP and transport layer functionalities that rely on the correct handling of their fields: ECN, FlowID, Type of Service are all examples of such fields. More complicated are the Don't Fragment bit and how it interact with path MTU discovery and any sent ICMP packet too big messages. I think those are the main points to mention.

[Ballot comment]
Section 3.2.1:

  Additionally, traffic management can be used to implement intercept
  capabilities where required to support audit or legal obligations.

I am not aware of legal requirements to implement intercept functions
by network operators that are not parties in the communication or
setup of the communication for other reasons already. There are
requirements for intercepting Internet communications by ISPs, but
this interception is to be done at the level of they provide
service. For instance, if they merely act as a DSL provider they would
be able to store/inspect IP traffic. Similarly, an operator that
provides voice service might have a legal requirement to provide
interception capabilities. Traffic management as defined in your
document is one way of doing this. However, in this case the operator
would already have SIP proxies in their network that can act as B2BUAs
and perform traffic management. So the introduction of additional
devices to do this may not be justified.

Some discussion of the above nuances would be useful in the document.

Section 3.3.1:

  For example, user-
  agents on networks which implement SIP differently (for example 3GPP
  or SIP [1] network etc)

Is the issue really that they implement SIP differently, or that they
require differing sets of extensions? Perhaps this needs to be written
in a way similar to the previous sentence which said "SBCs fixing
capability mismatches enable communications between user-agents with
different capabilities or extensions." Or simply say "For example,
connecting to a 3GPP network via a plain SIP phone."

Section 3.4.1:

  SBCs' NAT traversal function is required in scenarios
  where the NAT is outside the SBC

I have a hard time imagining networks where this arrangement
exists. If my Linksys router had an SBC function and it fixed
the lack of NAT traversal support in my SIP client, that would
be one. But somehow I suspect that I would get an upgrade to
my client software sooner than an upgrade to the router.

[Ballot discuss]
This is a very useful document, and after addressing/talking about the
below issues I will move to a Yes position.

Section 3.2.2:

This section should mention the fact that requiring media traffic to
go through a central point in the network is likely to cause a
significant additional burden in the amount of traffic that has
to travel a path to that point, creating possible bottlenecks in
the way. For instance, even if my home SIP proxies are somewhere
in the Internet, a call to someone else in the IETF/hotel/etc network
involves media going directly between the endpoints, not via some
party in the Internet.

[Ballot discuss]
I'd like to see a section added that SBCs have no current tie to routing topology and no requirements to automatically change BW reservations on TE tunnels. In general, a short section clarifying the (lack of) interaction w/ path selections, TE tunnel manipulation or BW capacities of the network.

[Ballot comment]
This is a rather nice document  I very much appreciate the clear and
consistent organization.

A few minor issues:

(1) Section 3.5, Access Control

This section seems to have multiple definitions of "access control".

The opening sentence focuses on controlling "what kind of signaling and
media traffic their network carries" but the closing sentence of the
same paragraph talks about access control based on "link-layer
identifiers, IP addresses or SIP identities".

The implications of these two definitions are very different, imho.
As a result, the requirements and issues presented in 3.5 are somewhat
confusing.  The example only addresses one aspect of the problem, as
well.

I suggest revising 3.5 to more clearly explain why these two
definitions of access control are related, or breaking this into
two sections each devoted to one problem.

(2) Section 3.5 would also benefit from more detail regarding the
range of policies that need to be expressed and enforced by an SBC.
The references to policies and policy servers need detail.

editorial nits:

Section 3.1.3

s/identity of subscribers in beeing hidden/identity of subscribers is hidden/

Section 4

s/exiting/existing/

[Ballot comment]
This is a rather nice document  I very much appreciate the clear and
consistent organization.

A few minor issues:

(1) Section 3.5, Access Control

This section seems to have multiple definitions of "access control".

The opening sentence focuses on controlling "what kind of signaling and
media traffic their network carries" but the closing sentence of the
same paragraph talks about access control based on "link-layer
identifiers, IP addresses or SIP identities".

The implications of these two definitions are very different, imho.
As a result, the requirements and issues presented in 3.5 are somewhat
confusing.  The example only addresses one aspect of the problem, as
well.

I suggest revising 3.5 to more clearly explain why these two
definitions of access control are related, or breaking this into
two sections each devoted to one problem.


editorial nits:

Section 3.1.3

s/identity of subscribers in beeing hidden/identity of subscribers is hidden/

Section 4

s/exiting/existing/

[Ballot comment]
This is a rather nice document  I very much appreciate the clear and
consistent organization.

A few minor issues:

(1) Section 3.5, Access Control

This section seems to have multiple definitions of "access control".

The opening sentence focuses on controlling "what kind of signaling and
media traffic their network carries" but the closing sentence of the
same paragraph talks about access control based on "link-layer
identifiers, IP addresses or SIP identities".

The implications of these two definitions are very different, imho.
As a result, the requirements and issues presented in 3.5 are somewhat
confusing.  The example only addresses one aspect of the problem, as
well.

I suggest revising 3.5 to more clearly explain why these two
definitions of access control are related, or breaking this into
two sections each devoted to one problem.


editorial nits:

Section 3.1.3

s/identity of subscribers in beeing hidden/identity of subscribers is hidden/
Section 4

s/exiting/existing/

[Ballot comment]
This is a rather nice document  I very much appreciate the clear and
consistent organization.

A few minor issues:

(1) Section 3.5, Access Control

This section seems to have multiple definitions of "access control".

The opening sentence focuses on controlling "what kind of signaling and
media traffic their network carries" but the closing sentence of the
same paragraph talks about access control based on "link-layer
identifiers, IP addresses or SIP identities".

The implications of these two definitions are very different, imho.
As a result, the requirements and issues presented in 3.5 are somewhat
confusing.  The example only addresses one aspect of the problem, as
well.

I suggest revising 3.5 to more clearly explain why these two
definitions of access control are related, or breaking this into
two sections each devoted to one problem.

[Ballot discuss]
This is an useful document. I am missing however information related to operational impact of deploying SBCs and I also found some statemenents related t omanagement functions that require clarification.

1. The document is largely based on operators requirements and these are often mentioned in the text. However no mention is made about the operational impact of deploying SBC. Intuitively one can think about 'boxes' at each network edge that needs one or several SBC functions - is this indeed the model? is this a concern? how are these 'boxes' configured and managed? who has the admin authority to perform management operations on them in situations like the Access Scenario w/ SBCs described in figure 3?

2. Section 2 mentions 'c) network management (traffic monitoring, management, and QoS)' as one of the three principal categories of functions performed by SBCs. However the document has little mention of these functions excepting traffic monitoring which makes me believe that this may need to be de-emphasized.

3. Section 3.2.1 - the following statement I believe is not fully correct:

  Some operators do not want to manage the traffic, but only to monitor
  it for collecting statistics and making sure that they are able to
  meet any business service level agreements with their subscribers
  and/or partners.  The protocol techniques needed for monitoring media
  traffic are the same as for managing media traffic.

Monitoring media can be performed through a number of techniques, part of them have little or nothing to do with those used to manage media traffic.

[Ballot discuss]
This is a very useful document, and after addressing/talking about the
below issues I will move to a Yes position.

Section 3.2.1:

  Additionally, traffic management can be used to implement intercept
  capabilities where required to support audit or legal obligations.

I am not aware of legal requirements to implement intercept functions
by network operators that are not parties in the communication or
setup of the communication for other reasons already. There are
requirements for intercepting Internet communications by ISPs, but
this interception is to be done at the level of they provide
service. For instance, if they merely act as a DSL provider they would
be able to store/inspect IP traffic. Similarly, an operator that
provides voice service might have a legal requirement to provide
interception capabilities. Traffic management as defined in your
document is one way of doing this. However, in this case the operator
would already have SIP proxies in their network that can act as B2BUAs
and perform traffic management. So the introduction of additional
devices to do this may not be justified.

Some discussion of the above nuances would be useful in the document.

Section 3.2.2:

This section should mention the fact that requiring media traffic to
go through a central point in the network is likely to cause a
significant additional burden in the amount of traffic that has
to travel a path to that point, creating possible bottlenecks in
the way. For instance, even if my home SIP proxies are somewhere
in the Internet, a call to someone else in the IETF/hotel/etc network
involves media going directly between the endpoints, not via some
party in the Internet.

[Ballot comment]
Section 3.3.1:

  For example, user-
  agents on networks which implement SIP differently (for example 3GPP
  or SIP [1] network etc)

Is the issue really that they implement SIP differently, or that they
require differing sets of extensions? Perhaps this needs to be written
in a way similar to the previous sentence which said "SBCs fixing
capability mismatches enable communications between user-agents with
different capabilities or extensions." Or simply say "For example,
connecting to a 3GPP network via a plain SIP phone."

Section 3.4.1:

  SBCs' NAT traversal function is required in scenarios
  where the NAT is outside the SBC

I have a hard time imagining networks where this arrangement
exists. If my Linksys router had an SBC function and it fixed
the lack of NAT traversal support in my SIP client, that would
be one. But somehow I suspect that I would get an upgrade to
my client software sooner than an upgrade to the router.

[Ballot discuss]
Section 3.2.1:

  Additionally, traffic management can be used to implement intercept
  capabilities where required to support audit or legal obligations.

I am not aware of legal requirements to implement intercept functions
by network operators that are not parties in the communication or
setup of the communication for other reasons already. There are
requirements for intercepting Internet communications by ISPs, but
this interception is to be done at the level of they provide
service. For instance, if they merely act as a DSL provider they would
be able to store/inspect IP traffic. Similarly, an operator that
provides voice service might have a legal requirement to provide
interception capabilities. Traffic management as defined in your
document is one way of doing this. However, in this case the operator
would already have SIP proxies in their network that can act as B2BUAs
and perform traffic management. So the introduction of additional
devices to do this may not be justified.

Some discussion of the above nuances would be useful in the document.

Section 3.2.2:

This section should mention the fact that requiring media traffic to
go through a central point in the network is likely to cause a
significant additional burden in the amount of traffic that has
to travel a path to that point, creating possible bottlenecks in
the way. For instance, even if my home SIP proxies are somewhere
in the Internet, a call to someone else in the IETF/hotel/etc network
involves media going directly between the endpoints, not via some
party in the Internet.

[Ballot discuss]
I think there is one distinction this draft misses and that is there are SBC that are operating with the users permission and ones that are not - the draft hints at this in the use cases and then does not really use it later on when looking at what things break and what things are likely acceptable. For example, if an SBC at the edge of an enterprise does topology hiding, it is in the same administrative domain, can share the users credentials, and the user chooses to route though it. In this way it can be very much authorized by the UA. Similarly, if a service provider has some broken gateways and deploys an SBC in front of them for protocol repair reasons, the SBC can be configured to more or less be the gateways and it is authorized.

Taking this into account, in section 3.1.2 paragraph 2, says topology hiding does not work for Identity. This is not really true for authorized SBCs and a common place to do Identity is in the border elements. I think it would be fairer to say that for unauthorized SBCs, topology hiding done in the ways described in this draft, is indistinguishable from a MITM attack.

Section 3.7.1 - statement about legal intercept. Can someone please point me at the laws that oblige all operators to provide legal intercept? I do not believe this is true. Furthermore, I do not believe that doing the media encryption function is the only way to do legal intercept. I point out some networks to CALEA without B2BUA with media encryption functions. Glad to discuss the details if people want however I'm not sure we need to agreed on that to be able put in what is the key thing for this draft which is  to say that some operators do use SBC to do legal intercept. I would not want to imply something about if laws require this or imply this is the only way to do it.

I think some thought is needed on revisiting these requirements. There should probably be an information reference to draft-ietf-sip-ua-privacy-01 which does talk about all of these.

Req-1: a B2BUA dealing with via or route headers is very acceptable - this would not break Identity or other end to end security. I'm confused on the case where you think topology sensitive information would be included in a To or From which would be more problematic to change for an authorized SBC. I just don't think I am understanding what this requirement is trying to get at.

Req-2: Some people are using TURN to hide topology or related media relays. There is also the session depended policy work that is a WG chartered item that is targeted at exactly this problem.  Agree that middle boxes modifying SBC without consent is a problem.

Req-3: I'm not sure what sort of mismatches we are talking about here. Claiming that modifying any SIP messages violates the end to end principle is not really true. Proxies and other SIP elements are required to modify message - a bit more nuanced view is needed here. Many types of interoperation can be done while still ensuring end to end integrity. For example, an SBC could interoperate a device that used REFER on one side with a device that did not on the other side. Some types of modification would break Identity. However, the SIP headers that are covered by this are far less likely to require to be modified for mismatching reasons by and unauthorized SBC.

I don't think Req 1 and 3 are crisp enough to be able to evaluate if there is no existing solutions today. I'm also not sure if we are only considering things that are RFC or things that are work in progress.

I don't think this draft has show that subset of the functions will remain non standardized (or even are today). A B2BUA is from an interpretability point of view specified by the specification of a UA. The operation protocol repair are things that could (and probably should) be done by authorized, not unauthorized, SBCs. The sip and sipping WG are putting considerable effort into standardizing the ability to enforce a specific codec.

[Ballot discuss]
I think there is one distinction this draft misses and that is there are SBC that are operating with the users permission and ones that are not - the draft hints at this in the use cases and then does not really use it later on when looking at what things break and what things are likely acceptable. For example, if an SBC at the edge of an enterprise does topology hiding, it is in the same administrative domain, can share the users credentials, and the user chooses to route though it. In this way it can be very much authorized by the UA. Similarly, if a service provider has some broken gateways and deploys an SBC in front of them for protocol repair reasons, the SBC can be configured to more or less be the gateways and it is authorized.

Taking this into account, in section 3.1.2 paragraph 2, says topology hiding does not work for Identity. This is not really true for authorized SBCs and a common place to do Identity is in the border elements. I think it would be fairer to say that for unauthorized SBCs, topology hiding done in the ways described in this draft, is indistinguishable from a MITM attack.

Section 3.7.1 - statement about legal intercept. Can someone please point me at the laws that oblige all operators to provide legal intercept? I do not believe this is true. Furthermore, I do not believe that doing the media encryption function is the only way to do legal intercept. I point out some networks to CALEA without B2BUA with media encryption functions. Glad to discuss the details if people want however I'm not sure we need to agreed on that to be able put in what is the key thing for this draft which is  to say that some operators do use SBC to do legal intercept. I would not want to imply something about if laws require this or imply this is the only way to do it.

I think some thought is needed on revisiting these requirements. There should probably be an information reference to draft-ietf-sip-ua-privacy-01 which does talk about all of these.

Req-1: a B2BUA dealing with via or route headers is very acceptable - this would not break Identity or other end to end security. I'm confused on the case where you think topology sensitive information would be included in a To or From which would be more problematic to change for an authorized SBC. I just don't think I am understanding what this requirement is trying to get at.

Req-2: Some people are using TURN to hide topology or related media relays. There is also the session depended policy work that is a WG chartered item that is targeted at exactly this problem.  Agree that middle boxes modifying SBC without consent is a problem.

Req-3: I'm not sure what sort of mismatches we are talking about here. Claiming that modifying any SIP messages violates the end to end principle is not really true. Proxies and other SIP elements are required to modify message - a bit more nuanced view is needed here. Many types of interoperation can be done while still ensuring end to end integrity. For example, an SBC could interoperate a device that used REFER on one side with a device that did not on the other side. Some types of modification would break Identity. However, the SIP headers that are covered by this are far less likely to require to be modified for mismatching reasons by and unauthorized SBC.

I don't think Req 1 and 3 are crisp enough to be able to evaluate if there is no existing solutions today. I'm also not sure if we are only considering things that are RFC or things that are work in progress.

I don't think this draft has show that subset of the functions will remain non standardized (or even are today). A B2BUA is from an interpretability point of view specified by the specification of a UA. The operation protocol repair are things that could (and probably should) be done by authorized, not unauthorized, SBCs. The sip and sipping WG are putting considerable effort into standardizing the ability to enforce a specific codec.

[Ballot comment]
Suggestions for editorial improvements/clarifications:

Section 2.1: I read the first paragraph while looking at Figure 2, and
was very confused. Does this section describe two different cases, one
without SBC and one with SBC? If so, having two figures as well would
help. If not, figure and text should use consistent names for the
network elements (e.g., which of these is the "originating gateway"
etc.).

Section 2.1, Figure 2: explain acronym SSB

Section 4, s/exiting/existing/

[Ballot discuss]
Depending on what kind of inspection or processing they do, inserting
media relays can prevent "non-media" uses of media path (such as media
path key agreement, STUN). Sometimes breaking them is intentional, but
not always (if e.g. media relay is only for SLA monitoring, or hiding
IP addresses, breaking DTLS-SRTP isn't necessarily intentional.).  I'd
suggest adding a couple of sentences to 3.3.2, and describing in
Section 5 (3rd paragraph) that while SBCs always break e2e security
mechanisms for SIP messages, some types of SBCs don't necessarily
break e2e media path security mechanisms.

Section 3.6: should mention that attempting to repair SDP obviously
has architectural issues, and breaks things.

Section 3.6: repairing header fields can have architectural issues,
too, if some current or future SIP mechanism uses those header fields
in some cryptographic computation (e.g., hash or signature), and the
canonicalization method did not anticipate some particular type of
"repair" being made by SBC. I'd suggest adding couple of sentences
about this.

[Ballot discuss]
I think the draft is not detailed enough of the architectural implications of modifying the media path so that the SBC or a SBC controlled device perform relaying of the media. As evident from the TURN discussion relaying packets are not that simple, and it usually requires specific support at the lower layer to carry IP and transport header information correctly between the incomming and outgoing part in relay. Resulting in that relay functions make commonly break functionality such as ECN, PMTUD (due to DF bit setting errors), QoS (Type of service).

I would like this to be better reflected in the text in the relevant sections.

[Ballot discuss]
This is a discussion disuss, although it might result in a document
revision or RFC editor note if the authors and/or IESG agree with my
suggestions.

I'm very supportive of publishing this sort of document and am likely
to vote yes after discussion.  I'd like customers of IETF standards to
have maximal security and privacy and that's only possible if we build
architectures that fit the real-world requirements, so documenting
the requirements as realized in deployed software is a benefit to the
standards community.

However, I think this document falls a bit short on the recommendations
for future work in the IETF.  It basically admits that some uses of
SDPs will never go away.  If that's the case, shouldn't we have a
mechanism to authenticate and secure SBCs as we do for HTTP proxies?
Why shouldn't such a mechanism be standardized (with appropriate
caveats)?  Can we also get trace headers inserted into the SDP so
we know when the SBC has made a modification?  Middleboxes may be a
necessary evil, but they are less evil when their presence is
documented and so it does less harm to problem diagnosis.  Should
we have best practices for SBCs as we now do for NATs?  If the best
we can do for some users is hop-by-hop transport security through a
known and authenticated SBC, that's a lot better than no security.

I also recommend referencing the BEHAVE specifications for NAT
traversal purposes.  Can't the SBC just use the timeout specified
there?  Are smaller timeouts necessary to deal with non-BEHAVE compliant
NATs that shut down sessions too soon?  Is this an interim measure
until NATs are fixed to comply with BEHAVE or are the BEHAVE keepalive
timeouts unrealistic?

[Ballot comment]
Section 3.4.2 says:
  >
  > There is also a problem related to the method how SBCs choose the
  > value for the validity of a registration period.  This value should
  > be as high as possible, but it still needs to be low enough to
  > maintain the NAT binding.  Typically SBCs do not have any
  > deterministic method for choosing a suitable value.  However, SBCs
  > can just use a sub-optimal, relatively small value which usually
  > works.
  >
  This text begs for an additional sentence.  Please provide an example
  of "a sub-optimal, relatively small value which usually works".

  Section 3.1.3: s/beeing/being/

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Mary Barnes is the document shepherd. She has reviewed this version of
the document
and believes it is ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes. Three members (Francois Audet, Spencer Dawkins and Michael
Procter) of the WG
have reviewed this document in detail. There are no concerns over the
depth or
breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no specific concerns or issues. There is no IPR disclosure.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is WG consensus behind this document and no one has
expressed concerns about its progression.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. The draft has been validated for nits using idnits 2.04.07.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Yes, the document references are split. There are no downward
references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes, there is an appropriate IANA section reflecting that this document
has no IANA considerations.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

There are no sections written in a formal language requiring validation.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This documents describes functions implemented in Session
Initiation Protocol (SIP) intermediaries known as Session
Border Controllers (SBCs). The goal of this document is to
describe the commonly provided functions of SBCs. A
special
focus is given to those practices that are viewed to be in
conflict with SIP architectural principles. This document
also explores the underlying requirements of network
operators
that have led to the use of these functions and practices
in
order to identify protocol requirements and determine
whether
those requirements are satisfied by existing specifications
or additional standards work is required.

Working Group Summary
The SIPPING WG supports the development and advancement of
this document.

Document Quality
This document defines no new protocol elements.
The document was thoroughly reviewed within the SIPPING WG.

Francois Audet, Spencer Dawkins and Michael Procter
provided
detailed reviews during and post WGLC.

Personnel
Mary Barnes is the WG chair shepherd. Jon Peterson is the
responsible Area director.