RE: [Sip] Never can a proxy modify SIP message body?

["Peterson, Jon" <jon.peterson@neustar.biz>]

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Chen Zaifeng,BISC R&D SA(BJ)
> [mailto:zaifeng.chen@bisc.siemens.com.cn]
> Sent: Sunday, June 15, 2003 6:19 PM
> To: 'sip@ietf.org'
> Cc: 'Jonathan Rosenberg'
> Subject: [Sip] Never can a proxy modify SIP message body?
> 
> 
> Dear All:
> I found two statements in rfc3261 which seem to conflict each other:
> 1. In page 23, in the definition of "Proxy, Proxy Server", it 
> says that "A proxy interprets, and, if necessary, rewrites 
>     specific parts of a request message before forwarding it."
> 2. In page 100, under the title of "1. Copy request", it says 
> that "The proxy MUST NOT add to, modify, or remove the 
>     message body."
> 

I don't believe these conflict with one another. The first says that a proxy
can rewrite "specific parts" of a request message. Those "specific parts" do
not include the message body. The rules for proxy processing make it quite
clear, I think, which parts proxy servers operate on.

> On the other hand, there are scenarios that need a proxy to 
> modify a SIP message body, e.g. for SIP<-->PSTN/ISDN
> calls, it is dangerous to delivery ISUP MIME content 
> encapsulated in SIP message body to SIP user client, or receive
> such ISUP content from SIP user client (in such cases the 
> ISUP content might be mostly for malicious usage) and
> forward it to somewhere like SIP-PSTN gateways, then a proxy 
> might have to screen/remove ISUP MIME content
> encapsulated in SIP message body.
> 

At the risk of rehashing old issues, I agree that there are risks associated
with the dissemination of RFC3204 ISUP MIME bodies. However, there are
alternatives to mitigating these risks by violating the operational
guidelines for proxy servers. For example, S/MIME, which is
mandatory-to-implement for user agents that support SIP-T, can be used both
to encrypt ISUP MIME bodies (so these bodies cannot be inspected by any old
UAS) and to sign ISUP MIME bodies (so that a recipient can verify that the
ISUP was not created by any old UAC).

I believe it is more secure, overall, to manage these constraints with
cryptography than it is to deploy "screening" proxy servers that are not
RFC3261-compliant.

> Any of your ideas or clarifications to my puzzles are highly 
> appreciated. Thanks!
> 
> Sincerely yours, 
> Chen Zaifeng
> --------------------------------------------------------------
> ------------
> Beijing International Switching System Corporation Ltd.
> TD/DEW
> No. 14 Jiu Xian Qiao Road
> Beijing 100016, P. R. China
> Tel:  +86-10-8457 1921
> Fax: +86-10-6436 7732
> E-mail: <mailto:zaifeng.chen@bisc.siemens.com.cn>
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
> 
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip