So the list discussion seem to have diverged into issues that relate to
RFC 4412 rather than the real issue under discussion. I'll work through
the issues raised I currently see them and try and get back on track to
the understanding we need to charter this. In terms of chartering, it is
not just a matter of saying to the Area Director that we need this, we
need to rationally explain a number of things including why it is
needed.
I thought I made clear in my initial mail that in my understanding there
would be no change between the namespace and priority levels of response
and the request. This needs to be more accurately specified in the draft
but certainly that was my understanding from the author, and what was
stated in IETF#69 SIP WG. No one seems to have disagreed with this from
the supporting side.
Therefore change of namespace and/or priority during a dialog would
become a separate issue for discussion in terms of RFC 4412 enhancement,
if it needed extra documentation. I tend to agree with John that using a
response is not the correct way to do this.
In terms of misuse, RFC 4412 section 1 states:
Since gaining prioritized access to resources offers opportunities to
deny service to others, it is expected that all such prioritized
calls are subject to authentication and authorization, using standard
SIP security (Section 11) or other appropriate mechanisms.
And section 4.2
2. It ascertains that the request is authorized according to local
policy to use the priority levels indicated. If the request is
not authorized, it rejects it. Examples of authorization
policies are discussed in Security Considerations (Section 11).
My understanding of the model used here is that some sort of trust model
applies. Some edge proxy determines whether the user is allowed to use a
certain level of priority (either from an included RPH or from some
other conditions), and either therefore includes or relays a RPH header.
>From that proxy onwards within the same trust area, that RPH is assumed
to be authenticated for use. If the trust are is exited, the RPH is
removed.
In terms of a valid architecture for use in responses, the one I have
certainly been considering has been the one where we have a stateful
proxy serving both the called and calling user, forming the edge of this
trust area. Other proxies providing routeing functionality between these
two edges could be stateless.
In this architecture, the originating edge proxy authorises the request
as indicated in RFC 4412. This makes its way to the terminating side. At
the terminating side either the terminating user or terminating proxy
puts the RPH in the response with the same value as in the request. If
this is performed by the terminating user, the terminating proxy checks
it (all proper walled garden stuff).
In this case, there does not seem to be any real function performed by
the need to reject a response with a 403, and it seems to be entirely
consistent with RFC 4412 section 4.7.3
SIP proxies MAY ignore the 'Resource-Priority' header field. SIP
proxies MAY reject any unauthenticated request bearing that header
field.
The stateless proxies that need the RPH header in this architecture
therefore get an authorised one, and only an authorised one. I am
assuming that stateful proxies would in anycase use the RPH from the
request - does this need to be stated?
Now whether there are other valid architectures that work could probably
be discussed in the draft if they are desired, but this seems to be the
main one, and seems to be valid, in terms of getting the information to
a stateless proxy that may need it.
But the real question I asked is that given this scenario, are there
valid things the stateless proxy can do with it. There seems to be no
dispute that for a stateless proxy it only applies to the SIP
processing, and therefore the treatment of the SIP response in
relationship to other requests and responses.
However, the only responses I have been given are of the "if its there
you have to do it" rather than "these are the reasons for doing it".
This does not lead us to a discussion which we need to have of whether
it is of benefit, might give improvements in certain circumstances, or
of no benefit whatsoever. Do we need it as a mandatory extension to RFC
4412, optional and used in some cases, or don't need the extension at
all?
If it does convey benefits, I think we also need to discuss whether the
requests and responses are placed in the same queue for each namespace,
priority level pair, or whether separate queues are needed for each.
To also explain further the linkage I made with overload control, it is
not that they form part and parcel of the same function, but rather that
in an overloaded network, we presumably see the end user seeing benefit
from RPH header usage. Do we expend more network resources on proxies
relaying responses into queues and then processing those queues, such
that the delay to the responses with RPH is greater than if we had just
proxied all responses on a first come first served basis without even
looking at the RPH issues (bearing in mind that transaction stateless
proxy processing of responses is simpler that stateful), i.e.
Response processing as described in Section 16.7 does not apply to a
proxy behaving statelessly. When a response arrives at a stateless
proxy, the proxy MUST inspect the sent-by value in the first
(topmost) Via header field value. If that address matches the proxy,
(it equals a value this proxy has inserted into previous requests)
the proxy MUST remove that header field value from the response and
forward the result to the location indicated in the next Via header
field value. The proxy MUST NOT add to, modify, or remove the
message body. Unless specified otherwise, the proxy MUST NOT remove
any other header field values. If the address does not match the
proxy, the message MUST be silently discarded.
Any modelling out there to prove one thing or the other.
Independently of getting these answered, I think there is value in the
author revising the draft to make the usage scenarios clearer.
Regards
Keith
________________________________
From: Elwell, John [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 25, 2007 7:30 AM
To: Janet P Gunn; Dean Willis
Cc: [email protected]; DRAGE, Keith (Keith)
Subject: RE: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
Janet,
If there really is a need for the callee to jack up the priority
of a dialog (I don't have a view on that), then a mechanism similar to
connected-identity should be used, i.e., a mid-dialog request in the
reverse direction, which can therefore be challenged and authenticated
in the normal manner.
John
________________________________
From: Janet P Gunn [mailto:[EMAIL PROTECTED]
Sent: 24 September 2007 19:20
To: Dean Willis
Cc: [email protected]; DRAGE, Keith (Keith)
Subject: Re: [Sip] Progression of
draft-polk-sip-rph-in-responses-00
Those are valid concerns. I said that I was
oversimplifying, and some of the oversimplification involves mechanisms
to addresses some of those concerns.
But we DO need to allow the situation where the first
"hop" of a "priority" call does not have RPH, but RPH is added for later
hops.
Janet
Dean Willis <[EMAIL PROTECTED]> wrote on
09/24/2007 01:12:49 PM:
> Janet P Gunn wrote:
> > Jeroen van Bemmel <[EMAIL PROTECTED]> wrote on
09/21/2007 03:19:09 PM:
> >
> >> Tim, Brian,
> >>
> >> First of all a question to clarify the requirements
further: is it
> >> possible/valid for the request to have no specific
priority while its
> >> response does, or should the RPH headers in a
response always be the
> >> same or a subset of those in the request (i.e.
copied)? I assume the
> > latter
> > No, not a valid assumption.
> >
> > In order to support legacy applications, priority
markings (e.g. RPH) may
> > be set based on the "dialed number"- e.g., by
parsing the Request URI.
> >
> > In some architectures (e.g. IMS) there may be
RPH-capable SIP actors (Type
> > A) which do not parse the Request URI looking for
the key strings. Such a
> > SIP actor would send a SIP Invite WITHOUT RPH.
However, a subsequent
> > RPH-capable SIP actor (which DOES parse the Request
URI looking for the
> > key strings) (Type B) would set RPH, both in Invites
sent forward, and in
> > responses sent back.
> >
> > So the "Type A" SIP actor could send out an Invite
without RPH, but get
> > back a response WITH RPH.
> >
> > I have oversimplified, but the point is that it is
not a valid assumption.
> >
>
> Ok, so what keeps me as a Joe End User from putting a
"higher priority
> than the president" marking on every response I send?
You can't
> challenge a response or send me an error code if you
don't like my
> priority. Does every response require authentication
of priority level?
>
> Do we also have a new requirement for a node to
"learn" the priority
> level of a dialog from a response, and then include
that priority level
> in future requests on that dialog?
>
> It seems like this mechanism could be used to "jack
up" the priority
> level of a dialog:
>
> 1) Alice sends a low priority request to Bob.
> 2) Bob replies with a high-priority marking in the
response.
> 3) Alice marks all future requests and responses in
this dialog high
> priority.
>
> --
> Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
