Subject: [Sipping] Re: Comment: draft-ietf-sipping-sbc-funcs-03.txt

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Fri, 01 Jun 2007 13:15:10 +0300

Hi Siddhartha,

Siddhartha Bhakta wrote:
> [1] This document mainly talks about the general
> practices of SBC and associated architectural issues.
> Is there any plan to propose solution(in this draft or
> in some other draft) for those architectural issues?

I personally hope that there would be solution drafts, which would be 
based on this draft, in the future.

> [2] Sec 3.1.1
> The Path, P-Asserted-Id, P-Preferred-Id etc. should
> also be specified in this section.

The draft has already gone through the working group last call and its 
current state is "Publication Requested", so we are not adding text to 
the draft anymore.

> [3] Sec 3.1.1
> "However, in deployments which use IP addresses
> instead of domain names in headers that cannot be
> removed (e.g.  From and To headers), the SBC may
> replace these IP addresses with its own IP address or
> domain name."
> 
> The TO and FROM header contains the identity of Callee
> and Calling party. (Ignore anonymous call for a
> moment). Is it justified to manipulate hostport part
> of TO & FROM?
> I think, it is justified with the explanation below. I
> just need others view on it.
> As TO and FROM are containing IP addresses, it can be
> assumed that hostport part of TO and FROM are
> insignificant to identify SIP users. Therefore,
> hostport part of TO and FROM can be modified with
> SBC's IP address or domain.
> 
> [4] This is an issue for any B2BUA
> If SBC needs to terminate any Dialog (due to session
> timer expiry etc.), SBC may generate BYE for that. But
> if that BYE is challenged then how shall SBC generate
> BYE with right credential?

To answer your questions [3] and [4]: The idea of the draft is just to 
describe the commonly provided functions of SBCs and not to specify any 
particular behavior. So, the draft does not specify what SBCs shall do 
in scenarios you described.

-- 
Jani

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Hans Persson <[email-masked]>
Date: Fri, 08 Jun 2007 14:09:29 +0200

> current state is "Publication Requested", so we are not adding text to 

Oops. Oh well, since I have some notes on this draft I may as well post
my comments anyway...

=== Corrections and Clarifications ===

At the end of the second paragraph of section 1:

> Network operators need many of the
>   features current SBCs provide and often there are no standard
>   mechanisms available to provide them.

I would add something like "or the available methods have undesirable
side effects" at the end of this sentence. It is true that STUN et al is
standardized, but it also means that the firewall administrator in
effect hands over the power to allow traffic into the protected network
to everyone on the inside. This is clearly not acceptable to all
administrators.

Figure 4:

> Record-Route: <sip:p3.middle.example.com>

Add ";lr" at the end.

3.1.3, last para:

> For example, if the SBC removes
>   "Via" entries from a request and then restarts, thus losing state,
>   the SBC may not be able to route responses to that request; 
> depending
>   on the information that was lost when the SBC restarted.

This sentence is strange. The first two lines seem to assume that a
restart means a loss of state (which doesn't have to be true), but then
the last two lines seem to contradict this.

3.4.1, second para:

> An SBC performing a NAT (Network Address Translator) traversal
>   function for a user agent behind a NAT sits between the user-agent
>   and the registrar of the domain.  

This is not true. The SBC may well *be* the NAT for the domain and the
registrar be located inside it (like the UA):

    internet --- SBC ---+--- UA
                        |
                        +--- registrar

The SBC will handle all NAT traversal issue needed for the UA to call
someone on the internet (who may or may not belong to the same domain),
but the registrar is not on the other side of the SBC.

3.4.1, second para:

> When the registrar receives a REGISTER request from the user-agent
>   and responds with a 200 (OK) response, the SBC modifies such a
>   response decreasing the validity of the registration (i.e., the
>   registration expires sooner).  This forces the user-agent to send a
>   new REGISTER to refresh the registration sooner that it would have
>   done on receiving the original response from the registrar.  The
>   REGISTER requests sent by the user-agent refresh the binding of the
>   NAT before the binding expires.

This sounds as if this is the only possible way. It is just one example
of how to solve this. 

5, third para:

> The fact
>   that some functions of SBCs require those SBCs to maintain session-
>   specific information makes the situation even worse.  If the SBC
>   crashes (or is brought down by an attacker), ongoing sessions
>   experience undetermined behavior.

This assumes that the SBC loses state when it crashes. As has been noted
elsewhere in the spec, it may well have redundancy.

=== Editorial Nits ===

Top of page 5 (sec 2, para 2):

> described in[2]) performing both Header Privacy and Session Privacy).

Missing space after "in".

Last para of 2.1:

> Figure 2 illustrates the peering arrangement with a SBC where

Should be "an SBC" since the pronunciation is "essbeesee". This goes for
a number of places in the document.

First para of 2.2:

> prevent over subscription of the access links.  Endpoints are

"over-subscription"

3.1.2, second para:

> Topology hiding function does not work well with Authenticated

"The topology-hiding"

3.1.3, first para:

> The current way of implementing topology hiding consists of having an
>   SBC act as a B2BUA (Back-to-Back User Agents)

"Agent"

3.1.3, third para:

> and then inserts a Via and Record-Route header fields with its own

Drop "a".

3.2.1, last para:

> This kind
>   of procedure can take place, for example, in a situation where
>   subscriber runs out of credits.

"the subscriber"

3.2.3, last para:

> with the endpoints.  It is noteworthy that similar problem, but with

"that a similar"

3.4.3, last para:

> preserving the SIP related NAT bindings.

"SIP-related"

3.5.1, last para:

> Otherwise, the link could become over subscribed and all sessions

"over-subscribed"

3.5.3, last para:

> messages in a way that the media is going to flow through SBC itself.

Insert "so" after "way" and "the" after "through".

3.6.2, last para:

> Section 3.3.2, also affects protocol repair function.

Insert "the" after "affects".

3.7.3, last para:

> Then the UAS replies with
>   a 200 OK response, the SBCs inject themselves in the returning media
>   path.  After signaling the media start flowing, and both SBCs are

Insert "and" after "response,".

"start" -> "starts"

4, first para:

> than others.  This list requirements that are derived from the

"This list contains"

5, first para:

> The result is that the user agents may
>   interpreted the actions taken by SBC as a MitM attack.

"interpreted" -> "interpret"

Insert "the" before "SBC".

5, second and third para:

>    distinguish between the actions of an attacker and those of a SBC,
>   users cannot know whether they are being eavesdropped or a SBC on

> A SBC is a single point of failure form the architectural point of

> that some functions of SBCs require those SBCs to maintain session
>    specific information makes the situation even worse.  If the SBC

"a SBC" -> "an SBC"

In #2 above, "form" -> "from".

In #3 above, "session specific" -> "session-specific".

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210857   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/