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:jbemmel@zonnet.nl] 
> Sent: Wednesday, November 21, 2007 4:14 PM
> To: Sandesara, Niranjan B
> Cc: sip@ietf.org
> 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip