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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 2 Mar 2005 15:55:30 -0500

Jonathan,

Agree with you general approach.  But, you may need to re-evaluate what
you think is already nailed.

>From what I have been able to glean from this thread there is one aspect
of #1 at the end of your message:

Given a desire to put a NAT at the boundary between ITSPs, what
function/mechanism enables:
1) ITSP-approved external IP addresses to be used throughout the SIP
message and body,
2) Does not permit a node on the "inside" to communicate internal IP
addresses to a node on the "outside?

I think the NAT traversal mechansisms defined thus far allow the
internal addresses to be leaked to an "accomplice" outside the NAT
protected boundary and reveals the nature of the bindings that NAT
establishes.  It also assumes that the NAT is passive to this process.
More efficient means may be available if the NAT is actively involved.

It might be good to come to a conclusion about whether such "IP
address-compromising" behavior is:
A) desirable
B) possible to preclude.

If IP address hiding is not possible, then this really becomes a FW
question and whether the pinhole-learning should be handled strictly by
the ITSP network, or whether devices external to the boundary may be
used.  If the cooperation of the FW is in play, then perhaps a more
efficient means of learning pinholes is desirable.

Put another way, the discover-delay of the existing passive-NAT
traversal mechanisms might be unacceptable, whereas discovery-delay
characteristics of an active boundary device is what is needed (among
other things).

