Subject: Re: [Sipping] Draft: Functions of Current SBCs

From: Ben Campbell <[email-masked]>
Date: Tue, 1 Mar 2005 09:20:44 -0600

On Feb 27, 2005, at 9:20 PM, Medhavi Bhatia wrote:

> Radhika,
>
>  
>
> What about entities which are not UAs (or B2BUAs) which modify SDP ? 
> (like ALGs). Guess they fall through the terminology trap door ;) I’d 
> still call them proxies (trusted or malicious) according to Section 
> 26.1.3 in rfc 3261.
>
>

I assume since you refer to the RFC 3261 definition of proxies, you are 
referring to ALGs which otherwise act like SIP proxies, but also modify 
SDP. Regardless of the definition, RFC 3261 says proxies MUST NOT 
modify SDP. I think we have two possible terms for such a beast: B2BUA, 
or "non-compliant proxy". I suspect that most marketing departmets will 
prefer the first :-)

_______________________________________________
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: "Andrew Graydon" <[email-masked]>
Date: Tue, 1 Mar 2005 10:54:38 -0500

This is a point I have made before we need to look at the functionality required for the SIP message across all the variations of network there may be, even a simple peer to peer (UA to UA) transaction will require functionality somewhere in the network topology of the relevant ISPs to provide security and other features, then we work our way up to more complex peering network topologies where there may be multiple devices providing this functionality across the boundaries of the transport layers.

Currently the discussion is all around business functions and current vendor implementations it seems, we need to abstract ourselves from this to discuss the required functionality, why it is required, what standards are needed (or changed) and leave the implementations up to the vendors. We are here to define standards, to ensure that a compliant device will work and be interoperable.

Andrew
________________________________________________________________________
Andrew Graydon                                 Phone: 905-804-1855 x289
V.P. Technology                                Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: March 1, 2005 10:12 AM
To: sipping
Subject: Re: [Sipping] Draft: Functions of Current SBCs

While I normally hesitate to disagree with Henry, I think this taxonomy talks more about business models than anything technical. I have personally built out SIP networks where no "carrier" in the sense of a VoIP (or other media) provider existed at all. (I assume you are not including an IP carrier that is not somehow participating in the VoIP stuff other than moving bits around--if this assumption is incorrect than disregard my comment).

If we do need to distinguish these two SBC roles, I suggest we examine what makes them different, not just what sort of company is deploying them.

On Feb 27, 2005, at 3:00 PM, [email-masked] wrote:

