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

From: Cullen Jennings <[email-masked]>
Date: Sat, 06 Nov 2004 14:37:18 -0800

I was playing with a SBC from one of my favorite SBC vendors and don't see
why GRUU will cause lots problems. They do muck with contact but they do it
in a stateless and can pass instance and grid parameters right thought. They
know how to map changes done in outgoing contact and apply them to an
incoming request URI.

Yes, SBC will need to be GRU aware, or already be transparent to this type
of thing, but I guess I'm not seeing the issue.

On 9/21/04 12:13 AM, "Jonathan Rosenberg" <[email-masked]> 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:[email-masked]]
>>> Sent: Thursday, September 16, 2004 4:32 PM
>>> To: Jonathan Rosenberg
>>> Cc: [email-masked]; 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip