Subject: RE: RE: [Sipping] Edge Proxy Informational Draft

From: "Andrew Graydon" <[email-masked]>
Date: Thu, 24 Feb 2005 00:06:59 -0500

Thanks Medhavi for the comments on the discussion paper, as a group the
SIPPING WG is a great place for voicing ideas and concepts to further
the implementation and use of SIP as a protocol and these forums help us
all. I do think though, that you may have misunderstood our intention in
submitting this to the group. We are not trying to attack any vendor or
implementation within the group but to further the knowledge and ideas
that we all work on. 

The concept of the Edge Proxy is to provide a layer of security which is
placed in both the transport layers and the application layers, while
not introducing another step in the SIP message. The concept of a proxy
is well documented and implemented in all areas of network security and
does not need redefining as a B2BUA or the introduction of another SIP
Proxy. 

This application layer proxy concept introduces beneficial functionality
to an implementation while remaining transparent to the SIP/SDP/RTP
stream, and the Edge Proxy, by providing both application layer
re-writing AND packet re-writing, introduces many standard security
features as described in the paper. With this Edge Proxy concept, other
application layer benefits may be seen, as the SIP headers may be
observed and policies imposed, before the SIP proxy is utilised. This
allows the threats and attacks mentioned in the paper to be nullified. 

In short, by combining information from multiple OSI layers from
transport to application, security may be enhanced WITHOUT pushing new
extensions and functionality to the standard at the same time as
minimising the effect on the SIP message stream. 

One comment on the paper may be that there is a lot of new ideas here,
and a couple of reads may help clarify the concept.

Andrew

________________________________________________________________________
Andrew Graydon                                 Phone: 905-804-1855 x289
V.P. Technology                                Fax:   905-804-1865
Borderware Technologies Inc.                   http://www.borderware.com

> -----Original Message-----
>Date: Wed, 23 Feb 2005 15:00:33 -0500
>From: "Medhavi Bhatia" <[email-masked]>
>Subject: RE: [Sipping] Edge Proxy Informational Draft
>To: "'Richard Fogel'" <[email-masked]>, <[email-masked]>
>Message-ID: <[email-masked]>
>Content-Type: text/plain;	charset="us-ascii"
>
>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

_______________________________________________
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: Thu, 3 Mar 2005 10:09:20 -0500

Andrew,
I think the basic issue about the draft is that of scope and content. 
You specifically mention that this draft contains newer ideas other
those already proposed before. On my reading, I did notice that you
discuss SPAM filtering (a far more complex topic than the level that
its handled in this docuement). That I agree is something that has not
been discussed in the scope of SBCs before. It may be worth for the
SBC draft authors to consider this.

The problem is that almost everything else has been proposed in some
way or the other in the other two drafts. To add to the fact, there is
enough debate already on what an SBC does and it seems to be going
nowhere. Add to that another element called a 'SIP Edge Proxy' that
does a little bit of everything and you can well appreciate that this
would add to the confusion :-)

It may be a good idea, for us, to track and define what SBCs are ,
classify them as needed (as Henry suggested, Premises or Network) and
then the authors of their draft re-evaluate what they feel can be
added to the existing definitions.

I will try and qualify my statement below.

To quote the very first para in the abstract:

"The SIP Edge Proxy is a new perimeter device that combines the
   essential functionality of a SIP Proxy Server, SIP-aware firewall and
   a Session Border Controller, in a way that is consonant with SIP
   standards and architectural integrity"

This is a-lot-o-things-in-one. Each such element is very complex on
its own(you can well judge by the 70+ mails in the SBC threads).

A part of it covers functionality of an SBC that is already covered in
more detail in the drafts that medhavi and gonazlo submitted. Some
other parts are questionable because they are not backed by solid
reasoning (see comments from me initially as well as from Mike later)

Here is a mapping, per my understanding of what this draft proposes
and what is already proposed in other drafts.

A=draft-camarillo-sipping-sbc-funcs-00
B=draft-bhatia-sipping-sbc

2.2: Identity auth - already performed and documented today by SBCs. 
(see 5.1.3 of B and 3.1 of A

2.3: Request processing - performed by SBCs again today - but this
draft makes assumptions that are not universal (see my earlier 
comments). All SBCs do some sort of request processing - but the logic
depends on the deployed network. Hence my objections to the procedure
sighted in this draft which is not universally acceptable (again, my
previous comments sight why)

2.4: Not sure if this is needed in an SBC - but probably depends on
the location of the SBC (premises or network). This is one point that
has not been proposed before as a functionality of the SBCs in A&B

2.6: Registration Authorization: This is nothing but a specialization
of Access Control. Again, its a "policy". Covered in 3.1 of A and lots
of sections of B. Again, my issue with your draft's interpretation of
2.6 is that is a possible example of a policy of a network but not a
global rule (it cannot be).

2.7: SIP Message checking: This is exactly what is done today by most
border elements. Again, the subitems you sight in that document are
_examples_ and not global rules. This forms a subset of what is called
"protocol repair" covered in 3.4 of A and 5.3 of B

2.8: Access Control: Covered in 3.1 of A 

2.9: Admission Control: covered in 5.2.1 of B and 3.3 of A.
Your draft in addition sights some examples that may be applicable to
some networks

2.10,2.11.2.12: NAT/FW
forms the main theme of both A & B, I guess that part is evident

2.13: Network and bandwith management: A mix of 3.3 and 3.1 of A and 5.2 of B

So all in all, I think what this draft does add are some example for
each section, that make specific assumptions about the network, which
are not universal, but will work as examples.

You did mention there are several other new ideas proposed - do feel
free to discuss them if I missed them in my mapping above.

regds
arjun

-- 
Arjun Roychowdhury