Subject: Re: [Sipping] Edge Proxy Informational Draf

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Mar 2005 14:53:19 -0500

Richard,

I just skimmed your doc. Without going into detail I have a couple of 
observations:

- your draft describes what you call a "SIP Edge Proxy". But many of
   the functions you describe cause the device to be something other
   than a proxy - just like the other descriptions of SBCs.

- as Mike Hammer commented, the device you describe seems omniscient(?)
   and omnipotent. It is involved in all requests to or from users
   of the domain it serves, even intra-domain requests. As such, it is
   acting as the proxy/registrar for all the AoRs in the domain, and
   has access to data, including authentication data for each user as
   well as black and white lists for each user. At the same time it is
   a firewall for all sip traffic in/out of the domain. As a firewall
   it is the first line of attack. IMO this is a poor way to design a
   system - too many eggs in one basket.

It feels like you are trying to describe all the security functions 
required for a *system*, but then are packaging them all up as if it was 
possible and made sense to put them all into one box. While it is an 
attractive sales pitch, I don't find it very believable.

	Paul

Richard Fogel wrote:
>   I assume the draft you refer to is 
> http://ietfreport.isoc.org/idref/draft-bhatia-sipping-sbc.
> There is no SIP anti-spam or meaningful security functionality mentioned 
> in it. The question about NAT traversal  is whether it can be provided 
> by an Edge Proxy in a manner that is more consistent with SIP 
> principles, standards, and architectural integrity. It is clear that if 
> NAT traversal is necessary, a SIP Edge proxy could provide the more 
> widely understood SBC functionality of NAT traversal and port 
> translation without making a hash of SIP architectural precepts.
> 
> According to the draft, how do SBC's provide meaningful SIP application 
> security functionality, such as REGISTER DoS/DDoS attacks, 
> impersonation, malformed SIP messages, etc.? All of these issues must be 
> addressed from an architectural and standards basis, which is the 
> purpose of the Edge Proxy.
> 
>> *From: *"Medhavi Bhatia" <[email-masked]>
>> *Date: *Wed, 23 Feb 2005 18:41:08 -0500
>> *To: *"'Richard Fogel'" <[email-masked]>
>> *Cc: [email-masked]
>> *Subject: *RE: [Sipping] Edge Proxy Informational Draft
>>
>> The function of SPAM, NAT-Traversal, access control and security are 
>> all listed in the first SBC draft which appeared as typical functions 
>> executed on it. These are essentially different levels of security 
>> provided on a border.
>>  
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Richard Fogel [mailto:[email-masked]] 
>> <mailto:[email-masked]%5D>
>> *Sent:* Wednesday, February 23, 2005 3:14 PM
>> *To:* Medhavi Bhatia
>> *Cc:* [email-masked]
>> *Subject:* Re: [Sipping] Edge Proxy Informational Draft
>>
>> As this is an informational draft only for discussion purposes I only 
>> wanted to discuss the scope of the problem without getting into the 
>> solutions (which would be part of a proper Edge Proxy spec). I would 
>> be happy to expand on the NAT issues in a revision if necessary. What 
>> I am putting forward in the paper is that SBCs are only a stop-gap 
>> solution to a much bigger problem about perimiter security, access 
>> conrtol, spam prevention and NAT traversal.
>>
>> Medhavi Bhatia wrote:
>> Richard,
>>  
>> An SBC generally is a SIP aware firewall, and it can be implemented as a
>> B2BUA or a SIP Proxy (most implementations tend to provide protocol fixing
>> and tend to be B2BUAs). The part where things break down is SDP re-writing
>> without explicit knowledge of the endpoint and I am not sure you even look
>> at that as a problem in this draft. In fact I don't see new insight here
>> apart from what is already on the table wrt the SBC drafts. Your draft 
>> talks
>> about requirements (or features) and claims architectural integrity. I am
>> not sure you are backing these statements well.
>>  
>> -Medhavi.
>>  
>>   
>>
>>     -----Original Message-----
>>     From: [email-masked] [mailto:[email-masked]]
>>     <mailto:[email-masked]%5D> On Behalf
>>         
>>
>> Of Richard
>>   
>>
>>     Fogel
>>     Sent: Tuesday, February 22, 2005 3:54 PM
>>     To: [email-masked]
>>     Subject: [Sipping] Edge Proxy Informational Draft
>>      
>>     We have submitted an informational draft for review by the SIPPING
>>     WG. The
>>     draft deals with the concept of a SIP Edge Proxy, a perimeter
>>     device that
>>     combines the functionality of a SIP Proxy Server, SIP-aware
>>     firewall, and
>>         
>>
>> a
>>   
>>
>>     Session Border Controller, in a way that is consonant with
>>     established SIP
>>     standards and architectural integrity.
>>      
>>     We apologize for missing the deadline for inclusion of this
>>     subject matter
>>     on the agenda of the forthcoming IETF meeting in Minneapolis, but we
>>     welcome
>>     commentary and feedback on the draft, which can be found at
>>     http://www.borderware.com/sip_edge_proxy.php
>>      
>>     Richard Fogel
>>     BorderWare Technologies
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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: Richard Fogel <[email-masked]>
Date: Thu, 03 Mar 2005 09:18:49 -0500

Thanks for your comments Paul.

>   than a proxy - just like the other descriptions of SBCs.

There has been a lot of discussion in the group about whether this is a 
proxy, an ALG or a B2BUA. The purpose of the draft was to discuss SIP 
security problems and a device which would address them. Once SIPPING 
accepts that such a device is needed we can decide on its name.

> required for a *system*, but then are packaging them all up as if it 
> was possible and made sense to put them all into one box. While it is 
> an attractive sales pitch, I don't find it very believable.

It is certainly possible that when implemented the Edge Proxy is indeed 
a system of boxes, each with specific functionality. The Edge Proxy 
draft is meant to lay out the requirements for a device/system. When 
implemented it must meet the needs for scalability, failover, etc. while 
being able to delegate such functions as authentication to other 
existing infrastructure.

>> There is no SIP anti-spam or meaningful security functionality 
>> mentioned in it. The question about NAT traversal  is whether it can 
>> be provided by an Edge Proxy in a manner that is more consistent with 
>> SIP principles, standards, and architectural integrity. It is clear 
>> that if NAT traversal is necessary, a SIP Edge proxy could provide 
>> the more widely understood SBC functionality of NAT traversal and 
>> port translation without making a hash of SIP architectural precepts.
>>
>> According to the draft, how do SBC's provide meaningful SIP 
>> application security functionality, such as REGISTER DoS/DDoS 
>> attacks, impersonation, malformed SIP messages, etc.? All of these 
>> issues must be addressed from an architectural and standards basis, 
>> which is the purpose of the Edge Proxy.
>>
>>> all listed in the first SBC draft which appeared as typical 
>>> functions executed on it. These are essentially different levels of 
>>> security provided on a border.
>>>  
>>>
>>> As this is an informational draft only for discussion purposes I 
>>> only wanted to discuss the scope of the problem without getting into 
>>> the solutions (which would be part of a proper Edge Proxy spec). I 
>>> would be happy to expand on the NAT issues in a revision if 
>>> necessary. What I am putting forward in the paper is that SBCs are 
>>> only a stop-gap solution to a much bigger problem about perimiter 
>>> security, access conrtol, spam prevention and NAT traversal.
>>>
>>> Medhavi Bhatia wrote:
>>> Richard,
>>>  
>>> apart from what is already on the table wrt the SBC drafts. Your 
>>> draft talks