RE: [Sip] Re: GRUU and things that rewrite contacts

["Medhavi Bhatia" <[e-mail]>]

Paul,

See inline.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Sunday, November 07, 2004 3:16 PM
> To: [e-mail]
> Cc: 'Jonathan Rosenberg'; [e-mail]; 'Robert Sparks'; 'Peterson, Jon'
> Subject: Re: [Sip] Re: GRUU and things that rewrite contacts
> 
> 
> 
> Medhavi Bhatia wrote:
> > I may have caught up to this discussion too late, but here are some
> > thoughts. I probably need to dig deeper into the GRUU draft too.
> >
> > There seem to be two cases.
> >
> > 1) SBC sits between the UA and the proxy/registrar, where the UA sends
> > requests for the proxy addressed to the SBC.
> 
> Can you clarify what you mean above - perhaps give an example?
> In general, the UA doesn't know much about what is going on. At best, it
> knows how to construct the To-uri and derive the request-uri from it,
> and then may have a loose route to insert in the message. Perhaps the
> loose route transits an SBC, and maybe it acts as a B2BUA. Or do you
> have something else in mind?
> 
[MB] I meant that the SBC was acting as an out-bound proxy to get to the
proxy/registrar. Packets are destined (at the IP level) to the SBC. The
To/request uri's are pointing to the proxy.

>  > In this case, I don't see much
> > of a concern as contact parameters are not overwritten for REGISTER.
> 
> You state this as fact. But this goes to the heart of the problem that
> we have no definition of what an SBC does. I guess yours must not
> overwrite contact parameters in a REGISTER.
> 
[MB] I assume topology hiding (THIG) is the function of SBC we are talking
about. In that case, not passing the parameters would not be the right thing
to do. The THIG only alters IP addresses in the headers involved in routing
SIP messages (like Via/Contact/Route etc).

>  > For the
> > INVITE, since the SBC knows that the Contact is a GRUU,
> 
> It does? How? I guess it can know in some cases, if it saw the register
> that requested the GRUU it might remember the returned gruu and
> recognize its use in future requests, but that would be a lot of work.
> And it won't work for gruu values that it didnt' see being assigned.
> 
> In general you just can't recognize a gruu by inspection.
>
[MB] I assume the supported header in the INVITE will contain the gruu
option tag.  The draft mentions somewhere about how a receiving UA can
detect that the Contact is a GRUU.
 
>  > it is not
> > overwritten. The last part needs SBCs to understand the GRUUs.
> 
> Please explain what kind of understanding you think you require, and how
> it is even theoretically possible to have it.
> 
> > 2) The same as above, except the UA does not know who the Registrar is.
This
> > is a tricky application and I guess not part of the usual suspects. In
this
> > case, the SBC will need to be aware of GRUUs on the REGISTER also.
> 
> I have no idea what you mean here.
> 
[MB] Service providers, especially in broadband users have been deploying
out-bound proxies which forward requests and responses between the client
and the main server similar to the case I describe in (1). However there is
one interesting variation. Consider that the registering UA does not know it
is exchanging messages with an out-bound proxy. The To/req uri as well as
the dest IP address are pointing to a proxy which then uses some other means
to target the request to the UA's real proxy:

(1) Request-uri/To point to the proxy (P) and dest IP points to the SBC. 
(2) Request-uri/To/dest IP all point to the SBC. SBC forwards request to P.

In both cases, SBC is acting as an out-bound proxy in a functional sense.
However in (2), the UA does not know about P. I assume that the GRUU which
is assigned to the UA also cannot point to the proxy and the domain part
must be changed by the SBC.

> > The SBC also may have an option to create a GRUU and map one obtained
from
> > the Registrar to this one.
> 
> I think that was more or less what Jonathan was suggesting it might do
> in his original posting. It is pretty ugly.
> 
[MB] I don't think it is necessary. I may be wrong of course.