> Two names for two very different devices: In the carrier network or at 
> the perimeter of the customer location.
>  
> The location changes many security aspects (we need to specify which) 
> and also the media performance, as well as bandwidth consumption.
> Multi-homing of customer networks is an issue here as well.
>  
> Henry
>
>
> From: Roy, Radhika [mailto:[email-masked]]
>  Sent: Sunday, February 27, 2005 2:24 PM
> To: Christer Holmberg (JO/LMF); [email-masked]; Medhavi Bhatia; 
> Brian Rosen; Richard Fogel; [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
> Yes, they are all B2BUAs (e.g., Transcoder, 3rd Party Call Controller, 
> etc.). However, all of them have specific names based on the services 
> that are being provided by each one of them among the SIP UAs.
>  
> So, this one (e.g., SBC) should also need to have a name, I believe.
>  
> Best regards,
>  
> Radhika R. Roy
> SAIC
>
>
> From: [email-masked] on behalf of Christer Holmberg (JO/LMF)
> Sent: Sun 2/27/2005 1:35 PM
> To: [email-masked]'; 'Medhavi Bhatia'; 'Brian Rosen'; 'Richard 
> Fogel'; [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
> If we can't call them SBCs, I'll give my hum for calling them B2BUAs...
>  
> Regards,
>  
> Christer Holmberg
> Ericsson Finland
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of [email-masked]
> Sent: 24. helmikuuta 2005 23:23
> To: 'Medhavi Bhatia'; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
> We have now a good agenda item for the SIPPING WG: Humming on various 
> name proposals  :-)
>  
> Henry
>
>
> From: Medhavi Bhatia [mailto:[email-masked]]
>  Sent: Thursday, February 24, 2005 2:39 PM
> To: [email-masked]; 'Brian Rosen'; 'Richard Fogel'; 
> [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
>
> I'd still vote for something like P-SBC and N-SBC. We already know 
> these are kinds of SBCs. The word customer premise needs to be 
> captured, so P-SBC should be "Premises-SBC". I can't get the same 
> understanding just by the word perimeter.
>
>  
>
>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, February 24, 2005 12:14 PM
> To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
>  
>
> >How about client side and network side?
>
>  
>
> 1. The intermediaries used in carrier networks (often referred to as 
> SBC in a confusing manner) could be called "Network based Session 
> Controllers" or NSC.
>
>  
>
> 2. The intermediaries at the perifery of private IP networks, 
> colocated with the NAT/FW could be called "Perimeter Session 
> Controllers" or PSC.
>
>  
>
> Any other, more accurate names?
>
>  
>
> Thanks, Henry
>
>  
>
>
> From: Brian Rosen [mailto:[email-masked]]
>  Sent: Thursday, February 24, 2005 10:43 AM
> To: [email-masked]; 'Medhavi Bhatia'; 'Richard Fogel'; 
> [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
> Henry
>
>  
>
> As always, you wield a sharp sword.  I think you are correct, we need 
> to differentiate a client side SBC from a network side SBC and we need 
> names.
>
> How about client side and network side?
>
>  
>
> Brian
>
>  
>
>  
>
>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, February 24, 2005 10:45 AM
> To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
>
>  
>
> Medhavi,
>
>  
>
> It appears the location of such intermediaries makes the critical
> difference:
>
>  
>
> 1. SBC placed in the network (in the C.O.) of the carrier, or
>
>   
>
> 2. A perimeter device (such as Borderware or SIP media Proxy - these 
> are product names ) that is collocated as CPE with the NAT and 
> Firewall. This co-location changes many security aspects (we need to 
> specify which) and also the media performance, as well as bandwidth 
> consumption. Multi-homing is an issue here, not to forget.
>
>  
>
> I suggest we should always make this distinction. Maybe someone 
> proposes some definitions or names for each.
>
>  
>
> Thanks, Henry
>
>  
> 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

_______________________________________________
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: "Andrew Graydon" <[email-masked]>
Date: Tue, 1 Mar 2005 11:05:53 -0500

I think some of the carrier participants to this list can clarify this
point, but my experience is that the inter-carrier trust model is a very
difficult scenario to classify this simply. If we take SS7 and SMS
transport as an example, while companies such as MCI and SBC may have
QOS/SLA relationships, the same could not be said for their respective
relationships with some of the international carriers, i.e. Mozambique
Mobile for a irreverent example :), which means we should try for a
generic set of standards and then let the vendors comply to those
standards and the different entities, carriers, enterprises,
individuals, implement those standards as they see fit.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Taylor
Sent: March 1, 2005 10:28 AM
To: Ben Campbell
Cc: sipping
Subject: Re: [Sipping] Draft: Functions of Current SBCs

Two possible distinctions that I see, but maybe we could position them
in a spectrum of classifications of borders:
  (1) Trust models are likely to differ for inter-carrier as opposed to
subscriber-carrier handoff.
  (2) QOS model is more likely to be governed by SLA when going
inter-carrier. 
Here, for sure, the enterprise-carrier boundary falls somewhere between.

Ben Campbell wrote:
> While I normally hesitate to disagree with Henry, I think this 
> taxonomy talks more about business models than anything technical. I 
> have personally built out SIP networks where no "carrier" in the sense

> of a VoIP (or other media) provider existed at all. (I assume you are 
> not including an IP carrier that is not somehow participating in the 
> VoIP stuff other than moving bits around--if this assumption is 
> incorrect than disregard my comment).
> 
> If we do need to distinguish these two SBC roles, I suggest we examine

> what makes them different, not just what sort of company is deploying
them.
>> Two names for two very different devices: In the carrier network or 
>> at the perimeter of the customer location.
>>  

>> Multi-homing of customer networks is an issue here as well.
...

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 1 Mar 2005 11:15:25 -0500

Andrew,

Well said.  Protocols tend to be about what information gets sent or received by a particular function that ultimately enables a service to be performed.  Here, we are reverse-engineering the opposite.  We are asking what piece of information enables a dis-service to be performed.  It would be good to have an itemized list of what SIP or SDP headers/parameters enable miscreants to do bad thing, when sending into the wild or received from the wild.

Perhaps once the specific threats are enumerated, we can focus on specific counter-measures, where we have the support of security in the application-layer components and not just the data transport level security mechanisms.  Each layer will likely have a job to do.

Mike

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Andrew Graydon
>Sent: Tuesday, March 01, 2005 10:55 AM
>To: Ben Campbell; sipping
>This is a point I have made before we need to look at the 
>functionality required for the SIP message across all the 
>variations of network there may be, even a simple peer to peer 
>(UA to UA) transaction will require functionality somewhere in 
>the network topology of the relevant ISPs to provide security 
>and other features, then we work our way up to more complex 
>peering network topologies where there may be multiple devices 
>providing this functionality across the boundaries of the 
>transport layers.
>
>Currently the discussion is all around business functions and 
>current vendor implementations it seems, we need to abstract 
>ourselves from this to discuss the required functionality, why 
>it is required, what standards are needed (or changed) and 
>leave the implementations up to the vendors. We are here to 
>define standards, to ensure that a compliant device will work 
>and be interoperable.
>
>Andrew
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Ben Campbell
>taxonomy talks more about business models than anything 
>technical. I have personally built out SIP networks where no 
>"carrier" in the sense of a VoIP (or other media) provider 
>existed at all. (I assume you are not including an IP carrier 
>that is not somehow participating in the VoIP stuff other than 
>moving bits around--if this assumption is incorrect than 
>disregard my comment).
>
>If we do need to distinguish these two SBC roles, I suggest we 
>examine what makes them different, not just what sort of 
>company is deploying them.
>
>[email-masked] for questions on current sip 
>[email-masked] for questions on current sip

---

From: "Parolkar, Satish" <[email-masked]>
Date: Wed, 2 Mar 2005 10:16:02 -0600

The point I was making is that the problem is  of "policy" setting
versus  identifying "lack of function or standardization of protocols".

While reading my e-mail you could substitute "VOIP+IM+FTP" wherever VOIP
is mentioned. 

Satish

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, March 02, 2005 10:11 AM
To: Parolkar, Satish; 'Jonathan Rosenberg'; 'Tom Taylor'
Cc: 'sipping'
Subject: RE: [Sipping] Draft: Functions of Current SBCs

So if I want to make a VoIP + IM + FTP call from Dallas to Tokyo, how
many agreements and policies will come into play?

Henry 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Parolkar, Satish
Sent: Wednesday, March 02, 2005 10:21 AM
To: Jonathan Rosenberg; Tom Taylor
Cc: sipping
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I agree functions at network borders are business relationships. Should
SBC functions be discussed in IETF forum at all?

I don't think the issue is of missing functionality in the protocols or
lack of standardization. I believe the issue may be of policy setting
between two VoIP networks. 

For example, consider the issue of security....There are many ways that
two service provider domains can secure their networks.

(a) Should Security be established using IPSec between the Edge Routers
so that VoIP call transport is secure across the public IP network? 
OR
(b) Should security be established between proxy servers using TLS to
secure SIP signaling? Do networks feel secure if only signaling is
protected?
OR
(c) Should IP end points based on their needs encrypt voice using sRTP.
Who should be responsible to secure voice the end customer or the
service provider?
OR
(d) Should networks use Topology Hiding and strip or encrypt some of the
SIP headers using Session Border Controllers that act as B2BUA.
OR
(e) Should networks use Media Relay to terminate and re-create RTP
streams at the edge of the networks using Session Border Controllers.

Similarly, in regards to QOS. Two networks need to establish policies to
determine if they want to use RSVP or DIffServ. Use MPLS VPN with QOS
etc to establish QoS. Should Session Admission Control be adopted? Once
again the protocols are established, it is just a matter of policy and
agreement based on evaluations as to which approach helps support voice
quality.

The SIP protocol, IPSec, TLS are all standardized. Unfortunately there
are too many standards. So the issue is not at all about
standardization. It is about the policy two networks want to establish
to ensure secure communications and that is a business relationship.

The issue that needs to be addressed is what security and QoS policy is
optimum to provide secure and quality communications across peering
domains?
Is there a forum that discusses the "policies" to establish secure and
quality VoIP communications across different network domains?

Satish
SBC Labs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Rosenberg
Sent: Wednesday, March 02, 2005 3:38 AM
To: Tom Taylor
Cc: sipping
Subject: Re: [Sipping] Draft: Functions of Current SBCs

Ultimately, required functions at a border depend on the business
relationships between those entities. Even for carrier-carrier
relationships, we have lots of different types: consumer voip providers
connecting to termination providers, consumer providers peering with
other consumer providers, wholesalers peering with other wholesalers,
and so on. I agree with Tom that there is a bigger gulf in the nature of
the relationships when you go from subscriber-carrier to
carrier-carrier, but its just a matter of degree.

I think that an attempt to classify the breadth of business
relationships between entities is ultimately futile. Since I don't
believe we need to standardize what an SBC is, we don't need to
standardize what a client facing SBC is vs. an inter-carrier SBC. We do
need to consider whether any of the relationships folks have seen in the
market have pushed functions into SBC products that are solving problems
not currently considered by existing standards.

-Jonathan R.

> inter-carrier. Here, for sure, the enterprise-carrier boundary falls 
> somewhere between.
> 
> Ben Campbell wrote:
> 
>> have personally built out SIP networks where no "carrier" in the 
>> sense of a VoIP (or other media) provider existed at all. (I assume 
>> you are not including an IP carrier that is not somehow participating

>> in the VoIP stuff other than moving bits around--if this assumption 
>> is incorrect than disregard my comment).
>>
>> examine what makes them different, not just what sort of company is 
>> deploying them.
>>
>>> The location changes many security aspects (we need to specify
>>> which) and also the media performance, as well as bandwidth
consumption.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Andrew Graydon" <[email-masked]>
Date: Thu, 24 Feb 2005 08:39:41 -0500

The sentiment you express here Martin and before by Christer is exactly
what this group is trying to achieve. We are not looking for any
specific solution or vendor based solution, primarily, as a group, we
are looking for information on the best methodology and architecture o
forward this technology into an implementation standard. To that end,
while there are current solutions on the market and in network, they are
not necessarily the best solution, and that is what we are trying to
determine a standard for as a group. 
There has been a lot of to-ing and fro-ing over the last while by
different proponents of SBCs and their commentators. While this has been
very useful, I think we have the information necessary at this stage to
move on and start to discuss how this FUNCTIONALITY is best defined, not
the current market technology. We have all seen the  questions and
comments on the SBCs, as a discussion/working group of a standards body,
can we leave this for the moment to focus on the functionality we need
in this area of perimeter security, define what is required and then
leave the market implementation to the vendors how should be utilising
the standards and definitions decided upon by this group.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dolly, Martin C, ALABS
Sent: February 24, 2005 7:46 AM
To: Christer Holmberg (JO/LMF); Gonzalo Camarillo (JO/LMF); Shai Mohaban
Cc: Bob Penfield; sipping; Alan Hawrylyshen; David R Oran
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Thanks Christer,

That is the best consise response/comment on this topic to date. Even,
us, service providers that deploy SBCs and/or SBC like functions, have a
need to "identify how a SBC affects SIP", and work on ways to address
these.

Cheers,

Martin

>>>Christer Wrote on 2/23/2005 at 11:17am

Hi,

I agree with Gonzalo. We can list all the functions in the world, and
I'm sure it's interesting reading to many people, but at the end we
should identify how and what affects SIP and SIP procedures. 

Please also remember that WE, if I've understood correctly, invited the
SBC vendors to provide information about what functions the SBCs provide
- NOT to argue whether they are bad or not.

There has also been a few mails about where in a network the SBCs can be
located. I also think that we need to remember that there may be more
than one SBC between the end-users, and that must be taken into
consideration when the "toolbox" is extended... 

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Roy, Radhika" <[email-masked]>
Date: Sun, 27 Feb 2005 22:44:44 -0500

Medhavi:
 
We did discuss this during RFC 3261 (Jonathan R. - is this ALG example for modifying SDP an exception or we are missing something?). 
 
We did NOT agree that a SIP Proxy will be allowed to change SDP. It is fundamental, like Web, to SIP standards. It is a very serious thing because it will have basic implications in designing of all SIP products.
 
By the way, in 3rd Party Controller RFC, it is defined as a B2BUA. So, is the case of Transcoder (Exploder and others).
 
If you want to change this, let us "standardize" it right from the beginning instead of "twisting" it creating confusions.
 
Radhika

________________________________

From: Medhavi Bhatia [mailto:[email-masked]]
Sent: Sun 2/27/2005 10:20 PM
To: Roy, Radhika; 'Christer Holmberg (JO/LMF)'; [email-masked]; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Radhika,

What about entities which are not UAs (or B2BUAs) which modify SDP ? (like ALGs). Guess they fall through the terminology trap door ;) I'd still call them proxies (trusted or malicious) according to Section 26.1.3 in rfc 3261.

