Subject: Re: [Ieprep] Resource priority header

From: [email-masked]
Date: Wed, 22 May 2002 14:36:19 EDT

In a message dated 5/22/02 9:48:55 AM Eastern Daylight Time, 
[email-masked] writes:

> On Tuesday, May 21, 2002, at 07:57 , [email-masked] wrote:
> 
> > To all,
> >
> > Following the discussion in the interim meeting, I would offer the 
> > following ideas for the Resource-priority header:
> 
> While protocol design can be amusing to some, I don't think that is
> within the charter for IEprep.  Of course the chair can correct me
> if he thinks I'm confused...
> 
> Ran
> 

Yes, I would be the first to agree that much of what I wrote is protocol 
design and doesn't belong in IEPREP, but we've had a Catch-22 here. Proposals 
in SIP for detailed protocol are bounced (correctly) to SIPPING due to lack 
of requirements, and attempts to define requirements in SIPPING for the 
Resource-priority header migrated to IEPREP to add their part, and discussion 
in IEPREP turned to details of levels required and functionality which can 
only be clearly defined by the details to be added to the Resource-priority 
header (which is protocol). I would say that those who want to concentrate on 
high-level functionality or requirements should ignore the protocol details 
in my e-mail. Although I agree it's "protocol", the details I propose for a 
new Annex C are a way to work toward an agreement on the high level stuff too 
(like number of levels).

Just think of my original e-mail as being sent to SIP, SIPPING, and IEPREP 
for people in each to consider the part they are interested in. But knowing 
that most everyone that is interested in this subject is one all three e-mail 
lists, it is only sent on one to save wear-and-tear on your Delete key.

And yes, as someone else commented, a lot of the IEPREP meeting was spent 
talking about this same type of thing.

Mike

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 22 May 2002 21:37:08 +0100

> that most everyone that is interested in this subject is one all three
> e-mail lists, it is only sent on one to save wear-and-tear on your Delete 
> key. 

actually, I'd appreciate it if next time you would cross-post with SIPPING
*and* this list.  my agreement with Ran stemmed from a concern that an 
extensive discussion on a *formal* proposed change/augmentation to 
something
like the R-P draft will carry on here and SIPPING will be left out.

i can always delete a duplicate.  i can't always assume that the right
people are on both lists.

on the other points, I'm not in quite agreement with Ran, but I won't
duplicate the points that others have already made.

regards,

-ken

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Allison Mankin <[email-masked]>
Date: Wed, 22 May 2002 20:04:21 -0400

Speaking as the AD for SIP and SIPPING, I request that there not be
cross-posting to SIPPING now.  And IEPREP should be disciplined and defer
further discussions of the R-P header mechanism.  It needs instead to
establish rough consensus that the requirements to which R-P is aimed
are the right ones.  That discussion did not occur Monday; the WG has
not made Henning's document a working group document, and a number of the
underlying requirements haven't been roughly resolved (I observed on Mon).

Given rough consensus requirements from IEPREP, SIPPING chairs and I
think that the SIPPING WG will work from them.  Again a goal is to have
a disciplined discourse, and now SIP-oriented discipline is added:

- How do the requirements trade off against requirements of SIP
  architecture?  For instance, the power to express and register
  priority namespaces is a major tradeoff against SIP concerns that
  extensibility can lead to implementation complexity, insecurity, and
  lack of interoperability. Coupling of a SIP feature to functions 
  outside of SIP such as resource management is a major tradeoff against 
  modularity.

- Is SIP the right protocol to accomplish all the functions identified
  by the requirements?  Or just some of them, and others need to be met
  in another way?

- Is it an appropriate feature in SIP architecture for a call request for
  one call to delay other arriving requests?  To cause ongoing calls to 
  be terminated?

- Are SIP features to meet the requirements securable for the big-I
  Internet?  (Authorizing, authenticating, maintaining
  integrity for a service with very strong access control needs).

Without answers to questions like these, I don't see how R-P 
standardization can "follow hot on the heels of the
requirements draft," to paraphrase a couple of the messages today.

Allison

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 May 2002 20:49:49 -0400

Good questions; let me start the discussion.

>   lack of interoperability. 

The problem is probably somewhat similar to having multiple media types 
- the more you have, the more negotiation you get. I don't think there's 
a bright line, but I do think that fewer is better. On the other hand, 
we do, I believe, have the right requirements that are similar to media 
types and other name spaces:

