RE: [Sip] Need for RPH in SIP Responses

["DRAGE, Keith \(Keith\)" <[e-mail]>]

Just to be clear, I personally was not arguing against the use cases.

I was pointing out that issues were being raised in discussing RPH in responses that were nothing to do with the new use cases, but appeared to be equally issues with RPH in requests.

Such discussion is an issue with RFC 4412, not an issue with either author draft, and should be discussed, but on a different thread. 

Regards

Keith

> -----Original Message-----
> From: Joel M. Halpern [mailto:[e-mail]] 
> Sent: Thursday, November 22, 2007 12:29 PM
> To: DRAGE, Keith (Keith)
> Cc: Jeroen van Bemmel; DOLLY, MARTIN C, ATTLABS; 
> [e-mail]; Sandesara, Niranjan B
> Subject: Re: [Sip] Need for RPH in SIP Responses
> 
> As I read the documents, there is a real point that prompts 
> the need for RPH in responses.  This has nothing to do with 
> stateless proxies.
> Rather, it has to do with the case where the device assigning 
> the RPH is upstream of a device that needs to make use of the 
> information.
> 
> That situation seems to be quite reasonable, does not require 
> a B2BUA, and can be reasonably recognized and acted upon in a 
> number of different network topologies.
> 
> However, some of the discussion has raised questions that do 
> need to be clarified in the document which actually defines 
> the extension.  Issues such as whether a response can have a 
> lower priority in its RPH than a request, appropriately 
> trusting / using the RPH in the response, etc.
> It appears to me that part of the confusion about those 
> issues is that there are related issues (such as the scope of 
> the RPH, and changes during a dialog) that apply to the 
> original document and are not well specified.
> 
> Yours,
> Joel M. Halpern
> 
> PS: In addition to the fact that the basic problem described 
> in the I-D does not depend upon the stateless / stateful 
> nature of the proxy, the reason I avoid the stateless proxy 
> aspect is that I doubt very much that an RPH in a response 
> will noticeably affect the actual response processing if no 
> other steps were taken before one got to parsing
> sufficient header to get to that.   Until this upstream 
> notification was
> brought forward, I was doubtful about the use of the header 
> in this fashion.
> 
> DRAGE, Keith (Keith) wrote:
> > Again, I would like to understand whether there is a 
> specific issue with regard to RPH in responses, or whether 
> this is a discussion of a failing of RFC 4412 as published 
> for requests.
> > 
> > I am not seeing a point here that relations specifically to 
> RPH in responses.
> > 
> > Regards
> > 
> > Keith
> > 
> >> -----Original Message-----
> >> From: Jeroen van Bemmel [mailto:[e-mail]]
> >> Sent: Wednesday, November 21, 2007 11:00 PM
> >> To: DOLLY, MARTIN C, ATTLABS
> >> Cc: [e-mail]; Sandesara, Niranjan B
> >> Subject: Re: [Sip] Need for RPH in SIP Responses
> >>
> >> Martin,
> >>
> >> It appears we have a different view on what constitutes 
> the Internet 
> >> - perhaps because I am not from the US. In any case, I was 
> referring 
> >> to the Internet as a whole, exactly as in RFC3455:
> >>
> >> The SIP extensions specified in this document make certain
> >>    assumptions regarding network topology, linkage between SIP and 
> >> lower
> >>    layers, and the availability of transitive trust.  These 
> >> assumptions
> >>    are generally NOT APPLICABLE in the Internet as a whole.
> >>
> >> The proposed mechanism is only secure under assumptions 
> that do not 
> >> hold in the Internet as a whole. It is not only a minor 
> change from 
> >> the current RPH usage, as 
> draft-polk-sip-rph-in-responses-00 tries to 
> >> say ("The only new security threat...")
> >>
> >> To me, there are 3 things that could happen:
> >> 1. ignore/accept it and generate an RFC 2. define 
> additional security 
> >> measures to mitigate 3.
> >> consider a different solution
> >>
> >> Regards,
> >> Jeroen
> >>
> >> DOLLY, MARTIN C, ATTLABS wrote:
> >>> Jeroen,
> >>>
> >>> It does apply to a concatenation of managed networks, lets say 
> >>> UE-AT&T-Verizon-UE...Oh, this is the same concatenation for
> >> what you
> >>> are referring to as the "internet"..right? Only difference is a 
> >>> different portion of our IP backbones.
> >>>
> >>> More important here (please just don't cut/paste the 
> above without 
> >>> this), for wireless access the user's priority level may
> >> change based
> >>> on call processing, including authentication, and this 
> needs to be 
> >>> relayed back to the wireless access.
> >>>
> >>> Cheers,
> >>>
> >>> Martin
> >>>
> >>> -----Original Message-----
> >>> From: Jeroen van Bemmel [mailto:[e-mail]]
> >>> Sent: Wednesday, November 21, 2007 4:14 PM
> >>> To: Sandesara, Niranjan B
> >>> Cc: [e-mail]
> >>> Subject: Re: [Sip] Need for RPH in SIP Responses
> >>>
> >>> Niranjan,
> >>>
> >>>   
> >>>> As has been pointed out earlier, possible security risk of
> >> permitting
> >>>> RPH in SIP responses is minimal in managed IP networks 
> where this 
> >>>> capability is generally expected to be used.
> >>>>
> >>>>     
> >>> For this argument to apply, the element sending the RPH 
> header in a 
> >>> response and the element acting on it should both be in the
> >> same domain.
> >>> In other words you are talking about a closed system, a
> >> very specific
> >>> environment. The use of this header in this way then
> >> clearly does not
> >>> apply to the Internet; the proper way to standardize this is as a 
> >>> P-header (instead of taking a header which is already 
> defined in a 
> >>> "approved-for-the-Internet" RFC, and modifying its allowed use to 
> >>> accommodate for a non-Internet use)
> >>>
> >>> Regards,
> >>> Jeroen
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> > 
> > 
> > _______________________________________________
> > 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