Subject: RE: [Sipping] Edge Proxy Informational Draf

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

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

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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Thu, 24 Feb 2005 10:16:37 -0500

I am sorry. We had it in one of the earlier draft versions and replaced it
with the sections on "identity". Identity verification is one of the most
important mechanisms for SPAM verification. (See
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-sipping-spam-00
.txt).

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Richard Fogel
Sent: Thursday, February 24, 2005 9:33 AM
To: [email-masked]
Subject: RE: [Sipping] Edge Proxy Informational Draf

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"  <mailto:[email-masked]> <[email-masked]>
Date: Wed, 23 Feb 2005 18:41:08 -0500
To: "'Richard Fogel'"  <mailto:[email-masked]>
<[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
 
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