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

From: Richard Fogel <[email-masked]>
Date: Thu, 24 Feb 2005 09:50:25 -0500

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 <[email-masked]>

Date: Fri, 18 Feb 2005 12:19:48 -0500

To: "Bharrat, Shaun" <[email-masked]>

Cc: Marc Petit-Huguenin <[email-masked]>, sipping <[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.

_______________________________________________
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: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 24 Feb 2005 10:20:27 -0500

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

 

Dave.

---

From: [email-masked]
Date: Thu, 24 Feb 2005 09:44:59 -0600

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

  _____  

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,

-Medhavi.

  _____  

Thanks, Henry

  _____  

 

 

Dave.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 24 Feb 2005 11:43:19 -0500

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,

Thanks, Henry

  _____  

Richard,

-Medhavi.

  _____  

Thanks, Henry

  _____  

 

 

Dave.