Subject: [Sip] bis-07.9: proxies are not allowed to modify message body

From: "Bob Penfield" <[email-masked]>
Date: Thu, 21 Feb 2002 10:05:19 -0500

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.

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

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 22 Feb 2002 09:40:14 -0000

----- Original Message -----
From: Bob Penfield <[email-masked]>

> 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
=============================================

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Feb 2002 12:20:44 +0200

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

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 22 Feb 2002 11:58:16 -0000

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.

----- 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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 22 Feb 2002 14:19:35 +0200

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

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 22 Feb 2002 08:56:45 -0500

----- Original Message -----
From: "Pete Cordell" <[email-masked]>

> it's potential limiting to decide what we can and can not change today.)

In bis-08, Content-Length is (ar) not (amr). Thus a proxy is not allowed to
change the length, it can only add it.

I think in general, I'm OK with this. The basic issue is how much
call/dialog state does the intermediary need to hold on to. Anything that is
doing firewall/NAT operations will need to be dialog/call stateful to some
extent because it will need to remove any bindings/pinholes when the dialog
terminates.

The only messy part is that if the B2BUA "proxies" the request (i.e. it only
does normal proxy stuff PLUS changing the SDP) the outgoing request will
have extra Via and possibly extra Record-Route headers. I don't see any
obvious interoperability problems with this. However, many folks want to
hide their internal Via & Record-Route stuff anyway, so you would have to
remove them in that case which makes it more or less a normal B2BUA. You
have to hold onto the Vias & Record-Routes or somehow encode them into the
message you send.

Now, the moment this intermediary needs to inject a request (like a BYE), it
needs to maintain CSeq numbers. Otherwise it would be possible for a UAC and
the intermediary to generate separate requests with the same CSeq number.
And the moment you do that, the intermediary needs to generate a unique
Call-ID, otherwise it might be possible for requests originated by the UA
and the intermediary that happen to have the same CSeq number to collide if
there is a spiral somewhere in the network.

In your previous example of an element that wants to limit the set of codecs
in the SDP, wouldn't you need to re-issue the INVITE with another set of
codecs if the far end did not have any matches? There would be no way for
the UA to know which of the codecs it originally offered might be
acceptable. In that case, the intermediary will need to bump the CSeq
number. Therefore, you need to be a B2BUA which generates a unique Call-ID
and its own CSeq numbers.

cheers,
(-:bob

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 22 Feb 2002 16:29:51 -0000

> change the length, it can only add it.

When I said 'the conclusion' I really meant Robert's conclusion, which was
more of 'a conclusion' than the final conclusion !

> obvious interoperability problems with this.

Nor do I, but if someone assumes that it can't change then potentially they
may come up with some cunning plan that inadvertantly introduces
interoperability problems.  So I think its safer for the definition of a
proxy to reflect this - especially as people will do it anyway.

> However, many folks want to

As an aside, there used to be via hiding, but that was removed because it
complicated loop-detection (I think).  It could probably be put back in now
that we're looking at Max-Forwards to do this.

But back to the plot, theoretically, you can go a long way down the route of
making an anonimiser that messes around with all sorts of SIP headers, but
still knows nothing more about SIP states than your average stateless SIP
proxy.  This is another example of why I think it is premature at this stage
to be too bullish about what a proxy can and can not change.  We might just
inadvertantly kill off that killer app.  (Mind you, looking at the table I
can't see immediately what I would change - other than Content-Length.)

> there is a spiral somewhere in the network.

True, that is a whole new beasty.

> and its own CSeq numbers.

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

If no match was found by the remote UAS, then the call would be dropped 'cos
you're not using that much bandwidth whatever the reason !'

> (-:bob

Back to philosophical points again, in the case of VoIP, the whole package
comes in two halves, invitation/membership control, and media control.  SIP
does the former, and SDP does most of the latter.  To arbitrarily say that
you will need to mess around with the invitation aspects, but not the media
control aspects seems hard to justify at this early stage.  I think it's
also messing policy with protocol design.

But I won't worry about it too much, as I'll just get on with it and do what
I have to do like everybody else out there, which at the end of the day is
the reality of the situation.  It just seems a shame that having put so much
work into the spec, it doesn't reflect what is really going to happen in the
real world.

Pete.

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 22 Feb 2002 16:44:13 -0800

Thanks for pointing this out - Updating UDP in a proxy might be a bad idea
but some people will do it anyways. However, saying a proxy can't do things
with bodies seem like a bad idea. Imagine that to achieve privacy and
someone decides to encrypt a body.

I don't see the reason to put this "MUST NOT" in. Can someone explain?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Bob
> Penfield
> Sent: Thursday, February 21, 2002 7:05 AM
> To: [email-masked]
> Cc: Jonathan Rosenberg
> Subject: [Sip] bis-07.9: proxies are not allowed to modify message body
>
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 24 Feb 2002 18:50:44 +0200

Hi,

If you do that, and you can prefectly do that if you wish, you have a
B2BUA... I do not see a problem with that.

I think the problem everybody has with this MUST NOT is the following.
People think: "If the elements in my architecture are called proxies, I
have a very good architecture, but if the elements in my architecture
are B2BUAs, my architecture is crap."... and to make every architecture
look good, they want to call stretch the concep of proxy so that all
their elements are called "proxies".

I do not think it is a big deal how we call these elements... let's call
everything an OPES-element instead of "proxy" or "B2BUA" and everybody
will be happy ;o)

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 25 Feb 2002 13:29:41 -0000

Gonzalo,

I think there are two problems here...

1) There are two definitions of a B2BUA floating around.  The definition of
this list/group is "Any intermediary device that is not a Proxy as defined
in bis."  And the definition in bis is quite clearly that it is a UAS back
to back with a UAC, and it maintains dialog state.  There are many devices
that fall into the first category that are not necessarily built as defined
by the second.

2) The group has managed to create (intentionally or otherwise) a smear
campaign against B2BUAs.  So the definition becomes "Any intermediary device
that is not a proxy as defined in bis.  NOTE: these devices are EVIL (c.f.
OPES)."

For me the main concern about a back to back UAS / UAC implementation
(perhaps with the two instances joined by something other than SIP) is that
they lose feature transparency.  It's the loss of feature transparency that
is the problem, not that it is a B2BUA.  There are many devices that are not
pure proxies that do not lose feature transparency, and even back to back
UAS / UACs can be built that still have feature transparency most of the
time.

Thus people are trying to build innovative products delivering exciting
services beyond simple call routing, that are good netizens, but they are
getting tarred as bad implementations by people that have never seen them
simply because they are not pure proxies.  Added to that, there are likely
to be many bad implementations of pure proxies, but nothing is said about
that.

In the light of that, one shouldn't be too surprised that there is some kick
back from the people building these devices.

After all, wasn't the promise of SIP that it could offer lots of exciting
new services?  Now an intermediary device can only do what I can already do
on my domestic phone line.  Anything else comes with a WARNING, which is not
very helpful for a technology attempting to build a new world order of
exciting, new and radical services !

To move forward, I think we need to:-

1) Either understand that anything that is not a pure proxy is not
necessarily a B2BUA (That really is just a matter of definitions.  I don't
care what you call it.  Maybe Application-aware Proxy.), or relax the
definition of a proxy at least so it allows changing the body.

2) Have people appreciate that some of the most exciting services, including
many that will make SIP worth developing, will end up being implemented with
elements of B2BUA in them, and if they want SIP to be successful, they
shouldn't be prejudiced against them and perpetuating the smear campaign.

Pete.

---

From: "Dean Willis" <[email-masked]>
Date: Sun, 24 Feb 2002 22:49:09 -0600

Gonzalo wrote:
> you have a

Here's my worry about that. There are REASONS why proxies are as limited as
they are in the specification. It's to keep them from breaking other things.
This has come up time and time again in 3GPP -- almost every time that we
fudge the line between proxy and B2BUA, we end up breaking something else.

The proxy rules are, I believe, most effective in providing "forward
compatibility" -- a basic proxy will work, as expected, with any reasonable
future SIP extension method type, extension header, or payload. In fact,
that's part of the rule we use in determining "reasonableness" for
extensions. No such restraint applies to B2BUAs. If you "break the rules" of
a proxy, all compatibility bets are off, and problems become very likely.
It's like running naked through Central Park at night with a bunch of $20
bills taped to your backside -- you MIGHT not have an unfortunate encounter,
and if you do you'll hear a whole lot of "I told you so!"s.

--
Dean