Subject: [Ieprep] overall issues and REQ-11 thru REQ-15

From: "King, Kimberly S." <[email-masked]>
Date: Wed, 2 Oct 2002 11:29:05 -0400

First, some overall issues:  
 
High-level Question:

What involvement is needed by the local IP network or SIP carrier
for the user to make use of a gateway's ability to invoke GETS, MLPP or some
other service on the CSN?

GETS Example:  User wishes to place GETS call from SIP phone to a phone in
the CSN (via a gateway).

CASE A:  The gateway doesn't support the priority scheme.  It sure might be
nice if it understood that 710 was a valid area code and routed this to the
CSN for authorization and preferential treatment in the CSN using GETS.  The
IP network or SIP carrier may have no particular relationship with the user.

CASE B:  The gateway does support the priority scheme.  At that point, it is
a matter of policy, if the gateway and user do some exchange
authentication/authorization and gives the user preferential access to a
gateway port.  Then the 710 call is routed to the CSN.  The IP network or
SIP carrier may have no particular relationship with the user.

CASE C:  The gateway supports the priority scheme and the IP network or SIP
carrier also have a business relationship with the user (or GETS service).
In this case, the authentication/authorization could potentially be for the
entire GETS service.  Not only is the user authorized for (perhaps
preferential) use of the gateway, the user is authorized for the full GETS
system and a true destination is entered by the gateway (i.e., perhaps the
user really wanted to call 202-555-1212).  In this case, there are some
pretty explicit relationships assumed.  

So, what are we talking about?  

Maybe it is best left ambiguous since the schemes I've heard voiced here use
different techniques.  The circuit-switched landline GETS model
authenticates in the PSTN (at particular IXCs) after the user dials the 710
"area code".  However, the traditional circuit-switched MLPP and GTPS
systems have their authentication built in based upon the physical line.   

When moving MLPP to an IP environment (a.k.a. Assured Service) then it
appears
http://www.ietf.org/internet-drafts/draft-pierce-sipping-assured-service-02.
txt

 "It must be possible to verify that the calling party is authorized to
   use the Assured Service and the requested precedence level value and
   to take the appropriate action if the calling party attempts to use a
   higher level."  
The network operator and the assured service user seem to have a known
established relationship.  It is my understanding (and I could be wrong)
that Assured Service is to be deployed on a priviate network where the local
IP networks and SIP carrier have an known relationship with the user.

Do the requirements assume any underlying relationship between the local IP
network or SIP carrier and the user?  Should they? 

Onward...the remaining requirements

        REQ-11: Identity-independent: The user identity is insufficient
             to identify the priority level of the request. The same
             identity can issue non-prioritized requests as well as
             prioritized ones, with the range of priorities determined
             by the job function of the caller. The choice of the
             priority is made based on human judgement, following a set
             of general rules that are likely to be applied by analogy
             rather than precise mapping of each condition. For example,
             a particular circumstance may be considered similarly grave
             compared to one which is listed explicitly.

Comment:  I think we are in new territory here.  With MLPP, certain lines
are provisioned to be able to make calls at a prescribed level(s).  With
traditional landline circuit-switched GETS, the user identity (+ PIN) is
sufficient to identify the priority of the call.  In the U.K's Government
Telephone Preference Scheme, lines are divided into classes to determine
what lines get to place outgoing calls.  So, I presume REQ-11 is directed
solely at the Topology B--IP at the Start?

        REQ-12: Independent of network location: While some existing
             schemes restrict the set of priorities based on the line
             identity, it is recognized that future schemes should be
             flexible enough to avoid such reliance. Instead, a
             combination of authenticated user identity, user choice and
             policy determines the request treatment.

        REQ-13: Multiple simultaneous schemes: Some user agents will
             need to support multiple different priority schemes, as
             several will remain in use in networks run by different
             agencies and operators. (Not all user agents will have the
             means of authorizing callers using different schemes, and
             thus may be configured at run-time to only recognize
             certain namespaces.)

        REQ-14: Discovery: A terminal should be able to discover which
             priority name spaces are supported by a network element.
             Discovery may be explicit, where a user agent requests a
             list of the supported name spaces or it may be implicit,
             where it attempts to use a particular name space and is
             then told that this name space is not supported.

