Re: [Sip] Need for RPH in SIP Responses

["Joel M. Halpern" <[e-mail]>]

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