> I have the distressing feeling that SBCs are just doing random stuff,
> which has lots of potential unintended consequences.
> 
[MB] Yep. SBCs implement a lot of features. Some of the them were mentioned
earlier on another thread. However there are clearly some things which must
not be done (like re-writing contact parameters) and some things which it
must be able to decipher when it processes packets (like media description
for the message). These functions are provided today only via B2BUAs and
most people designing SBCs or planning to make one don't always know the
requirements clearly. Application Servers based on B2BUAs deal with the same
problem. I know of core proxies manufactured by some major vendors which are
based on B2BUAs.

At minimal we need to see how requirements of intermediate elements and
networks, like THIG and media relays are factored in when designing
features. We need to look at requirements of service providers in greater
detail.


> 	Paul
> 
> > -Medhavi.
> >
> >
> >>-----Original Message-----
> >>From: [e-mail] [mailto:[e-mail]] On Behalf Of
Paul
> >
> > Kyzivat
> >
> >>Sent: Tuesday, September 21, 2004 9:13 AM
> >>To: Jonathan Rosenberg
> >>Cc: [e-mail]; Robert Sparks; Peterson, Jon
> >>Subject: Re: [Sip] Re: GRUU and things that rewrite contacts
> >>
> >>This would be a good time for those that build SBCs to take note and
> >>action, and to speak up if they have difficulty with the deployment of
> >>GRUUs.
> >>
> >>	Paul
> >>
> >>Jonathan Rosenberg wrote:
> >>
> >>>Jon,
> >>>
> >>>I agree with you and Paul that we cannot, and should not, try here or
> >>>anywhere else to define an SBC and consider its impacts. I think we can
> >>>and should discuss the impact of contact-rewriting elements, and point
> >>>out, as you say, that the identity draft would detect such a case.
> >>>
> >>> From a practical matter, I will say that the fact that SBCs will
likely
> >>>not work with GRUU is a real concern. It is going to make it hard to
> >>>deploy gruu, and generally I am a really big fan of easy-to-deploy
> >>>solutions. For better or worse, there ARE SBCs deployed in many
existing
> >>>SIP networks, and in those networks, getting gruu deployed will be
> >>>harder. It will require coordination now between not just the client
> >>>vendor and SIP server vendor, but now also the SBC vendor. In my
> >>>experience, the more parts of the machine that all need to be
> >>>simultaneously upgraded for a new feature, the less likely,
> >>>exponentially I think, it is that such an upgrade will occur. If you
> >>>couple this with the fact that, while gruu is definitely a key part of
> >>>our specs, its an infrastructure improvement with no new features per
> >>>se, it becomes a hard sell.
> >>>
> >>>I still believe that the only alternative on the table - using a new
> >>>header field for conveying gruu in register and invite/200 - has an
even
> >>>worse deployment path.
> >>>
> >>>So, absent a better suggestion, and I don't have one, I think our only
> >>>choice is to document the problems per above.
> >>>
> >>>-Jonathan R.
> >>>
> >>>
> >>>
> >>>Peterson, Jon wrote:
> >>>
> >>>
> >>>>I agree with Paul that SBC behavior is probably defined too poorly to
> >>>>refer
> >>>>to it directly in the GRUU draft, and personally I'm very skeptical of
> >>>>taking on that definition as a deliverable for GRUU. At the risk of
> >>>>complicating a discussion about non-standard entities with standards:
> >>>>
> >>>>RFC3261, Table 2:
> >>>>
> >>>>      Header field          where   proxy ACK BYE CAN INV OPT REG
> >>>>      ___________________________________________________________
> >>>>      Contact                 R            o   -   -   m   o   o
> >>>>
> >>>>
> >>>>I don't see an "m" under "proxy" there... but of course we're not
> >>>
> > talking
> >
> >>>>about proxy servers as such. That much said, if Contacts were
> >>>>something that
> >>>>an entity other than a user agent could safely set, there would be an
> >>>>"m" in
> >>>>the table up there. If an intermediary wants to request that it be in
> >>>
> > the
> >
> >>>>path of further SIP transactions in a dialog in a safe way, well,
> >>>
> > there's
> >
> >>>>another header for that. Furthermore, the GRUU acquisition mechanism
> >>>>inherently provides a way for intermediaries to give a Contact header
> >>>>to a
> >>>>user agent in order to strongly bind request routing to an
> >>>>intermediary. So,
> >>>>there are reasonable alternatives to rewriting the header in transit.
> >>>>
> >>>>Furthmore, I would like to point out that sip-identity provides
> >>>
> > integrity
> >
> >>>>over the addr-spec of the Contact header field. If the Contact header
> >>>>field
> >>>>has been modified by an intermediary after integrity has been applied,
> >>>
> > it
> >
> >>>>should be considered an integrity violation by the recipient.
> >>>>
> >>>>This is of course not to say that there are no architectures where
> >>>>SBCs and
> >>>>sip-identity might live together in harmony. The point is that SIP
> >>>>can't be
> >>>>expected to differentiate between friendly and unfriendly
> >>>
> > intermediaries
> >
> >>>>that break the rules, and that we certainly can't enable arbitary
> >>>>entities
> >>>>to modify the Contact header or we open ourselves up to all sorts of
> >>>>nasty
> >>>>attacks. Whatever security gains people think they are getting from
> >>>>rewriting the Contact header at an intermediary, I'm sure they pale in
> >>>>comparison to the threats that the arise if Contact header can be
> >>>>arbitarily
> >>>>changed by anyone. If we want to prevent something from rewriting a
> >>>>header
> >>>>that shouldn't be rewritten, we should use some form of integrity to
> >>>>prevent
> >>>>that.
> >>>>
> >>>>So, I do think it is reasonable for the GRUU doc to discuss the impact
> >>>>of an
> >>>>intermediary rewriting the Contact header in general (without defining
> >>>>SBCs), and point out that integrity mechanisms like sip-identity could
> >>>
> > be
> >
> >>>>used to detect a rewrite of a Contact header. But, on some level, I
> >>>>guess I
> >>>>feel rewriting Contacts at an intermediary is already acknowledged to
> >>>
> > be
> >
> >>>>problematic by the core SIP standard. It'd also be a problem for GRUU
> >>>>if an
> >>>>SBC removed the Call-ID header field, or did any of a number of things
> >>>
> > it
> >
> >>>>shouldn't do.
> >>>>
> >>>>Jon Peterson
> >>>>NeuStar, Inc.
> >>>>
> >>>>
> >>>>
> >>>>>-----Original Message-----
> >>>>>From: Paul Kyzivat [mailto:[e-mail]]
> >>>>>Sent: Thursday, September 16, 2004 4:32 PM
> >>>>>To: Jonathan Rosenberg
> >>>>>Cc: [e-mail]; Robert Sparks
> >>>>>Subject: Re: [Sip] Re: GRUU and things that rewrite contacts
> >>>>>
> >>>>
> >>>>[snip]
> >>>>
> >>>>
> >>>>>I don't want to comment on the above right now because we are clearly
> >>>>>have different assumptions here.
> >>>>>
> >>>>>I don't think we can meaningfully comment on the impact on SBCs when
> >>>>>we have no definition of such a beast. And trying to generalize to
> >>>>>all forms of B2BUA makes things worse - we repeatedly state that
> >>>>>about all you can say in general about a B2BUA is that it is two
> >>>>>connected UAs - you can't say anything about how the two calls are
> >>>>>related.
> >>>>>
> >>>>>If this is an important problem for us to mention at all, (and I'm
> >>>>>not yet convinced it is), then I think the first step is to define an
> >>>>>SBC, along with the kinds of transformations it performs. Since that
> >>>>>has never been written down, when it is written it can deal properly
> >>>>>with GRUUs.
> >>>>>
> >>>>>    Paul
> >>>>>
> >>>>
> >>>>
> >>
> >>_______________________________________________
> >>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>This list is for NEW development of the core SIP Protocol
> >>Use [e-mail] for questions on current sip
> >>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip