Subject: preventing direct INVITE in enterprise

From: "Larry Dolinar" <[email-masked]>
Date: Wed, 27 Oct 1999 16:07:21 -0500

What is the current thinking on the path ACKs and BYEs travel and how this
affects enterprise implementations?  For efficiency's sake, UAs "in the
open" would want the most direct path for 2xx, ACK, and BYE. Meanwhile UAs
behind a firewall would proxy requests and responses, so does the proxy bear
all the responsibility for hiding any Contact: information the UA might
include that would reveal its address?  Normally Contact: information is
simply copied, right?  

Section 6.13 seems to indicate INVITEs must (sip-new-00) add Contact:, while
section 11.1 indicates it's optional.  But I suppose the Request-URI would
still reflect the proxy server behind the firewall, if implemented
consistently.

Suppose a marginally compliant UAC outside the enterprise decides to cache
Contact: addresses across calls (bad UA!). 
Does the enterprise proxy also prevent the INVITE from arriving, since the
Request-URI is "too specific", and return 403 Forbidden or something
similar?

I'm trying to allay some fears on the part of enterprise types here that are
concerned over the potential for incoming calls bypassing the proxy based on
direct response by the enterprise UA.  Even to the point of requiring all
2xx, ACK, and BYE traffic to traverse the proxy.  Any cause for concern?
All insights welcomed.

regards,
larry

---

From: "Alex Doyle" <[email-masked]>
Date: Wed, 27 Oct 1999 17:58:43 -0400

preventing direct INVITE in enterpriseMy two cents:

* Enterprise proxies can use the Record-Route header to ensure they receive
subsequent BYEs, right?  Subsequently, I don't think proxies should have to
hide Contact information -- they should be able to just copy it, as you
mentioned.  Because it receives the Record-Route, the called UA knows to
ignore the Contact field.

* UAs should never cache Contact addresses.

* You can certainly make a case that value can be added by making 2xxs,
BYEs, ACKs, etc. go through a proxy server.  Network-oriented features can
be implemented on a proxy server, and could be triggered by these events.

Alex

  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Larry Dolinar
  Sent: Wednesday, October 27, 1999 5:07 PM
  To: SIP Mailing List (E-mail)
  Subject: preventing direct INVITE in enterprise

  Section 6.13 seems to indicate INVITEs must (sip-new-00) add Contact:,
while section 11.1 indicates it's optional.  But I suppose the Request-URI
would still reflect the proxy server behind the firewall, if implemented
consistently.

  I'm trying to allay some fears on the part of enterprise types here that
are concerned over the potential for incoming calls bypassing the proxy
based on direct response by the enterprise UA.  Even to the point of
requiring all 2xx, ACK, and BYE traffic to traverse the proxy.  Any cause
for concern?  All insights welcomed.

  regards,
  larry

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 28 Oct 1999 00:44:43 -0400

> Larry Dolinar wrote:
> 
> What is the current thinking on the path ACKs and BYEs travel and how
> this affects enterprise implementations?  For efficiency's sake, UAs
> "in the open" would want the most direct path for 2xx, ACK, and BYE.
> Meanwhile UAs behind a firewall would proxy requests and responses, so
> does the proxy bear all the responsibility for hiding any Contact:
> information the UA might include that would reveal its address?
> Normally Contact: information is simply copied, right?

If your desired service is to hide addresses, then the proxy will need
to modify things like the Contact header, SDP addresses, and the From
field. But, if all you want is for the signaling to all pass through the
enterprise proxy, there is no need. Record-Route will get the proxy on
the path for all messages.

> while section 11.1 indicates it's optional.  But I suppose the
> Request-URI would still reflect the proxy server behind the firewall,
> if implemented consistently.

Contact will be mandatory in INVITE. This has nothing to do with the
address in the request URI. The request URI leaving a UAC generally is
the same as the To field. However, if there is an outbound proxy (as
there is in your scenario), all requests go to the proxy no matter what
the request URI is.

> 
> Suppose a marginally compliant UAC outside the enterprise decides to
> cache Contact: addresses across calls (bad UA!).
> Does the enterprise proxy also prevent the INVITE from arriving, since
> the Request-URI is "too specific", and return 403 Forbidden or
> something similar?

Alex has pointed out correctly that Contact headers aren't supposed to
be cached across calls. If a UA outside the enterprise uses an old
Contact header anyway, the request will never even hit the proxy (thats
the whole problem, right?) This is solved by your firewall; don't let
port 5060 into your network unless it comes from your proxy. 

> 
> I'm trying to allay some fears on the part of enterprise types here
> that are concerned over the potential for incoming calls bypassing the
> proxy based on direct response by the enterprise UA.  Even to the
> point of requiring all 2xx, ACK, and BYE traffic to traverse the
> proxy.  Any cause for concern?  All insights welcomed.

I don't see a problem here. Use Record-Route, and all compliant
implementations go through your proxy. Preventing clients from
communicating directly is no different here than with IP in general. If
thats your goal, make sure your firewall doesn't let port 5060 in or out
unless it is from your own proxy. 

-Jonathan R.
-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 210 
dynamicsoft                                 West Orange, NJ 07052
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com