Subject: [Sipping] Edge Proxy Informational Draft

From: Richard Fogel <[email-masked]>
Date: Tue, 22 Feb 2005 15:53:42 -0500

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: Wed, 23 Feb 2005 15:00:33 -0500

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
>

---

From: Richard Fogel <[email-masked]>
Date: Wed, 23 Feb 2005 15:14:13 -0500

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,

-Medhavi.

-----Original Message-----

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

Richard Fogel
BorderWare Technologies

---

From: Arjun Roychowdhury <[email-masked]>
Date: Wed, 23 Feb 2005 16:25:10 -0500

Richard,
Did a very quick read. Some comments:

This draft makes some assumptions on what a network can or cannot do,
which I do not believe are common properties that can be enforced:

Section 2.2:
Not sure what you mean by stating a SIP message being known and verified.
Known: are you suggesting it must be a known method ? If so, then it
prohibits two end devices (or networks) to exchange a new SIP method
(say for gaming) that you do not know about.

Verified: Its a tougher problem than it sounds. Can all networks be
'walled' successfully ? Are we saying that if we get a call from a
domain that is not in my database, I reject it ? It could well be a
call from my friend on vacation using an ISP in tahiti.

Section 2.3, pt 2:
"The message is checked to determine whether it is constitutes DoS
        or spam"

Can you expand on what parameters must be checked to detect its a DoS attack ?

Section 2.4: Spam protection:

The most elementary form of spam tracking is URI based. If we make an
assumption that [email-masked] will always call from spam.ru, then
this works. In reality, from addresses are generated in bulk and
spammers keep changing their IDs. Which is why most email spam
solutions in addition also check for content heuristics (incidentally
gmail seems to do a pretty good job of it, though very agressive). So,
besides URI based detection, which will likely not help beyond basic
detection, other mechanisms need to be deployed (Jonathan's draft does
speak about alternatives too)

Section 2.7: Doing this can have an impact on interoperability. There
are several devices out there today that still make 'protocol
mistakes' in heades that are unimportant for the call. Dropping them
would mean a call that worked before stops all of a sudden after
deploying this node.

Similarly, somewhere else you require that long messages be dropped.
Well, again, this is an interop issue. I know of several vendors who
generate NOTIFY messages that are over 20,000 bytes ! (thanks to XML
payloads).

regds
arjun

-- 
Arjun Roychowdhury

---

From: Richard Fogel <[email-masked]>
Date: Wed, 23 Feb 2005 16:59:34 -0500

Thanks for your comments. Please read my responses inline.

Arjun Roychowdhury wrote:

Richard,

Section 2.2:

I meant that the sender of the message be known, not the method. In
general as you state later, this is a tough problem that is addressed
by other papers. An Edge Proxy implementation would use several
approaches.

There could be policies about how you accept calls from unknown
domains. For example, the Edge Proxy could add a question mark to the
display name to indicate the call is from an unknown domain.

Section 2.3, pt 2:

A DoS would be an attempted flood, e.g. sending many BYE messages per
sec.

At a minimum we could start with blacklisting the source IP. Assuming
that the caller has not spoofed his IP, a good place to start is a
reverse DNS lookup to verify the caller's domain.

In general only the headers specified in 3261 and other specs would be
checked for validity, any "unknown" header would be passed. You make a
good suggestion in that the malformed message setting could be tuned to
allow benign malformed headers to pass.

Another good suggestion. The max message size could be based on the
message's method. I was thinking more like 50K.

regds
arjun

Richard Fogel
BorderWare Technologies

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Wed, 23 Feb 2005 18:41:08 -0500

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,

-Medhavi.

-----Original Message-----

Of Richard

Fogel

a

 
Richard Fogel
BorderWare Technologies