-Medhavi. 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roy, Radhika
Sent: Sunday, February 27, 2005 5:49 PM
To: Medhavi Bhatia; Christer Holmberg (JO/LMF); [email-masked]; Brian Rosen; Richard Fogel; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

One thing that we need to make sure that we must follow the terminologies used in SIP RFCs. For example, a SIP Proxy must NOT modify SDP. However, a SIP UA can modify SDP. That is why, the term B2BUA is used in the context of Transcoder, 3rd party Call Controller, etc.

If anyone wants to violate the above definition of SIP Proxy, it will create a whole lot of confusions in SIP standards, products, and industry as a whole.

Let us not "twist" the fundamental aspects of SIP standards.

Keeping the above thing in our mind, let us see what we call this entity (e.g., SBC).

Best regards,

Radhika

PS: By the way, some vendors have used the term as "SIP Signaling Proxy." It is the SIP Proxy that modifies the SDP, where needed based on some predefined service logic, but does NOT receive or send RTP/media. There are so many "tricks" are being played in development of the products in the industry. Let us not follow those non-standard terms because it will defeat the main purpose of standardization. 

________________________________

From: Medhavi Bhatia [mailto:[email-masked]]
Sent: Sun 2/27/2005 3:58 PM
To: Roy, Radhika; 'Christer Holmberg (JO/LMF)'; [email-masked]; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