- reasonable default behavior (don't make the call fail unless you 
really, really have to)

- discovery capability (be able to find out what the other side understands)

Another analogy is caller preferences, btw.

>   Coupling of a SIP feature to functions 

We already do this each time we reach a PSTN gateway. The gateway needs 
to make choices, given resource limits, whose call it drops, delays or 
takes. Even doing FCFS is a policy decision, with its own implications. 
(As for packet queueing, retry behavior, for example, may make this 
particular one a bad choice.) The R-P mechanism is just a policy input, 
in addition to other SIP information, including inter alia, my strength 
of authentication, my identity and associated AAA information, the 
destination (e.g., 'sos' vs. 1-900-your-future --- obviously, the latter 
wins, since it produces more revenue for the carrier) or a P-Bribe header.

>   by the requirements?  Or just some of them, and others need to be met

I really see only one function: provide policy input to the gateway on 
how to handle this session.

>   one call to delay other arriving requests?  To cause ongoing calls to 

The action is a policy decision. SIP calls can already cause all of the 
actions you describe, based on other information in the SIP request. 
This just provides a more semantically distinct way of expressing user 
desires, as opposed to overloading other information. ("It's Bill 
Clinton calling, so it must be high priority, even if the address is 
[email-masked]")

>   integrity for a service with very strong access control needs).

Again, this is not fundamentally different from securing any other input 
into policy mechanisms. As usual, the receiver of a message has to make 
policy decisions that weigh potential cost of erroneous prioritization 
either way. This requirement is fairly similar to, for example, 
(trusted-third-party or first-party) caller identification that is used 
to rouse somebody from sleep.

I do see a requirement that any prioritization information be tightly 
bound to a message, so that cut-and-paste attacks aren't possible. An 
attacker shouldn't, for example, be able to "upgrade" the discussions of 
the cooks discussing KP duty over "we will bomb Russia in 5 minutes" 
calls. (Oops, maybe they should in that case.)

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 23 May 2002 11:40:13 +0100

without duplicating Henning's earlier comments, I'll just reiterate
that the R-P header mechanism is just a means of conveying labels.
And thats a requirement that we have as originally discussed in
Baker's draft, and an objective stated in the Carlberg draft.

Policy determines the actions to be taken on those labels.  This 
separation of policy and label has been discussed in the IEPREP list 
and WG/BoFs, and the position has been heavily endorsed by the chair.  
Perhaps I'm mistaken, but my concern is that some of the items you 
raise seem to deveat from this position.

on a different note..

>   one call to delay other arriving requests?  To cause ongoing calls to 

so while I'm agnostic as to whether such types of actions should be done,
I am concerned if one prevents SIP from just conveying information that
could trigger such action (either within IP telephony, or in the PSTN).

-ken

---

From: Allison Mankin <[email-masked]>
Date: Thu, 23 May 2002 09:56:08 -0400

Ken,

> Baker's draft, and an objective stated in the Carlberg draft.

It is very easy to say about strings in SIP that they are labels for
some external module, but someone has to evaluate the impact of
of such a design for SIP processing. Notable here is that there is a
strong impact on the security handling of a SIP message carrying one
of these - the requirements for authentication and integrity are
especially difficult since it seems likely that intermediaries need to 
be able to modify or add these labels.

There is also an impact on interoperability handling.  I didn't
say it this way in my other message, but there are major tradeoffs
(aka inherent conflicts) in the direction being discussed that 
SIP and IP telephony entities invoke some local default policy for
any label they receive that they don't understand.  It's hard to see
how this squares in the Internet/heterogeneous deployment world with
the IEPREP fundamental requirement of high probability of successful
calling.  If the real tradeoff is that SIP implementations actually
need to understand the majority of labels, then there's impact
on SIP processing, in my opinion.

> and WG/BoFs, and the position has been heavily endorsed by the chair.  

It's a classic separation to use, but I think it has allowed some
of the hard issues to be placed under a Hitchhiker's Guide-style
Someone Else's Problem Field.

> raise seem to deveat from this position.

If the label has impact on the protocol carrying it, as I've
argued above, then the items are not deviant (though it might be
more fun be deviant...) - anyway, what I wrote were questions to be
discussed...

> could trigger such action (either within IP telephony, or in the PSTN).

Only if the "just conveying" has a really good security and
authorization story.

