Subject: Re: [Sipping] What problems are SBCs addressing?

From: "Ram Dantu" <[email-masked]>
Date: Fri, 15 Oct 2004 17:00:09 -0500

We are having a workshop on this topic (VoIP Security).
In particular, we would like to work on the issues what
SBCs are not addressing. Let me know if you need
further information

http://www.globecom2004.org/images/W05_CFP.pdf

Ram Dantu

_______________________________________________
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: "Brian Rosen" <[email-masked]>
Date: Sat, 16 Oct 2004 13:54:30 -0400

The big one is that IETF specifications will REQUIRE TLS security for
emergency calls (1-1-2/9-1-1/...) because location is carried in the
signaling.  When I checked last, there were no SBCs which would maintain a
sips connection.  That may have changed, but it's an issue.

There are a number of other issues with respect to emergency calls that will
require changes in SBCs, but with respect to security its maintaining TLS.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ram Dantu
> Sent: Friday, October 15, 2004 6:00 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Sipping] What problems are SBCs addressing?
> 
>

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 18 Oct 2004 09:52:40 +0100

The apparent incompatibility between proxy based perimeter defence and
things like TLS (e.g. end-to-end encryption/authentication) is something I
want to emphasis.  (Most firewall functions are currently located at the
network perimeter.  There are motions to make all hosts in an enterprise act
as their own firewall, but it may be a while before this is widely trusted
and accepted.)  Even on HTTP, TLS isn't particularly firewall friendly as it
doesn't allow inspection (hence abuse of port 443).

So my point is, perimeter defence and end-to-end encryption/authentication
are both important security issues.  We need to avoid developing one
facility at the expense of the other.

BTW - I've taken the liberty of re-ordering Brian's list into (rough)
categories:-

Perimeter defence type things:
-----------------------
2. Firewall
3. DoS attack mitigation
5. Service provider infrastructure hiding
7. Legal Intercept (pjc - maybe a thing on its own e.g. regulatory.)

QoS type things:
-----------------
4. SLA enforcement/measurement/facilitation
7. Packet marking and remarking
9. Bandwidth management/policing

Addressing IP deployment issues type things:
-----------------------------
1. NAT traversal (and actual NAT functions)

'Regular' SIP proxy type things:
--------------------------------
6. Routing services (pjc - I assume this is SIP routing)
10. Call admission control
11. CDR creation and other billing functions
12. Protocol "repair"

Misc!:
---------
8. Protocol interwork (pjc - really a GW function?)

Of these categories, the first two are the ones I feel are not addressed by
other SIP pieces.  With regard to NAT, there are other ways to do NAT
traversal.  However, if you are required to have a DMZ proxy then having it
do NAT traversal as well may be conceptually easier than other solutions.

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware
http://www.tech-know-ware.com
For LMX XML to C++ binding see http://www.xml2cpp.com
=============================================

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Ram Dantu'" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, October 16, 2004 6:54 PM
Subject: RE: [Sipping] What problems are SBCs addressing?

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 18 Oct 2004 09:00:28 -0400

Pete

TLS is not end to end, it is hop by hop.  An SBC could implement
sips and be able to inspect, but most don't.  That's not a standards
problem; if they were 3261 compliant, they would implement TLS.
Few do. S/MIME is end to end.  SBCs clearly break that.  There is
tension between end users that want security and network operators
that want to protect the network against theft of service, etc.
It should be possible to find a standards-based way to do that,
and I'm hopeful that the discussion Jonathan started will.

The discussion about packet marking/remarking was an example of 
something other than perimeter defense which is not currently
addressed by standards.  If there was, SBCs would not need
to rewrite SDP to force media to go through it.

The categories may be helpful, but there are many ways to
cut the pie.  Call Admission control is a QoS thing, for
example.   Routing is a perimeter defense; all customer proxies
route all calls to the network to the SBC.  It does the
route beyond.  If the SBC wasn't there, the customer would
have to do it.  Et cetera. 

Brian

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Monday, October 18, 2004 4:53 AM
> To: Brian Rosen; [email-masked]; [email-masked]