If NAT ALG is the only function the SBC is providing, it doesn't need to be a B2BUA. In the case of transcoding too, I don't see why the SBC needs to be a B2BUA. I think the same can be done using a proxy (though the role of modifying SDP would violate RFC 3261). Going forward, things like topology hiding and interworking may become more specialized applications reducing the need for SBCs to be B2BUAs. 

I think of the SBC as more like a set of requirements, for example security related, dos attacks, spam etc. The implementations today have become more of an issue since they are not compliant with SIP. I think the markets and/or technology will evolve to be a better fit in near future.

-Medhavi.

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roy, Radhika
Sent: Sunday, February 27, 2005 3:24 PM
To: Christer Holmberg (JO/LMF); [email-masked]; Medhavi Bhatia; Brian Rosen; Richard Fogel; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Yes, they are all B2BUAs (e.g., Transcoder, 3rd Party Call Controller, etc.). However, all of them have specific names based on the services that are being provided by each one of them among the SIP UAs.

Best regards,

Radhika R. Roy

SAIC

________________________________

From: [email-masked] on behalf of Christer Holmberg (JO/LMF)
Sent: Sun 2/27/2005 1:35 PM
To: [email-masked]'; 'Medhavi Bhatia'; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Regards,

Christer Holmberg

Ericsson Finland

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]]On Behalf Of [email-masked]
	Sent: 24. helmikuuta 2005 23:23
	To: 'Medhavi Bhatia'; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	We have now a good agenda item for the SIPPING WG: Humming on various name proposals  :-)

	Henry