Mike

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Jonathan 
>Rosenberg (jdrosen)
>Sent: Wednesday, March 02, 2005 4:26 AM
>To: Paul Kyzivat (pkyzivat)
>Cc: 'Drage, Keith (Keith)'; [email-masked]; Medhavi Bhatia
>Subject: Re: [Sipping] Draft: Functions of Current SBCs
>
>One of the problems we have in this thread (and there are 
>many) is that there is a misconception about the difference 
>between a logical and a physical role.
>
>In SIP, we have tried quite hard to specify things in terms of 
>logical roles. These are behaviors that a physical entity can 
>follow. Indeed, in order to provide flexibility, these logical 
>roles are ideally defined on a fairly fine grained basis as 
>component roles, so that a physical device can be composed of 
>many such logical roles. All of this is spelled out in:
>
>http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-sip
>-arch-00.txt
>
>We in the IETF have not specified the physical components that 
>people have to build. Indeed, we have tried to leave lots of 
>room for flexibility even on how these various roles behave. 
>We don't specify what kind of routing logic a proxy uses, or 
>how it makes authorization decisions, and so on. The result of 
>this is that vendors can build products that contain certain 
>logical roles behaving in certain ways, and still be compliant 
>to the specs.
>
>As an exmaple, considering even vanilla proxies, there are 
>different types of proxies that folks talk about - home 
>proxies, route proxies, edge proxies, and so on. The various 
>CSCF flavors of proxy/b2bua are another example of this.
>
>Applying this to the SBC discussion, SBC has become a 
>marketing term for a box that provides a set of functions. I 
>don't think it is the job of IETF to specify what has to be 
>inside of an SBC, anymore than it is our job to specify what 
>goes inside of something a vendor calls a "home proxy" or 
>"application server". However, it is our job to make sure that 
>the component functions that vendors are looking to put inside 
>of that box can be implemented using standards based techniques.
>
>As a result, I think there is a natural progression in the set 
>of activities we need to do here:
>
>1. document what various vendors and providers think these 
>boxes are doing (in terms of addressing problems) today. This 
>gives us a big set of problems to start with. I don't know 
>that these documents ever need to become RFCs; they serve as 
>fodder for subsequent work. Gonzalo's draft is a reasonable 
>starting point here.
>
>2. from these list of functions, we extract orthogonal sets of 
>problems, each of which (1) can be considered in isolation, 
>and (2) we believe represents a problem for which there is no 
>solution based on existing standards, and for which we feel 
>development of a solution is reasonable. Each of those things 
>results in a requirements document.
>
>3. from there, we follow our normal sip process
>
>4. it might be handy to have an "examples" document, akin to 
>nat scenarios and service examples, which shows the various 
>solutions we come up with being used in concert, to give folks 
>a sense of how there is a coherent solution that combines 
>these things together.
>
>
>Another thing we've discussed in this thread was whether some 
>of the problems being solved by SBCs were ones for which there 
>were already standards track alternative solutions. An example 
>of this is NAT traversal, of course. SBCs list this as a 
>primary function, yet we already have a solution based on 
>STUn/TURN/ICE. So, do we do anything here? In these cases, I 
>think we need to look at the reason why the standard solutions 
>are not being used. I can think of a few reasons:
>
>1. the standards solutions are missing some kind of important feature
>
>2. the standards solutions require support in endpoints, 
>proxies or other places, and it is easier to deploy a "single 
>box" solution that allows a problem to be addressed by 
>inserting a single box without having to change anything else 
>in the network
>
>
>If we conclude that the problem being addressed is in category 
>(2), that is something I do not think we need to do any 
>further work on here in IETF. These reasons eventually 
>evaporate once the standard solutions get implemented. A 
>problem in category (1) is more problematic, and we should 
>consider those to determine whether or not we believe there 
>are new requirements not already considered in our solutions.
>
>
>HTH,
>Jonathan R.
>
>
>Paul Kyzivat wrote:
>
>> 
>> 
>> Medhavi Bhatia wrote:
>> 
>>> I don't think the SBC is any "SIP entity". SBC is just a marketing 
>>> term, providing mostly security functions at this point.
>> 
>> 
>> I don't think you really mean that it isn't *any* sip entity - but 
>> rather that no single currently defined sip entity covers all the 
>> functions that it might perform. You seem to be suggesting 
>that it is 
>> context sensitive. We already have many compliant examples of this:
>> 
>> - UAC and UAS are separately defined, but I doubt if you can find
>>   a device that is one without also being the other.
>> 
>> - its quite common for a single device to usually be a proxy, but
>>   to sometimes send a 3xx. When it does it is acting as a UAS.
>> 
>> - it is quite common for a device to act as both a proxy and a
>>   registrar (which is a special form of UAS).
>> 
>> None of these cases bother anyone. I think the cases that bother 
>> people are when a device acts in multiple conflicting roles in a 
>> single context. A good example is a device that acts as a 
>proxy until 
>> it redeclares itself as a B2BUA and sends a BYE. This is in 
>violation 
>> of the expectations of the other parties regarding what the 
>roles are 
>> in the dialog(s).
>> 
>>     Paul
>> 
>>> Consider an entity deployed at the security border doing just SPAM 
>>> detection/prevention, DoS attack prevention etc. These are SBC 
>>> functions, but they can be done using a SIP Proxy.
>>>
>>> If this entity is performing some NAT functions or transcoding like 
>>> SDP rewriting, then we need a B2B UA (there are non-compliant SIP 
>>> ALGs which perform SDP re-writing, but lets consider those as a 
>>> separate problem). For transcoding, the SBC may make the 
>transcoding 
>>> decision and send the call to a transcoder. In this case, the SBC 
>>> could be a SIP Proxy and the transcoder a B2BUA. Similarly for QoS 
>>> borders, SDP inspection may be required rather than rewrites at the 
>>> SBC. This could be done using a SIP Proxy as well, but 
>requires SDP inspection.
>>>
>>> If the SBC is generating new messages on behalf of either 
>endpoints, 
>>> it needs to be a B2BUA.
>> 
>> 
>> _______________________________________________
>> 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
>> 
>
>-- 
>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
>
>_______________________________________________
>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
>

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 3 Mar 2005 10:23:58 -0600

> address-compromising" behavior is:

Arguably not possible.

Scenario: Bob, inside a firewall, calls Charlie, who is outside. Bob 
runs his traffic through a hub that has an Ethereal listener. So does 
Charlie.

Typical conversation:

"Like, dUde! My address is 192.168.67.100 and I'm, uh, using port 10000 
for RTP. What's it look like at your end, huh? Let's figure out what my 
firewall is doing so we can break it and other righteous hackers can 
own my phone!"

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Mar 2005 13:48:12 -0500

Dean,

I think this just points up the need for the SBC to monitor the contents 
of the RTP streams in real-time, blocking or translating the verbal 
rendition of restricted internal domain names and IP addresses.

	Paul

Dean Willis wrote:
> firewall is doing so we can break it and other righteous hackers can own 
> my phone!"
> 
> -- 
> Dean
> 
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Mar 2005 23:20:39 -0500

Michael Hammer (mhammer) wrote:

> establishes. 

Well, putting aside the issue of whether IP address hiding really helps, 
if you do decide you need it, I believe ICE/STUN/TURN can be made to 
work in such a condition.

  It also assumes that the NAT is passive to this process.
> More efficient means may be available if the NAT is actively involved.

I think dumber nats are a good thing.

> address-compromising" behavior is:

