Subject: [Sip] Need for RPH in SIP Responses

From: "Sandesara, Niranjan B" <[email-masked]>
Date: Wed, 21 Nov 2007 15:56:09 -0500

Hi!

The SIP Resource Priority Header (RPH), in its current form, is not
allowed in SIP responses.  This was a design choice during RFC 4412's
development. This is not a good choice in certain scenarios. The
Internet Draft, "Allowing SIP Resource Priority Header in SIP Responses"
(draft-polk-sip-rph-in-responses-00) describes a modification to RFC4412
to permit RPH in responses. The Internet Draft, "Requirements for SIP
Resource Priority Header in SIP Responses"
(draft-gunn-sip-req-for-rph-in-responses-00), describes one of the
requirements associated with systems using RPH, that could be easily met
by the modification of RFC 4412 to permit RPH in responses, and can not
be easily met by other methods. Additional scenarios and requirement are
described below that can be easily met if RPH is permitted in responses
per draft-polk-sip-rph-in-responses-00.

All aspects of a GETS/WPS call require priority treatment in order to
ensure that it is successfully established with priority, maintained
with adequate quality and priority, and released with priority.  RFC
3261 permits stateless servers. There are scenarios involving stateless
servers that require such servers to provide priority treatment to
GETS/WPS calls. Three scenarios are described below where inclusion of
RPH in SIP responses would enable a stateless server to provide priority
treatment.

1.	If there is congestion at a SIP server, it is important that SIP
messages (requests as well as responses) related to a GETS/WPS call are
processed with priority, and discarded last in comparison with normal
calls. Presence of RPH in SIP responses would enable a stateless server
to provide such capability.
2.	A network can mark IP packets that carry SIP messages related to
GETS/WPS calls with a specific DiffServ Code Point (DSCP). This could be
used as one mechanism to ensure that such packets receive priority
treatment in transport through an IP network. A stateless server can
mark IP packets that carry SIP responses in this manner only if it
recognizes the responses that are related to GETS/WPS calls. Presence of
RPH in SIP responses would enable a stateless server to mark packets
carrying SIP responses in this manner or other priority transport
mechanisms (e.g. MPLS path selection). 
3.	On receipt of a SIP response related to a GETS/WPS call, if a
stateless server needs to invoke other services and interact with other
servers with priority, it needs to be aware of the GETS/WPS call.
Presence of RPH in SIP responses would enable a stateless server to
provide such capability.

As described in the internet draft, "Requirements for SIP Resource
Priority Header in SIP Responses"
(draft-gunn-sip-req-for-rph-in-responses-00), GETS/WPS paradigm is
different from the MLPP paradigm. One important difference between the
two is that a GETS/WPS call request from the calling party may not
include an RPH. It is possible that SIP servers (whether stateful or
stateless) preceding the server that authenticates and authorizes a
GETS/WPS call request have RPH capability but do not have the capability
to identify the request as a GETS/WPS call request. After successful
authorization, the authenticating server will insert an RPH in all
requests it sends. In this scenario, the servers preceding the
authenticating servers would not become aware of the priority nature of
the call and would not provide any priority treatment until they receive
a SIP request with an RPH from the authenticating server.  This is not
desirable. This situation can be easily remedied if RPH is permitted in
SIP responses.

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. 

Regards,

Niranjan Sandesara

_______________________________________________
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

---

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 21 Nov 2007 22:14:08 +0100

Niranjan,

> 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

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 21 Nov 2007 16:44:23 -0500

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:[email-masked]] 
Sent: Wednesday, November 21, 2007 4:14 PM
To: Sandesara, Niranjan B
Cc: [email-masked]
Subject: Re: [Sip] Need for RPH in SIP Responses

Niranjan,

Regards,
Jeroen

---

From: Jeroen van Bemmel <[email-masked]>
Date: Wed, 21 Nov 2007 23:59:32 +0100

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

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 22 Nov 2007 13:13:29 +0100

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 

> Sent: Wednesday, November 21, 2007 11:00 PM
> To: DOLLY, MARTIN C, ATTLABS
> Cc: [email-masked]; Sandesara, Niranjan B
> 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 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...")
> 
> 2. define additional security measures to mitigate 3. 
> consider a different solution
> 
> Regards,
> Jeroen
> 
> > 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.
> >
> > 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
> >
> > 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
> >
> >   
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Nov 2007 07:28:37 -0500

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.

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 22 Nov 2007 17:43:58 +0100

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

> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Thursday, November 22, 2007 12:29 PM
> To: DRAGE, Keith (Keith)
> Cc: Jeroen van Bemmel; DOLLY, MARTIN C, ATTLABS; 
> [email-masked]; Sandesara, Niranjan B
> 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
> > 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.
> > 
> >> 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 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...")
> >>
> >> 1. ignore/accept it and generate an RFC 2. define 
> additional security 
> >> measures to mitigate 3.