________________________________

	From: Medhavi Bhatia [mailto:[email-masked]] 
	Sent: Thursday, February 24, 2005 2:39 PM
	To: [email-masked]; 'Brian Rosen'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	I'd still vote for something like P-SBC and N-SBC. We already know these are kinds of SBCs. The word customer premise needs to be captured, so P-SBC should be "Premises-SBC". I can't get the same understanding just by the word perimeter.

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Thursday, February 24, 2005 12:14 PM
	To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	>How about client side and network side?

	1. The intermediaries used in carrier networks (often referred to as SBC in a confusing manner) could be called "Network based Session Controllers" or NSC.

	2. The intermediaries at the perifery of private IP networks, colocated with the NAT/FW could be called "Perimeter Session Controllers" or PSC.

	Thanks, Henry

________________________________

	From: Brian Rosen [mailto:[email-masked]] 
	Sent: Thursday, February 24, 2005 10:43 AM
	To: [email-masked]; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	Henry

	As always, you wield a sharp sword.  I think you are correct, we need to differentiate a client side SBC from a network side SBC and we need names.

	Brian

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Thursday, February 24, 2005 10:45 AM
	To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
	Subject: RE: [Sipping] Draft: Functions of Current SBCs

	Medhavi,

	It appears the location of such intermediaries makes the critical difference:

	2. A perimeter device (such as Borderware or SIP media Proxy - these are product names ) that is collocated as CPE with the NAT and Firewall. This co-location changes many security aspects (we need to specify which) and also the media performance, as well as bandwidth consumption. Multi-homing is an issue here, not to forget.

	I suggest we should always make this distinction. Maybe someone proposes some definitions or names for each.

	Thanks, Henry

---

From: [email-masked]
Date: Thu, 24 Feb 2005 11:06:03 -0600

>How about client side and network side?
 
1. The intermediaries used in carrier networks (often referred to as SBC in
a confusing manner) could be called "Network based Session Controllers" or
NSC.
 
2. The intermediaries at the perifery of private IP networks, colocated with
the NAT/FW could be called "Perimeter Session Controllers" or PSC.

Thanks, Henry

  _____  

Henry

As always, you wield a sharp sword.  I think you are correct, we need to
differentiate a client side SBC from a network side SBC and we need names.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, February 24, 2005 10:45 AM
To: 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Medhavi,

2. A perimeter device (such as Borderware or SIP media Proxy - these are
product names ) that is collocated as CPE with the NAT and Firewall. This
co-location changes many security aspects (we need to specify which) and
also the media performance, as well as bandwidth consumption. Multi-homing
is an issue here, not to forget.

I suggest we should always make this distinction. Maybe someone proposes
some definitions or names for each.

Thanks, Henry

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Medhavi Bhatia
Sent: Thursday, February 24, 2005 9:20 AM
To: 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Richard,

Based on discussions on other email threads on SBCs we pretty much
understand them today as perimeter security devices. Our focus in this group
is SIP SBCs of course. Now we may change the name and call it a SIP
perimeter security device, but that does not change much does it ? The
functions you describe in this new draft can only be implemented today by
creating the same set of problems (SDP inspection/rewrite etc), so what
exactly is the new stuff which is being proposed ? The security requirements
only grow each day with new kinds of attacks, violations and ways to detect
and prevent that. Previously, these devices were called firewalls and then
we have SBCs. It is also widely recognized that SBCs will merge with
firewalls since they are in the data path (So we will be back to using the
term firewalls).