Apparently operators do find it desirable, though I admit I'm not sure 
what attacks are possible. So what if someone outside my network knows 
that an endpoint has the address 10.0.1.1? Practically every computer 
behind a broadband router has this address. It doesnt mean its reachable.

> efficient means of learning pinholes is desirable.

I don't think you need to have devices external. Previous versions of 
nat-scenarios described enterprise configurations where you also can't 
rely on servers external to the firewall.

-Jonathan R.
-- 
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: Dean Willis <[email-masked]>
Date: Thu, 03 Mar 2005 23:46:29 -0600

Paul Kyzivat wrote:

> I think this just points up the need for the SBC to monitor the 
> contents of the RTP streams in real-time, blocking or translating the 
> verbal rendition of restricted internal domain names and IP addresses.

Excellent point, Paul. Can we get that into the SBC requirements draft 
as a MIUST feature? Will we also need have to have a language 
enforcement mechanism to make sure that the users do not attempt to 
communicate in a language other than that indicated by the SIP 
signaling? After all, we can't expect the SBC to decode arbitrary 
languages -- it'll probably need to load a specific codec for the 
language to be used in the session.

--
Dean

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 4 Mar 2005 05:10:33 -0500

Not possible to completely hide topology indeed. That does not mean
its not a useful function to have as a safety precaution. I really am
not sure how many people really call other people up for the sake of
exchaning their phone/device IP addresses .Its more of an added safety
precaution. Just like front airbags you know. You can still crash out
of the car from the side :-)

Its not always true that addresses that are inserted in SIP messages
that traverse to external networks are always private. They can
contain public IP addresses that happen to be traversed in the
internal route.Stripping IPs based on policy from known SIP headers at
the edge adds to a larger gamut of overall security requirements of a
network. How effective this IP stripping only from select areas
depends on the nature of the network.

Gee is it just me or is this entire SBC+ thread a lot of fun :-)

Again: may I repeat - what we need _first_ is a document identifying
the laundry list of functions that SBCs perform today. I am opposed to
the idea of not including functionality that we believe a standard
proxy or UA does already or excluding functionality that we think is
objectionable. We need a reference document that states "Yes, this is
a function that SBCs perform, but here is why we did not take it into
consideration" instead of , a year down the line "Uhh.. I don't quite
remember, search the archives, a year ago, we thought this is exactly
what a Proxy does but it looks like on further discussion there are
things we missed out"

regds
arjun

regds
arjun

-- 
Arjun Roychowdhury

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 4 Mar 2005 11:47:46 -0500

Sorry, I needed a quick followup.I missed out the main point of my
mail (this is what happens when I switch from Starbucks to Folgers)

A lot of the examples listed against topology hiding assume that its
the IP address of the caller/callee within the secure domain that is
the concern. This may not be the case. Topology hiding could be
applied to selectively/completely hide the address of any intermediary
server in that secure domain which needs to be in the call route but
does not want to expose its IP address to the outside world.

In such cases, even if A were to call B (B is outside the secure
domain) , typically, A, as a 'user' at most may have an idea on what
his own IP is, but would likely not know what is the topology/IPs of
other possibly important nodes in his network. Hence, A being able to
communicate any other IPs besides his own to B is unlikely, unless A
starts looking at SIP messages that are routed or starts poking around
his own network. I think the point of topology hiding is to not make
these addresses easily viewable/accessible. If someone is intent on
poking around, there is little much one can do.

regds
arjun

-- 
Arjun Roychowdhury

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 Mar 2005 12:07:56 -0500

A note on this: please plan to turn this feature off for emergency calls.
When the call arrives at the PSAP, they want the full trace of what happened
to the call, with no hiding of intermediaries.  You don't want to be pawing
through SBC call logs to figure out what happened when something fails.
Every element should add a VIA and they should all be there when the INVITE
arrives.

Of course, there are no protocol police, and there isn't any way to enforce
this, but it will at least be in the North American standards, and hopefully
elsewhere too.

Emergency calls will be recognizable by the SBC, so if they want to apply it
selectively, it's possible.  

I personally believe the whole idea is no more than security by obscurity,
and thus worthless.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Arjun Roychowdhury
> Sent: Friday, March 04, 2005 11:48 AM
> To: Dean Willis
> Cc: [email-masked]

---

From: Arjun Roychowdhury <[email-masked]>
Date: Fri, 4 Mar 2005 13:10:29 -0500

> selectively, it's possible.

Yes, agreed.

-- 
Arjun Roychowdhury