Subject: RE: [Sip] Proxies Can Modify SDP?

From: [email-masked]
Date: Tue, 5 Feb 2002 08:21:22 -0700

Yes, a prominent proxy vendor does this with their firewall control proxy.

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, February 05, 2002 7:22 AM
> To: Tom-PT Taylor
> Cc: [email-masked]'
> Subject: Re: [Sip] Proxies Can Modify SDP?
> 
> 
> 
> Hi,
> 
> A proxy controlling a media firewall, and/or doing some kind of "codec
> filtering", should be able to modify the SDP, right?
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> >I've been involved in a little bit of correspondence with 
> TIPHON WG 3,
> >where there is some question whether proxies are allowed to modify
> >SDP.  I know this has shown up in E-mail, but it does not show up in
> >2543bis.  Could someone confirm this so I can forward the message to
> >TIPHON?
> > 
> >Tom Taylor
> >[email-masked]
> >Ph. +1 613 736 0961 (ESN 396 1490)
> 
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: [email-masked]
Date: Tue, 5 Feb 2002 09:46:20 -0700

Also note what just came up in a separate thread, table 2 in bis does not
allow a proxy to modify the Content-Length header, which would typically be
needed to modify SDP.

John Hearty
Level3

> Tom-PT Taylor writes:
> TIPHON WG 3, where
>  > there is some question whether proxies are allowed to 
> modify SDP.  I know
>  > this has shown up in E-mail, but it does not show up in 
> 2543bis.  Could
>  > someone confirm this so I can forward the message to TIPHON? 
> 
>    A better question to ask is what happens when a
>    proxy wants to modify SDP, but the SDP was either
>    sent encrypted or end to end.
> 
> 		  Mike
>

---

From: Phil Reynolds <[email-masked]>
Date: Wed, 6 Feb 2002 12:40:07 -0000

Dangerous, it may be, but then that's my middle name :-)

Mucking about with the network headers without understanding the bodies is
even more dangerous -- at best every thing just works (more by luck than
judgement), normally the world just goes bang in varied and unpredictable
ways. Any protocol that relies on end-to-end integrity of the message is
<mock-Scottish-accent, British-cultural-in-joke> doomed
</mock-Scottish-accent> to failure unless the absolute nature of both ends
are known up front, or are you trying to tell me that your VoIP to PSTN
gateway doesn't muck with the message body.

For a protocol to be widely acceptable and universal it must be adaptable to
the needs of all and, in the case of VoIP protocols, be transferable through
a wide variety network architectures and infrastructure. The widespread
take-up of VoIP and videoconferencing has been hampered by its inability to
reach beyond the confines of a single enterprise without breaking the
security of the enterprise firewall.

Being one of the "prominent sip vendors" (we like to think so anyway :-))
who produce NAT traversal proxies, we feel that if you want your
communications to work then you have to put up with us mucking about with
your SDP and hence content-length header. Weather that makes us a B2BUA or
an "illegal proxy" is irrelevant to anyone except the marketing people.

If you are sufficiently paranoid (quite rightly so in many applications)
then you are going to have to deploy network infrastructure that does not
change addresses, as encrypting the SDP is about as interoperable as
encrypting the entire network packet (IP headers and all), it just ain't
going to work in the general case. To add security to SIP there needs to be
some way of adding authentication/encryption information without affecting
the ability of the network infrastructure to read and modify the control
information (e.g. add a separate body with authentication information, or
add this to the RTP payload -- I'm no security expert so don't quote me).

---------------------------------------------------------
Phil Reynolds
Ridgeway Systems and Software
Tel: +44 118 938 1211
Fax: +44 118 935 4444
mailto:[email-masked]
http://www.ridgewaysystems.com

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 05 February 2002 23:50
> 
> Danger, Will Robinson, danger!
> 
> Having proxies muck with bodies, for the purposes of nat traversal,
> compression for low speed access, and so on, is very dangerous
> territory. It brings us to issues of robustness, integrity 
> and informed
> consent which have been the pain of opes for well over a year now. I
> suggest you read RFC 3238 for a summary of some of the issues.
> 
> The use of encryption alone means that we know for certain that this
> mechanism will not work in many cases. I recommend we steer 
> clear of it
> in the spec. Another nicety I came up with was Require. What 
> happens if
> a UA modifies the semantic of SDP in some way, and uses Require to
> enforce it? Now, the "proxy" will need to look at the Require headers
> too. Hmm. Sounds like a B2BUA again.
> 
> That means that the column for Content-Length under proxy 
> would be "ar",
> since we will need to add one when converting from UDP to 
> TCP. The spec
> will mention that as the reason this value is present. However, I
> believe the spec should remain as is with regards to the other content
> headers; proxies are not supposed to muck with them.
> 
> Now, it is true that, ahem, certain prominent sip vendors 
> have products
> called firewall control proxies which muck with the SDP. Whether these
> things are rightly proxies, based on the SIP spec, or a 
> B2BUA, is more a
> matter of technical marketing than standards, so I would not lose too
> much sleep over it. Its far less a stretch than what people 
> are calling
> softswitches these days ;). Our job here at IETF is to write standards
> that work and are good for the Internet.
> 
> 
> Thanks,
> Jonathan R.
>