Subject: [Sipping] new draft on session policies in SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 May 2002 22:09:09 -0400

Folks,

I've just submitted a new I-D on "Supporting Intermediary Session
Policies in SIP" that I think will be of interest to both MIDCOM and
SIPPING. Until this draft appears in the archives, you can pick up a
copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sipping-session-policy-00.txt

The draft is aiming to solve the paradox we have found ourselves in
around "firewall control proxies". The sip spec forbids proxies from
modifying the SDP, yet to be a MIDCOM-capable proxy, it may need to do
that. The draft proposes a general framework for allowing proxies to
have a say in session policies of all sorts, such as insertion of media
intermediaries, codec grooming, and so on, without violating the SIP
architecture, and with full cooperation and consent of end systems. It
then provides details on an instantiation of the framework to support
media intermediaries.

Comments and questions are welcome, as always.

Finally, as required of me by IETF policies, I must inform the group
that I believe that dynamicsoft may have IPR associated with this draft.
Fortunately, its being made available under our "free if you don't bug
us" policy, documented at
http://www.ietf.org/ietf/IPR/DYNAMICSOFT-SIP-UNIFY.txt.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: [email-masked]
Date: Thu, 2 May 2002 23:19:03 -0400

True that this solution does seem to get out of the sticky solution of SDP 
mangling by essentially "replicating" the elements in the body
to be changed  into new headers.

If this is adopted as a way forward, then essentially all UA's need to be 
aware of the fact that special processing needs to be done on behalf of 
midcom proxies, because these special proxies can't do it themselves. 

My only issue with this is that this now mandates NAT (for example) 
awareness onto the UAs - which is taking a step away from trying to make
UAs unaware of such translations in the network.

Again, while this soln. does address e-e encryption issues, it also does 
so by replicating (and therefore exposing) part of the SDP information
(at least IP:ports ) that had  been encrypted in the first place in the 
body.  So can we not live with the part that needs NATTing not be e-e 
encrypted
in the first place ? 

The benfits mentioned about this soln. allowing "routing" of media streams 
is very interesting though. However, I am not sure practically
if its more desirable to keep the UA unaware of such translations and let 
such a n/w deploy an "FCP" who does the dirty work instead
as today and live with the issue of not being able to totally perform end 
- end encryption for the  _full_ message body.
Why not simply change the term "Firewall Control Proxy" to "Firewall 
Control Agent" :-) ? (that takes care of not offending the dictats of the 
bis)

My Opinion: agreed that the current solution has pitfalls, but it also has 
the advantage that endpoints dont need to care about the fact that
they are/are not behind a NAT. 

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301-212-7860        (M): 240-475-2139

Jonathan Rosenberg <[email-masked]>
Sent by: [email-masked]
05/02/2002 10:09 PM

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        [Sipping] new draft on session policies in SIP

Folks,

Thanks,
Jonathan R.

---

From: David Oliver <[email-masked]>
Date: Fri, 24 May 2002 11:53:35 -0500

I support this suggestion, as it addresses issues which are of great concern
to many potential SIP users, who have requirements for (network) security
and (connection) privacy. NATs are a fact of life, at least until IPv6
arrives. In my opinion, at least, Firewalls will also be with us always, if
for no other reasons than the rational paranoia of MIS departments, and the
"Toasternet" phenomenon - small, simple hosts, such as phones, audio and
video systems, and central heating controllers cannot be reasonably be
expected to be absolutely secure against network attacks.

> mangling by essentially "replicating" the elements in the body to be
changed
> into new headers.

> midcom proxies, because these special proxies can't do it themselves. 

Strictly speaking, only UAs needing privacy and operating in a low-trust
environment (hotel network, etc.) need to be aware of the middlebox
elements. Without such awareness, they cannot make connections. STUN solves
this heuristically for some NATs, but requires significant awareness by the
UA, and does not provide for sophisticated (e.g. bandwidth limiting)
firewalls. STUN does have the advantage of only requiring the UA local to
the middlebox to be aware of its existence. In a trusted environment, it
would be possible to have a proxy perform the encryption for non-aware UAs.

> encrypted in the first place?

Unfortunately, it is messy to have part of the SDP body unencrypted, and
impossible to change it in place without breaking its digest.

There is an alternative which would keep port numbers secure, and would
limit awareness of the existence of the middlebox to the local UA, which
would work similarly to the 407 Proxy Authentication Required cycle:

A UA makes an outgoing INVITE, containing an "Content-Type: application/sdp"
causing a "4xx Media-Stream Required" response from the local proxy. This
step can be elided if the UA knows the proxy requires the media stream;
always performing it ensures the media stream is never transmitted over
insecure links (assuming the initial hop uses TLS, etc.).

The UA sends a second INVITE is sent with the UA's Media-Stream header; the
proxy acquires a NAT binding and responds with a "4xy Apply Media-Middlebox"
response, and a Media-Middlebox header containing the binding. 

Finally, the UA creates a new SDP substituting the middlebox information,
and reissues the INVITE with the MS and MM headers. The INVITE is then
forwarded by the proxy; the proxy may strip the Media-Stream and Middlebox
headers to prevent them ever being sent in the clear over any non-secured
hops. The target UA thus receives a completely normal INVITE request.

Incoming INVITEs are handled similarly with the roles reversed. The target's
local NAT-aware proxy adds an Requires: Media-Stream to the INVITE, to which
the UA responds with a provisional response containing its MS. The proxy
acquires a NAT binding and reissues the INVITE with the binding's
Media-Middlebox header, allowing the UA to issue a 200 OK response, with the
media translation incorporated into the SDP.

These are only preliminary thoughts, and I'm sure there are gaping holes to
be found. The solution does allow UAs that are not behind a NAT/firewall to
be unaware of any special handling, and no media information is sent in the
clear. The only security weakness I can see is that a *malicious* proxy
server could pass on the media stream information (as could any Middlebox
entity); this is information that could be gleaned by traffic analysis in
any case.

> is very interesting though. However, I am not sure practically if its more
> desirable to keep the UA unaware of such translations and let such a n/w
> deploy an "FCP" who does the dirty work instead as today and live with the
> issue of not being able to totally perform end - end encryption for the
> _full_ message body.

An FCP only solves the problem for users in a completely trusted network,
i.e. one in which every possible user of the network is trusted not to
eavesdrop on conversations, etc.

> the advantage that endpoints dont need to care about the fact that they
> are/are not behind a NAT. 

I believe that this is an area which needs to be solved expeditiously, and
the proposal is an excellent starting point.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: [email-masked]
<mailto:[email-masked]> Tel:    210.402.9669
Fax:   210.402.6996 

Folks,

Thanks,
Jonathan R.