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

[Paul Kyzivat <[e-mail]>]

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?

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

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

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

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

I have the distressing feeling that SBCs are just doing random stuff, 
which has lots of potential unintended consequences.

	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