[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] B2BUA & Max-Forwards
This is correct. A B2BUA can't blindly forward a request containing a
Require header.
The saving grace for a B2BUA is that it does not need to understand the
extension in detail. It just needs to know whether it can forward a request
that contains a given Require header. This can be easily provisioned using
some sort of ASCII configuration file, and doesn't require any new code etc.
A B2BUA could even routinely download the list of acceptable Require headers
from some sort of server. (A smart B2BUA could even post back a set of
unknown Require headers that it has seen recently.)
Added to that, ideally extensions will avoid the need for specifying Require
as much as possible.
Thus the impact of Require headers is likely to be fairly minimal for most
B2BUAs. As it is so easy to support the majority of Require extensions in a
B2BUA, B2BUAs will likely support the extensions before the majority of
actual UAs!
(And a firewall related B2BUA really ought to be blocking what it doesn't
understand anyway, so there is little conflict here also.)
Pete.
----- Original Message -----
From: "Jonathan Rosenberg" <jdrosen@dynamicsoft.com>
To: "Adam Roach" <adam@dynamicsoft.com>
Cc: "'Phil Reynolds'" <preynolds@ridgewaysystems.com>; <sip@ietf.org>
Sent: 05 December 2002 06:37
Subject: Re: [Sip] B2BUA & Max-Forwards
> inline.
>
> Adam Roach wrote:
> > -----Original Message-----
> > From: Phil Reynolds [mailto:preynolds@ridgewaysystems.com]
> >
> >
> >>Now your back to restricting what I can and can't do in an
> >>intermediary. It can't be a B2BUA 'cos it doesn't need to
> >>honour require headers (the UA at the other end does that,
> >>if they were meant for my intermediary then they would be
> >>proxy-require?), and it can't be a proxy 'cos of the rules
> >>about not changing the body so what is it?
> >
> >
> > Broken.
>
> Adam is correct.
>
> >
> > The restrictions placed on nodes by 3261 (which I'm merely
> > reiterating, not imposing) aren't an authoritarian attempt
> > at unnecessary proscription. They serve a purpose.
> >
> > I'll describe one of the (several) purposes that applies
> > to the situation you propose.
> >
> > One of the things that UAs are required to be able to do is
> > sign and/or encrypt the bodies and/or some subset of the
> > headers to ensure confidentiality and/or integrity. The
> > protocol places restrictions on various nodes to ensure
> > that this can be done. Your box is broken precisely because
> > it interferes with these abilities (or, more precisely,
> > these abilities interfere with it).
>
> Let me add some more here.
>
> Anything that deviates at all from proxy rules will need to be a b2bua
> and follow b2bua rules, including processing of Require. There is no
> black-or-white here. Let me give some examples.
>
> Lets say my b2bua is a proxy in all ways, BUT it happens to muck with
> SDP to enable firewall traversal. Surely then it can ignore Require,
> right? WRONG. Lets say I define extension foo, which means "the content
> of this SDP is not what it seems - look at this header to instead find
> the real port/address for media". This extension needs a Require
> (because only a UA ever looks at bodies), but not a Proxy-Require,
> because proxies don't. Thus, your almost-a-proxy will fail in odd ways
> because it has ignored Require when it shouldn't have.
>
> Indeed, for any operation prohibited to a proxy, but allowed for a UA, I
> can come up with an extension, indicated in a Require header, that would
> need to be understood by a b2bua which breaks the proxy rules and
> performs this operation. Indeed, the rules on what is a UA, and what is
> a proxy, are meant precisely to help define what goes in Require, and
> what goes in Proxy-Require.
>
> Whether or not Require gets passed on by such a b2bua depends entirely
> on the application logic.
>
> -Jonathan R.
>
> --
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> jdrosen@dynamicsoft.com FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________
> 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