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

From: Richard Fogel <[email-masked]>
Date: Tue, 22 Feb 2005 16:02:22 -0500

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.

> Cheers,
> Shaun

>> -----Original Message-----
>> From: Marc Petit-Huguenin [mailto:[email-masked]]
>> Sent: Friday, February 18, 2005 10:31 AM
>> To: Bharrat, Shaun
>> Cc: Arjun Roychowdhury; Jani Hautakorpi; sipping
>> Subject: Re: [Sipping] Draft: Functions of Current SBCs
>>
>>
>> Bharrat, Shaun wrote:

>>> Arjun:
>>>
>>> Not agreeing or disagreeing about what this draft should be; just
>>> have a question on the following statement...
>>>
>>>

>>>> As an example, a thread above stated that the primary

>> objective of an

>>>> SBC is NAT traversal. If that were true, then the work is

>> already done

>>>> :-) - we have ICE, STUN and the rest of the group.
>>>>

>>>
>>>
>>> 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.
>>

>>> Thanks and cheers,
>>> Shaun

_______________________________________________
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: Arjun Roychowdhury <[email-masked]>
Date: Wed, 23 Feb 2005 16:05:46 -0500

On Tue, 22 Feb 2005 16:02:22 -0500, Richard Fogel <[email-masked]> wrote:
> 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

How does one actually check for voice spam ? The draft you mention
highlights the problems and certain mechanisms as well as highlights
the fact that voice spam filtering is a harder problem than email spam
filtering. Also, I have not yet seen voice spamming in live networks,
so not sure if you are indicating its a reality today that takes more
precedence than the other SBC functions listed.

regds
arjun

-- 
Arjun Roychowdhury

---

From: [email-masked]
Date: Wed, 23 Feb 2005 14:41:26 -0600

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

From: David R Oran  <mailto:[email-masked]> <[email-masked]>

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

Cc: Marc Petit-Huguenin  <mailto:[email-masked]> <[email-masked]>,
sipping  <mailto:[email-masked]> <[email-masked]>

  

Dave.