If I understood Henning's email Re: [Ieprep] IEPREP SIP  REQ-10 (w/14), this
requirement request default treatment of network elements not supporting the
proposed mechanism and gives some options (no not OPTIONS) for appropriate
responses from those that do.

 "(Methods would be requested via OPTIONS and returned in Allow, but that's
not likely to be applicable in our application.) All SIP systems have to
support this mechanism today, as it is the foundation of the feature
negotiation mechanism."

        REQ-15: Testing: It must be possible to test the system outside
             of emergency conditions, to increase the chances that all
             elements work during an actual emergency. In particular,
             critical elements such as indication, authentication,
             authorization and call routing must be testable.

I suspect what is really being requested is that the mechanism isn't
something that is switched on only during emergencies but rather something
that is always available if requested (and hence can be tested outside of
emergency situations).

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

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 02 Oct 2002 17:07:06 +0100

> IP network or SIP carrier may have no particular relationship with the user.

the 710 number and whatever services associated with it are two different
and cascading items.  710 should be recognized by all LECs, CLECs, etc
within the US.  additional high probability of completion (HPC) services 
is in addition to that and may exist depending on the service contracted
by the customer (ie, US govt).

> network or SIP carrier and the user?  Should they? 

which "requirements" are you referring to?  I ask because you talk of
MLPP and the Pierce draft (which imo is presented more in terms of
describing a service, and not really a set of requirements) as well
as Henning's draft.

If you are referringto Hennings draft, than in my opinion, the answer
to your question should be no because Henning's draft is very narrow
in scope and only aims at SIP, not what's underneath it.

-ken

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Oct 2002 13:47:04 -0400

> IP network or SIP carrier may have no particular relationship with the user.

This seems to be purely a configuration issue, requiring no further 
protocol work. The gateway would treat the SIP phone like a somewhat odd 
telephone extension, with the usual DTMF-based authorization.

> SIP carrier may have no particular relationship with the user.

I'm not sure if you consider "SIP network" = "gateway", but in any 
event, auth* would require some relationship to the user. Hard to 
authenticate somebody you haven't met, if indirectly (via some cert).

> So, what are we talking about?  

A is not interesting (no SIP protocol features involved); both B and C 
could happen, but, again, from a protocol perspective, I don't see why 
it matters. in case B, the user may have to authenticate twice, both via 
some challenge/response and DTMF, but that's a user interface issue.

> systems have their authentication built in based upon the physical line.   

Also, this strongly depends on the trust relationship between the 
various parties. I don't think that's something we want to get into, as 
it appears to be largely an operational issue.

> network or SIP carrier and the user?  Should they? 

No, I don't think they do (or should). I'm wary of attempting to write 
down all permutations and network configurations. Generally, the IETF 
seems to want to stay away from "business models" and network 
configurations and stick to things that are necessary for 
interoperation. I think your discussion and taxonomy is useful, just not 
something I would want to have to expand into an RFC...

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Oct 2002 14:03:07 -0400

> solely at the Topology B--IP at the Start?

I suppose this depends on what you mean by 'user identity'. At the 
user-level, the GETS user still has the same identity (name, SSN, 
telephone number) whether placing a GETS call or not. You could view the 
GETS id+pin as another identity or as a credential for the same person, 
since the id+pin are (I would guess) not meant to be shared by several 
people.

SIP makes the problem a bit more interesting since you have at least 
three identifiers:

- your IP address
- your From SIP URI
- your authentication ID (Digest user name)

You may have more with network-asserted IDs. Yes, this makes sense only 
in an IP-originated scenario, unless the gateway from the CSN 
effectively emulates a user (e.g., queries user via some kind of IVR 
system and then inserts this information into the SIP request).

Also, as we discussed in other venues, I think it would be very useful 
if one could separate the notion of identity from privilege.

> that is always available if requested (and hence can be tested outside of

Noted.