Subject: RE: [Ieprep] emergency traffic

From: Fred Baker <[email-masked]>
Date: Tue, 22 Jan 2002 10:32:30 -0800

At 10:16 AM 1/22/2002, Beard, Cory wrote:
>The only option would be without authorization.  There would have to be a 
>mechanism where people could choose their own priority but would know not 
>to use a priority level they knew was inappropriate.

A better way is to have them tag their traffic with what it is ("this is an 
emergency-related call" vs "this is an emergency-management call") and let 
the service provider apply a policy ("oh, well, in that case..."). If it is 
a priority, one can expect users to set it according to their own 
perceptions ("but I really AM worried about my sister! She's pregnant and 
works on the 201st floor!"). Mixing policy and labels is pretty broken, 
because it limits you to exactly that set of policies.

>Isn't this how MLPP works?  Can't someone choose their own priority level, 
>knowing that there will be repercussions for inappropriate use?

What repercussions? If I'm not mistaken, you have to have authorization to 
present the priority, and (as you argue later in the email) the most 
repercussions you're likely to get is a 911 operator irritated with you.

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

---

From: Sean Donelan <[email-masked]>
Date: Tue, 22 Jan 2002 20:45:53 -0500 (EST)

> because it limits you to exactly that set of policies.

But before you can apply the policy, you need something the service
provider can use to distinguish the different traffic.

You can distinguish some traffic based on the source or destination,
such as 9-1-1 (or 1-1-9 or 9-9-9) calls are identified by called number.
You can also distinguish traffic based on explicit tagging, such
as TOS or Diffserv.  Or you can distinguish traffic based on
transmission path, such as MLPS or a seperate dedicated network.

Traffic flows to or from an emergency management agency are the simplest
to identify. Dynamically identifying traffic orginating from arbitrary
locations and destined for arbitrary locations as deserving special
treatment is a more complex problem.

Personally, I would like to implement the simple case first.  Learn what
breaks.  After getting the "simple" case to work, move onto the more
difficult task of dynamically identifying traffic from arbitrary  locations
needing special treatment.

And if it turns out the "special treatment" wasn't so special after all,
we haven't completely broken things.

> repercussions you're likely to get is a 911 operator irritated with you.

I visited my local government depository library a couple of weeks
ago and looked up some reports.  Virtually every report on the use of
crisis communication systems from world war II  until the gulf war (the
most recent publically released report was 10 years old) details problems
with "precedence abuse."

---

From: Fred Baker <[email-masked]>
Date: Tue, 22 Jan 2002 18:18:26 -0800

>provider can use to distinguish the different traffic.

fine; if they tag it with something the policy can trigger on, a label that 
identifies the relevant attributes, that can be used for that purpose. Note 
that a label is not a policy, though:

         "this sweater is of the kind you would give your daughter"

does not equal

         "buy this sweater".

The first is a label, like "this is traffic related to an emergency". The 
second is a policy, like "treat this with the highest priority, because it 
is related to an emergency".

My comment on MLPP is that it is an example of a policy encoded in a label, 
and makes it difficult to provide other policies. You want the label in the 
message, and the policy in the service provider.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 23 Jan 2002 15:53:51 -0600

>> >knowing that there will be repercussions for inappropriate use?

MLPP enabled networks allow users to choose which Precedence level they wish
that next call to be made at, up to the maximum level that phone is allowed to
make. MLPP is not directly user assigned, but phone assigned. The physical ISDN
port a particular phone is attached to on what is known as an End Office Switch
determines the configuration of that phone. 

In IP, that could be dynamic to the phone upon the user logging into the phone
(SmartCard) and then accessing what they individually deem appropriate. I do
realize this is a huge problem in non-closed networks like direct ISP-connected
facilities. But in Enterprise, Campus and other large finite networks (i.e.
DSN) -- I believe this can be accomplished.

Plug #1: I have an -01 version of an ID specifying this within the IP domain
published last November. It still needs work, but comments are welcome to it

Plug #2: Henning Schulzrinne and I have ID in the SIPPING WG for a new SIP
Request/Response Header for multiple namespace.level's of Resource Priority to
be contained within the INVITE's and 200 OK's for the signaling process of a
VoIP Precedence or Emergency or IEPREP type call set-up request. It with some
typo's is at the following loc (version -02 is to be published within days from
today -- which might change which version is current in the IETF Directory):
http://www.ietf.org/internet-drafts/draft-polk-sip-resource-01.txt
This ID was discussed openly (no PPT) during the BOF in SLC

>> repercussions you're likely to get is a 911 operator irritated with you.

Since it's mostly government-based in implementation, there are repercussions
that civilian or normal users don't need to adhere to.

And yes, Precedence misuse is prevalent -- so I don't recommend it's use be
assigned unchecked by users with no authorization mechanism present as to which
levels that user is able to choose from.

In this example of user's logging onto the network, a tracking mechanism for
each user shouldn't be too hard to report and be justified in usage of by that
user.

*************************************
"People generally demand more respect for their own rights than they are
willing to allow for others"

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems
2200 East President George Bush Turnpike 
Richardson, TX  75082 USA
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: Sean Donelan <[email-masked]>
Date: Wed, 23 Jan 2002 18:31:44 -0500 (EST)

> determines the configuration of that phone.

My understanding is the NCS wants the precedence to follow the user
not the device, so the user has access to the same enhanced priority
no matter which working system the user is currently near.  This was
the sticking point with Verizon giving priority to cell phones instead
of users.

This requires solving multiple hard problems, and in practice may
make the communication system more brittle.  Even the limited user
authentication used on the Internet today had problems.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 23 Jan 2002 22:13:49 -0600

At 06:31 PM 1/23/2002 -0500, Sean Donelan wrote:
>not the device, 

they do, and I do for MLPP over IP (MoIP) and IEPREP and IP enabled e911(and
the like) 

>so the user has access to the same enhanced priority
>no matter which working system the user is currently near.  

The only way to do this is with an authentication mechanism making sure the
requesting user of a higher than normal precedence call (or whatever) is who
they say they are, then an authorization mechanism making sure they access only
one of the priority levels they're allowed to.... then there's letting the
infrastructure know this in some form or fashion to get the media to behave

>This was

These *special* cell phones are/were to have an authentication chip in them
granting the privileges

>
>This requires solving multiple hard problems, 

I know.... I've been racking *me little brain* for 2+ years now on this topic.
The mobile user is the hardest problem to solve because of the trust model
necessary coupled with the response times expected.... 

:-\

>and in practice may
>make the communication system more brittle.  

Maybe.... I think something such as the SIP Resource header could solve the
signaling aspect. Now just getting something in the IP header that classifies
this traffic and its intent, across domains no less -- otherwise Diffserv
should solve it within a single IP Managed domain that's run well; and maybe
MPLS if that domain is big enough to warrant it. Within a single domain the AAA
would be much easier to solve, so would the whole trust boundary issue and the
cipher(s) and keying.

But anywhere to anywhere..... yuk!

>Even the limited user

agreed

James M. Polk
Consulting Engineer
Office of the CTO

Cisco Systems