Finally, your last sentence raises my antennae about a different
distinction:  the function of conveying the information from a SIP
phone to a PSTN gateway for use in the PSTN, and the function of
bridging the information between PSTN gateways across the SIP/IP
net, are easier to engineer and secure than the functions in which
the information invokes functions in the SIP/IP net.  I just spoke
with Scott about this and he agreed that guidance to the group
to keep them well distinguished (which he has given) may mean the
working group should consider motivating distinct solutions.

Allison

---

From: Fred Baker <[email-masked]>
Date: Thu, 23 May 2002 07:57:42 -0700

Maybe we need to raise the level of this conversation. We seem to be 
focused pretty heavily on specifying a question for the RP draft to be an 
answer to (which ignores H.323 and so on). May I attempt to rephrase the 
question without presuming the answer?

It seems that the fundamental issue is that during certain circumstances 
there is a need to ensure that individuals that have been given specific 
responsibility and authority to act for the good of the community can 
communicate. These include certain government officials, folks responsible 
for critical communication infrastructure, those who would organize 
appropriate responses to mass injury or destruction, etc. In order to 
accomplish that, policies must be put in place to identify such 
individuals, verify that communications which claim that privilege are in 
fact authentically authorized to use it, and ensure that the speed and 
accuracy of those communications is not unnecessarily impeded. That fact is 
fundamental to the charter of this working group.

In order to accomplish that, there must be mechanisms in the signaling 
protocols that apply to communications that allow for this type of policy 
to be identified, claimed, and acted out. These include at minimum SIP, 
H.323, and H.248; it may well also apply to other signaling protocols, and 
may apply at other communication layers to non-signalled traffic.

The specifics of such a policy are not the province of this working group, 
or of the IETF in general. However, any such policy which is in active use 
and which is agreed to by appropriate policy bodies should be representable 
in the mechanism we define. If this is not so, the failure is not on the 
part of the policy, it is on the part of the mechanism.

 From my perspective, the policy belongs to the policy-maker; the language 
that defines it is non-technical, and should neither attempt nor be 
construed to color the technical implementation of it. If we can come up 
with one set of labels that adequately describes all potential policies, 
this is good. If we cannot (and it seems to me to be a difficult thing, 
given the possible range of "all potential policies"), then we need to be 
able to identify both the policy and the claims being made under it.

The authentication and authorization mechanisms appropriate are often set 
by the policy itself; the relevant technical issues in that area include 
ensuring that mechanisms exist to authenticate and authorize the claims 
under the policy, giving guidance as to what technical mechanisms may be 
appropriate or inappropriate, and ensuring that any appropriate mechanism 
can be encoded in the mechanism provided.

The specific set of policies in view here are those used by the US and UK, 
and which have made their way into existing telephony standards. Other 
policies are also possible.

Once such a mechanism exists, it is also usable by non-emergency-related 
policies as well, such as the one used by the US military and NATO countries.

---

From: Ken Carlberg <[email-masked]>
Date: Thu, 23 May 2002 16:36:27 +0100

Hi Allison,

> be able to modify or add these labels.

yes, we are in agreement with the importance of authentication and
authorization.  I'm not sure about the likelyhood of intermediaries
modifying/adding these labels, but it is interesting headache to
ponder.

I'm uncertain though if you're asking for an additional security
companion document to go with the R-P draft, or an extended discussion
in the security section of the R-P draft.  and if the former, is there
something that Ian Brown needs to add to his security document, or was
there something else you had in mind?

> on SIP processing, in my opinion.

ok, I would add some clarification on IEPREP's part by saying that the
"high probability of successful calling" is only within the realm of
those SIP entities that support the R-P header and the NameSpace that
triggers it.  so, im my view its not a case of all SIP implementations 
understanding the majority of labels/namespaces that have been defined.  
as an example, not all carriers in the US support the NS/EP code point
for GETS service, but those that do are ones that have been contracted 
via an SLA and support the high probability of completion.  

> more fun be deviant...) - anyway, what I wrote were questions to be

yes, agreed.  they're good discussion points.  

> the information invokes functions in the SIP/IP net.  I just spoke

agreed.  we made this distinction in the framework document and viewed
it in part as both 'low hanging fruit' and as something we'll probably
see supported in the near term by vendors.   

> working group should consider motivating distinct solutions.

ok.  something to give thought to.

-ken