Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message bod y

From: "George Foti (LMC)" <[email-masked]>
Date: Fri, 22 Feb 2002 08:11:35 -0500

There was the definition of "transperent" B2BUA to allow a proxy to initiate
things it is not supposed to do, such as a BYE to terminate  a session (in
case of prepaid) or deregistration (if the network operator decides to kick
somebody out)
 
So while the spec. says as a *pure* proxy you cannot modify SDP, I guess
most of us will do B2BUA, as the way out.

Regards

George Foti
Ericsson Canada

> -----Original Message-----
> From: Christer Holmberg (LMF) 
> Sent: Friday, February 22, 2002 7:20 AM
> To: Pete Cordell
> Cc: Bob Penfield; [email-masked]; Jonathan Rosenberg
> Subject: Re: [Sip] bis-07.9: proxies are not allowed to modify message
> body
> 
> 
> 
> Hi Pete,
> 
> PERSONALLY (I am not sure it's correct from a standard point 
> of view) I would
> say that even if the basic spec doesn't allow a proxy to 
> modify the SDP, you can
> always define a "SIP proxy extension" (similar to any other 
> SIP extension)
> defining a feature/functionality which does allow 
> modification of the SDP - and
> you could still call your node a proxy ("a proxy supporting 
> the SDP modification
> extension", or something...).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> 
> Pete Cordell wrote:
> 
> > Christer,
> >
> > I did see that conversation, but it just seemed to fizzle 
> out (maybe I
> > didn't see the end).
> >
> > I quite liked the conclusion where you could change 
> Content-Length (amr),
> > but none of the others.  (But then that suited my service 
> today.  Generally
> > it's potential limiting to decide what we can and can not 
> change today.)
> >
> > If it comes down to what's in a name, then I don't really 
> see the point.  If
> > I'm non-compliant if I call it a proxy, and compliant if I 
> call it a B2BUA,
> > then it seems a bit odd.
> >
> > And I would say that the spec does (try to) stop me 
> building something that
> > is not a proxy and not a full B2BUA.  According to the spec 
> I either have to
> > be a proxy in which case I can not change the SDP, or I can 
> be a full back
> > to back UAS / UAC - (there's no partial B2BUA and the 
> definition of B2BUA is
> > quite specific about what it is.).
> >
> > For example, a proxy that wants to limit the bandwidth used 
> on a certain
> > path can operate purely statelessly (and pretty dumbly), 
> but it is not a
> > proxy (by the current definition) nor is it a B2BUA because 
> it doesn't need
> > to maintain dialog state.
> >
> > We could define some more proxy types (such as stateless, 
> transaction
> > stateful, dialog stateful, body modifying stateful), but I 
> don't really
> > think that buys us anything.
> >
> > At the end of the day the body is no different from any of the other
> > headers, and the test of whether it can be modified by a 
> proxy should be
> > similar - if it doesn't break the protocol, and it might be 
> useful, then
> > allow it.
> >
> > On a philosophical note, it seems bad to come up with a 
> protocol that is not
> > NAT or firewall friendly, but even worse to then try and 
> prevent anybody
> > from trying to do something about it (including ALGs in 
> NATs, Midcom, and a
> > number of other schemes you may care to name!)
> >
> > Pete.
> >
> > =============================================
> > Pete Cordell
> > Tech-Know-Ware
> > [email-masked]
> > +44 1473 635863
> > =============================================
> >
> > ----- Original Message -----
> > From: Christer Holmberg <[email-masked]>
> > To: Pete Cordell <[email-masked]>
> > Cc: Bob Penfield <[email-masked]>; 
> <[email-masked]>; Jonathan
> > Rosenberg <[email-masked]>
> > Sent: 22 February 2002 10:20
> > Subject: Re: [Sip] bis-07.9: proxies are not allowed to 
> modify message body
> >
> > >
> > > Hi,
> > >
> > > It's not too long since we had this same discussion.
> > >
> > > Then it was realized, that if a proxy is allowed to 
> modify the message
> > body, one
> > > could argue it should also be allowed to modify one or more of the
> > Content-Xxx
> > > headers (in most cases Content-Lenght, but maybe also 
> others), maybe
> > > encode/decode the message body etc etc etc. It was then 
> decided that the
> > spec
> > > should NOT define such behaviour for a basic proxy, and 
> that IF a proxy
> > wants to
> > > do something like that it will have some kind of B2BUA 
> behaviour (nobody
> > says
> > > you have to implement "full" B2BUA behaviour).
> > >
> > > Regards,
> > >
> > > Christer Holmberg
> > > Ericsson Finland
> > >
> > >
> > > Pete Cordell wrote:
> > >
> > > > ----- Original Message -----
> > > > From: Bob Penfield <[email-masked]>
> > > >
> > > > > Lines 2622-2623 say that "The proxy MUST NOT add to, 
> modify, or remove
> > the
> > > > > message body". Does this mean that all existing 
> Firewall Control
> > Proxies
> > > > > which update the SDP (like example 3.1.5 in
> > draft-ietf-call-flows-05.txt)
> > > > > non-compliant? I guess they will all have to be 
> turned into B2BUAs.
> > > >
> > > > I too think that this is overly restrictive, and may 
> come to bite us in
> > the
> > > > future.
> > > >
> > > > There are many things that you can do, firewall control 
> for one, that
> > > > require you to change the SDP, but don't necessitate a 
> full back to back
> > UAC
> > > > / UAS.
> > > >
> > > > For example, a proxy in an enterprise context might 
> want to remove high
> > > > bandwidth codecs from the SDP so that it doesn't use 
> too much bandwidth
> > on
> > > > the access link.  This seems quite legitimate policy, 
> and helpful.  I'm
> > sure
> > > > that there are many other things that will become 
> attractive in the
> > future
> > > > that we can't think of at the moment.
> > > >
> > > > In fact, from simple proxy to full B2BUA there is a 
> whole spectrum of
> > > > devices, of which they are only two points.  Indeed, at 
> some phases
> > > > intermediaries may act as stateless proxies, and other 
> phases they maybe
> > > > full B2BUAs.  Making a device non-compliant just 
> because it doesn't fit
> > into
> > > > one of those definitions doesn't seem helpful.  Such 
> restrictions are
> > not
> > > > the route to service utopia.
> > > >
> > > > I understand that this is in part determined by some of 
> the security
> > issues,
> > > > but I see this as a defect in the security, rather than anything
> > > > fundamentally wrong.  (In fact, in the case of VoIP I 
> see very little
> > > > benefit in securing the SDP as there are so many 
> additional ways that
> > you
> > > > can corrupt the media that it really doesn't buy you 
> much.  This may not
> > be
> > > > the case for instant messaging.)
> > > >
> > > > I would also warn against forcing users to choose 
> between security and
> > > > connectivity, as connectivity will almost always win.  
> After all, the
> > PSTN
> > > > has very little authentication and for most of the 
> people, most of the
> > time
> > > > it works just fine.  (Call tracing is about the only 
> thing from a PSTN
> > style
> > > > service that authentication would help with.  But you'd 
> just drop your
> > > > authentication if you were doing malicious calls.  
> Another observation
> > is
> > > > that e-mail spoofing is dead easy, but it doesn't seem 
> to be a major
> > problem
> > > > even though it has been around for years.)
> > > >
> > > > So maybe the spec should say 'SHOULD NOT change the 
> payload if it's
> > secured
> > > > in some way'.  'SHOULD NOT' is sufficient because the 
> UAS is the one
> > that
> > > > makes the final decision whether to accept the modified 
> payload or not.
> > (I
> > > > would imagine that most of the time it doesn't even 
> check - either
> > because
> > > > the user doesn't care, or due to PKI and shared secret 
> problems that
> > have
> > > > been mentioned in the e-mail exchanges.)
> > > >
> > > > Pete.
> > > >
> > > > =============================================
> > > > Pete Cordell
> > > > Tech-Know-Ware
> > > > [email-masked]
> > > > +44 1473 635863
> > > > =============================================
> > > >
> > > > > cheers,
> > > > > (-:bob
> > > > >
> > > > > Robert F. Penfield
> > > > > Chief Software Architect
> > > > > Acme Packet, Inc.
> > > > > 130 New Boston Street
> > > > > Woburn, MA 01801
> > > > > [email-masked]
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > >
> 
> 
> _______________________________________________
> 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: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Fri, 22 Feb 2002 08:31:55 -0500

Inline [RRR]

-----Original Message-----
From: George Foti (LMC) [mailto:[email-masked]]
Sent: Friday, February 22, 2002 8:12 AM
To: Christer Holmberg (LMF); Pete Cordell
Cc: Bob Penfield; [email-masked]; Jonathan Rosenberg
Subject: RE: [Sip] bis-07.9: proxies are not allowed to modify message
bod y

[RRR] Is not better to clarify in the spec: "Pure" Proxy vs. "Transparent" B2BUA Proxy?

Regards

George Foti
Ericsson Canada

---

From: "George Foti (LMC)" <[email-masked]>
Date: Fri, 22 Feb 2002 08:39:49 -0500

I guess, its up to the editors to consider including such a definition. But
its already in people's mind, may be thats why it is not explicitly defined
rgds/gf

> From: Roy, Radhika R, ALASO [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 8:32 AM
> To: George Foti (LMC); Christer Holmberg (LMF); Pete Cordell

---

From: "George Foti (LMC)" <[email-masked]>
Date: Fri, 22 Feb 2002 17:45:35 -0500

Comments inline/gf

> From: Pete Cordell [mailto:[email-masked]]
> Sent: Friday, February 22, 2002 1:05 PM
> To: Adam Roach; Bob Penfield
> Cc: [email-masked]
> Sure, if I want to be malicious I can do loads of things and 
> I don't have to
> wait until I receive a SIP INVITE to do it.  I can quite 
> easily just fire
> out loads of UDP packets and gobble up bandwidth that way.  After all,
> saying something is PCMU when it is actually something else 
> is not going to
> make the dialog of any use to the remote UA.
> 
> I was really thinking more of a facilitating service rather 
> than one that
> was enforcing.  For example, it might be perfectly reasonable 
> to use CD
> quality on the internal LAN, but not across the enterprise 
> access link.
> Therefore a UA would want to declare that it can do CD 
> quality on the off
> chance that it might be useful, but be happy if some helpful 
> intermediary
> advised that you were probably going to loose most of your 
> packets in you do
> it across the access link (not to mention getting your 
> managers upset).
> Many, many people would be happy to work within those bounds, 
> and something
> that helps them get the right mix at the right time can only 
> be helpful.
> 
> Besides, who said there wasn't any stick here.  The 
> considerate proxy could
> have a nasty side to it and actually talk to the firewall, a 
> la Midcom, and
> tell it to discard packets if this flow goes out of SLA.
> 

Very similar to what 3GPP plan to do to police misbehaving clients. 
So basically you *ONLY GET* what you *ASK* for. The rest is thrown out.

> So go ahead and build your client that interprets "PCMU/8000" as
> "cd-quality-audio".  I'm sure it won't be the worst 
> bastardisation of the
> SIP spec.
> 
> Pete.
> 
> From: Adam Roach <[email-masked]>
> To: 'Pete Cordell' <[email-masked]>; Bob Penfield
> <[email-masked]>
> Cc: <[email-masked]>
> Sent: 22 February 2002 16:39
> Subject: RE: [Sip] bis-07.9: proxies are not allowed to 
> modify message body
> 
> 
> > > From: Pete Cordell [mailto:[email-masked]]
> > >
> > > All I was thinking was, if it saw something like:
> > >
> > > m=audio 3456 RTP/AVP 0 7
> > > a=rtpmap:0 PCMU/8000
> > > a=rtpmap:7 LPC/44100/2     # Whatever linear CD quality is
> > > m=video 2232 RTP/AVP 51
> > > b=6000         # Haven't checked SDP, but looking for 6 Mbits/s
> > > a=rtpmap:51 H262/90000
> > >
> > > in the messages that zipped past it, then it could change it to:
> > >
> > > m=audio 3456 RTP/AVP 0     # No CD quality
> > > a=rtpmap:0 PCMU/8000
> > > m=video 2232 RTP/AVP 51
> > > b=128         # Limited to 128kbits/s
> > > a=rtpmap:51 H262/90000
> >
> > Trying to do this sort of enforcement in the SIP signalling
> > layer is horribly, horribly misguided. If you need to enforce
> > this sort of policy, you'll need support at the access level;
> > there are a whole suite of protocols (RSVP, COPS, etc) designed
> > for exactly this.
> >
> > If you try to do this with a SIP proxy, I will personally be
> > one of the first people on your network to build a client that
> > interprets "PCMU/8000" as "cd-quality-audio," give it to my
> > friends, and send whatever media I feel like, regardless of
> > what your meddlesome proxy thinks it has to say about it.
> >
> > And I guarantee that I won't be the last.
> >
> > /a
> >

---

From: "Mark Watson"<[email-masked]>
Date: Tue, 26 Feb 2002 19:40:11 -0000

Jon,

Makes sense, but two points:
1) If I don't encrypt my message body, I am presumably saying that I do
trust any element to look at it, or I don't care. A Service Provider
offering a service based on network-modification of the message body either
forces me to send it un-encrypted (=less customers) or sets up the security
systems needed for me to send it encrypted (=more customers)

2) I think the nub of the definition problem is that it is possible to build
a device which modifies message bodies, and which deals with all of the
'UA-like' behaviour this entails, but which is stateless. There is no good
name for this device as just the 'UA' in B2BUA implies transaction stateful
however you define it (it logically contains UAs hence transaction layers).

Whether you think something is anathama or an invention of genius, it is
always a good idea to have a name for it.

...Mark

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: 26 February 2002 05:05
> To: [email-masked]'
> Forbidding proxies to modify message bodies does not improve 
> security; it's
> the other way around. The fact that we can secure messages 
> bodies end-to-end
> entails that proxies may not be entitled to modify bodies.
> 
> Mostly, this just reinforces the fact that bodies are intended for
> end-to-end use. Many of the misconceptions about this issue 
> arise from a
> belief that the operators of proxy servers are necessarily a 
> privileged
> participant in a SIP network. Actually, if you are a 'network 
> operator', and
> you want to inspect and modify bodies, you must have a trust 
> relationship
> with users - they must accept that you, the network operator, are the
> appropriate recipient of SIP message bodies, and they must secure MIME
> bodies with that expectation (any encrypted bodies must be explicitly
> intended to be decrypted by the network operator). In that sense, the
> network operator becomes the destination of the request, and 
> thus more or
> less a user - and this is why the discussion naturally transitions to
> B2BUAs. I think this in no way diminishes the value of 
> network-based service
> that require access to SIP message bodies - it just shows 
> that if you want
> to offer these sorts of services, you require that users 
> trust you in a way
> that they aren't asked to trust proxy servers, which operate only on
> headers.
> 
> Jon Peterson
> NeuStar, Inc.
>