-Medhavi.

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Fogel
Sent: Thursday, February 24, 2005 9:50 AM
To: [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

I apologize for the confusion. The Edge Proxy is not an SBC. It is a SIP
perimiter security device. Other functions such as protocol conversion etc.
might  be part of an implementation for a given customer but are not part of
the spec.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, February 23, 2005 2:41 PM
To: 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Protocol conversion (mostly H323-SIP) can be accomplished in a signaling
converter and there are several products on the market. This has nothing to
do with NAT traversal, which in turn has nothing to do with spam and meeting
various security threats. 

All of the above do not require an SBC.

Thanks, Henry

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Fogel
Sent: Tuesday, February 22, 2005 3:02 PM
To: [email-masked]
Subject: Re: [Sipping] Draft: Functions of Current SBCs

I think that SBCs have some functionality needed by the carriers, such as
NAT traversal and
protocol conversion (mostly H323-SIP), but that functionality should be
included in a new
device which specifically targets perimiter security, spam and NAT
traversal. In particular,
spam is such a serious threat (as described by Rosenberg et al. in draft
"SIP and Spam") that it must be checked now. Malformed messages must be
checked at the perimiter as they can crash
vulnerable internal servers and UAs (as shown by the PROTOS Test Suite).
Extra authentication must be done at the perimiter to stop
impersonation, call hijacking and denial of service.

From: David R Oran  <mailto:[email-masked]> <[email-masked]>
Date: Fri, 18 Feb 2005 12:19:48 -0500
To: "Bharrat, Shaun"  <mailto:[email-masked]> <[email-masked]>
Cc: Marc Petit-Huguenin  <mailto:[email-masked]> <[email-masked]>,
sipping  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [Sipping] Draft: Functions of Current SBCs

On Feb 18, 2005, at 10:48 AM, Bharrat, Shaun wrote:

> Marc:

>>> SBC implementations out there currently "solve" the NAT

>> problem without

>>> requiring any special support from the IAD (there are some

>> IAD requirements

>>> such as symmetric signaling and RTP but leaving those out).

>> How does ICE,

>>> STUN, etc solve the NAT traversal problem in this manner --

>> don't they all

>>> require active participation on the part of the IAD?

>> 
>> This is supposed to be a good thing. We need better endpoints, not
>> crutches for broken endpoints.

> 
> No one is arguing against the notion that in a perfect world, we
> have "good" endpoints. Take the argument further and everything should
> be fixed so that there is no need for NAT. Realistically, NAT is
> going to be around for a long time, there will IADs that don't support
> STUN and ICE, and customers will want to nevertheless support these
> NAT'd IADs. This is one of the functions currently provided by SBCs.
> 

I agree, since we are not debating what would be "better" than an SBC
but rather what they are deployed to do *and why*. Note that the why
and the what are equally important and it's critical to connect the two
or we won't be able to sort through the design or requirements space
later on. Where I got off the boat with these drafts was the implicit
scoping to just about any function in the universe, whether or not it
required violating one of more of the SIP "architectural rules".
Clearly you could provide SOME kind of service by chaining together a
bunch of B2BUAs, but we've already have a different architectural model
for that - it's called the PSTN.
 
I'll issue one more plea to try to look at this in terms of things SBCs
do that violate one or more of the precepts I mentioned in an earlier
message (which is not by any means a complete set). We aren't debating
whether those things happen or not, or just how bad they are, and
whether there are better alternatives to breaking the rules at this
stage. What I do debate is claiming as SBC functions things that normal
SIP proxies or other SIP servers can do without breaking the rules.
 
Remember, we wouldn't even be having this thread if the SBCs weren't
doing things that break the rules.
 
Dave.

---

From: "Andrew Graydon" <[email-masked]>
Date: Mon, 28 Feb 2005 22:41:04 -0500

I fully agree with you that the definition currently being talked about
for an SBC is what you would classify below as a 'device' and not
necessarily a standard. There are many functions that are provided by
the current SBC incarnations and proposed in the Edge Proxy by ourselves
that will further the security aspects of SIP and could be transformed
into a standard, one of the reasons we asked people to look and discuss
the discussion paper we sent, but the current discussion is off the
standards track.

We need to revisit the full SIP message flow between the endpoint and
the variety of topologies that it may pass through, and discuss where
the security points must be and what functionality must be involved, and
then decide on whether this group wants to discuss this as a standard or
a best practice.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: February 28, 2005 12:06 PM
To: Gonzalo Camarillo
Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg (JO/LMF)';
'sipping'; 'Shai Mohaban'; 'David R Oran'
Subject: Re: [Sipping] Draft: Functions of Current SBCs

Gonzalo,

If some incarnation of an SBC is really "just" a proxy, then I agree
with you. But if it is in reality a B2BUA, which tries to be transparent
and perform functions that otherwise might be done by a proxy, as well
as a few that can't be done by a proxy, then I would like to understand
that by having it spelled out.

For instance, hypothetically we might have a device that:
- is inserted in path via Route header
- forwards messages in both directions like a proxy
- preserves dialog info like a proxy
   (from/to tags, callid cseq)
- alters From and To URIs like a B2BUA
- alters SDP like a B2BUA
- based on altered SDP, terminates and reoriginates
   RTP media streams.

This is neither fish nor fowl. I want to know about the proxy-like
things it does as part of the context to understanding it in full.

	Paul

Gonzalo Camarillo wrote:
> Paul,
> 
> if your box performs one of the functions proxies perform (e.g., 
> rewrite the Request-URI), you can call it an SBC, or whatever name you

> wish, but it will be a proxy and there will be nothing new to specify
there.
> 
> I was referring to functions that may go against the SIP spec (e.g., 
> SDP rewriting). We need to document them and come up with alternative 
> solutions (e.g., session policies) that are, as people usually put it,

> "SIP friendly".
> 
> Thanks,
> 
> Gonzalo
> 
> 
> Paul Kyzivat wrote:
> 
>>
>>
>> Gonzalo Camarillo wrote:
>>
>>> Brian,
>>>
>>> I agree with documenting:
>>> 1) bad behavior -- we have better answers
>>> 2) bad behavior - we need to do something
>>>
>>> although the better answers would not be documented in this
document.
>>>
>>> Still, I would not like to document here normal behavior, for the 
>>> reasons given before in this thread.
>>
>>
>>
>> Gonzalo - the problem here is that there is no "normal behavior" for 
>> a B2UA or an SBC. There are behaviors that might be "normal" for a 
>> proxy. But then people deploy an SBC instead of a proxy. Whether the 
>> SBC performs functions that are normal to a proxy or not is of
interest.
>>
>> It is good however if certain behavior can be described simply, by 
>> relating it to already defined behavior for other kinds of sip 
>> components.
>>
>>     Paul
>>
>>> Thanks,
>>>
>>> Gonzalo
>>>
>>> Brian Rosen wrote:
>>>
>>>> Wouldn't it actually make sense to go ahead and list all the 
>>>> functions, classify them (normal behavior, bad behavior -- we have 
>>>> better answers, bad behavior - we need to do something, ...) and 
>>>> then go work on the parts that need attention?
>>>>
>>>> I don't want to revisit this again later and have to go through 
>>>> that work again.
>>>>
>>>> Brian
>>>>
>>>>
>>>>> From: [email-masked] [mailto:[email-masked]] 
>>>>> On Behalf Of Christer Holmberg (JO/LMF)
>>>>> Sent: Wednesday, February 23, 2005 11:17 AM
>>>>> To: Gonzalo Camarillo (JO/LMF); Shai Mohaban
>>>>> Cc: 'Bob Penfield'; 'David R Oran'; 'Alan Hawrylyshen'; 'sipping'
>>>>> I agree with Gonzalo. We can list all the functions in the world, 
>>>>> and I'm
>>>>> sure it's interesting reading to many people, but at the end we
should
>>>>> identify how and what affects SIP and SIP procedures.
>>>>>
>>>>> Please also remember that WE, if I've understood correctly,
invited 
>>>>> the
>>>>> SBC vendors to provide information about what functions the SBCs 
>>>>> provide -
>>>>> NOT to argue whether they are bad or not.
>>>>>
>>>>> located. I also think that we need to remember that there may be 
>>>>> more than
>>>>> one SBC between the end-users, and that must be taken into 
>>>>> consideration
>>>>>> From: [email-masked] [mailto:[email-masked]]
>>>>>> Sent: 21. helmikuuta 2005 14:12
>>>>>> To: Shai Mohaban
>>>>>> Cc: 'Bob Penfield'; 'sipping'; 'Alan Hawrylyshen'; 'David R Oran'
>>>>>>> If people think we should not include here things that can
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> potentially
>>>>>>
>>>>>>> be handled by other entities such as SIP proxies then so be it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Exactly. As the draft indicates in its abstract and its
introduction,
>>>>>> the purpose of this exercise is to identify functions that cannot
be
>>>>>> performed with the current SIP toolbox. Once we identify these
>>>>>> functions, we will extend the toolbox appropriately.
>>>>>>
>>>>>> However, if a proxy, which is part of the current toolbox,
>>>>>> can already
>>>>>> perform a particular function, we do not have any problem. We do
not
>>>>>> need to document what operators do with their proxy servers.
>>>>>>
>>>>>>
>>>>>>> But on the other hand you see arguments that SBCs are
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> redundant or evil,
>>>>>>
>>>>>>> etc, and maybe exactly because there is such confusion it would
be
>>>>>>> worthwhile to describe why carriers are using these devices
today in
>>>>>>> general...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The scope of this draft is clearly not to state whether or
>>>>>> not SBCs are
>>>>>> evil. We are only interested in functions that require SIP
>>>>>> extensions so
>>>>>> that they can be carried out without breaking the SIP
architecture
>>>>>> (e.g., end-to-end integrity, confidentiality and feature 
>>>>>> negotiation).
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Gonzalo
>>>>>>
>>>>>>
>>>>>> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
>>>>> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

---

From: Eric Burger <[email-masked]>
Date: Fri, 4 Mar 2005 18:11:06 -0500

I would offer that if *I* have a bunch of obsolete, non-conforming devices
in *my* network, *I* can chose to make those devices *look* conforming by
inserting a "proxy" device that, to the Internet, is the UA.

If one wants to call that device a SBC, great.  If you want to call that an
Edge Proxy, great (well, not so great, as people might think you are talking
about a SIP Proxy, which it is NOT).

However, if *you* insert a device that is the *endpoint* for all of my SIP
traffic, i.e., I cannot *ever* make an end-to-end SIP request, then I would
do my best to find someone that does allow the Internet to work.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, February 24, 2005 12:14 PM
To: 'Brian Rosen'; 'Medhavi Bhatia'; 'Richard Fogel'; [email-masked]
Subject: RE: [Sipping] Draft: Functions of Current SBCs

Thanks, Henry

Henry

Brian

Medhavi,

 

Thanks, Henry

---

From: Eric Burger <[email-masked]>
Date: Fri, 4 Mar 2005 18:10:59 -0500

This is key and I am eagerly awaiting the holes in SIP.

I am NOT really interested in listening to the holes in Brand C's
implementation (or lack thereof) of SIP.

> Sent: Tuesday, March 01, 2005 12:40 PM
> To: [email-masked]; [email-masked]
> Cc: 'Drage, Keith (Keith)'
> >Let's first decide that a new architectural piece is needed to solve
> problems like NAT, spam, SIP DoS, etc.
> 
> You all know the IETF solutions for each. If there is interest, we can
> assemble the list of relevant IETF RFCs and Internet Drafts.
> 
> If we do, please state exactly what is missing in the current 
> documents for
> SIP NAT, SIP spam and SIP DOS. Unless you want to support 
> legacy UAs that
> don't have ICE, in which case user edge boxes, colocated as 
> CPE, would be
> OK, since they can be part of the NAT/FW and don't worsen the media
> performance.
> 
> So please state what is missing in the current IETF work, 
> item by item.
> 
> Thanks, Henry 
> 
> [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Tuesday, March 01, 2005 12:13 PM
> To: [email-masked]
> Cc: 'Drage, Keith (Keith)'
> I think you're absolutely right. I don't understand why the current
> discussion is getting bogged down in taxonomy questions about B2BUAs,
> Proxies etc. Let's first decide that a new architectural 
> piece is needed to
> solve problems like NAT, spam, SIP DoS, etc. and then decide 
> what to call it
> (I've called it an Edge Proxy, but that's subject to change).
> > 
> > From: Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: Tuesday, March 01, 2005 8:05 AM
> > To: 'Medhavi Bhatia'; [email-masked]
> > I don't think we can go in this direction.
> > 
> >  
> > 
> > There is currently 2 core SIP entities defined, UA and proxy. They 
> > have rigorous definitions with state machines and defined 
> handling of 
> > various header and message bodies.
> > 
> >  
> > 
> > If your entity is conformant to RFC 3261 UA functionality, 
> then call 
> > it a UA (or a B2BUA).
> > 
> >  
> > 
> > If your entity is conformant to RFC 3261 proxy functionality, then 
> > call it a proxy.
> > 
> >  
> > 
> > If your entity is neither, then do not call it a UA or a proxy, or 
> > even nearly a UA a proxy. Further, if you need it to be 
> standardised, 
> > it needs the same rigorous definitions that are already 
> given in RFC 
> > 3261 to UA and proxy. Additionally, in defining such a new role 
> > (Paul's "neither fish nor foul" entity), the impact on backward 
> > compatibility with the existing RFC
> > 3261 entities needs to be fully investigated. You cannot 
> avoid these 
> > issues just be calling it "nearly a proxy".
> > 
> >  
> > 
> > We still however seem to be getting bogged down in 
> discussions of how 
> > we implement these things, rather than the discussion proceeding in 
> > identifying the functions that need to be supported, and 
> why existing 
> > SIP roles cannot perform these functions. We need that 
> discussion to 
> > have completed before someone can start inventing a new SIP role.
> > 
> >  
> > 
> > regards
> > 
> >  
> > 
> > Keith
> > 
> > 
>