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

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 10 Oct 2002 15:12:44 -0400

[JPG comments in line.

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, October 02, 2002 1:47 PM
To: King, Kimberly S.
Cc: Ieprep (E-mail)
Subject: Re: [Ieprep] overall issues and REQ-11 thru REQ-15

> 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.

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.

[JPG] The gateway needs to recognize 710 as a valid prefix, and know what to
do with it (at a minimum route it to something that knows what to REALLY do
with it, such as one of the 3 GETS IXCs, or a GETS capable LEC).

> 
> 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.

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).

[JPG] Even if there is no direct relationship between the user and the
gateway, there needs to be an indirect relationship, e.g., the user has a
relationship with a database or other auth* agent, and the gateway also has
a relationship with the database or auth* agent.

[JPG] And there may be two (or more) variants of "support the priority
scheme."  One variant would be to perform the auth* and then provide the
requested special service.  Another would be to provide the requested
special service IFF the request carried a valid (trusted) indicator that it
had already been auth*ed.  In this case, a request that had not already been
auth*ed would fail.  Presumably the first  alternative is better than the
second, but the second is still better than case A.

[JPG] While it is possible that a user might need to be auth*ed twice, it is
in every one's interest to try to avoid that in setting up the business
relationship.

> 
> 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?  

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.

> 
> 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. 

[JPG] Some of the (future) variants of GETS use the instrument or line
identification as part of the auth* process, and may auth* somewhere other
than the IXC.  So it needs to be more general.

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.
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Oct 2002 16:28:30 -0400

> with it, such as one of the 3 GETS IXCs, or a GETS capable LEC).

Not necessarily. In many (smaller network) cases, the gateways are about 
as smart or dumb as a PBX, i.e., they just talk to a local PSTN switch. 
A carrier will likely have to do the routing, as you mention; the 
gateway effectively acts like a local telephone switch with rather 
peculiar line interfaces or a tandem with an IP trunk interface. In both 
cases, this is invisible to the IP side. Since we don't specify boxes, I 
don't think we need to worry about this.

> a relationship with the database or auth* agent.

Yes, typically the gateway won't do the authentication itself, 
particularly if its of the MGCP-kind. The associated SIP UA will do 
this. In that case, SIP ends on the UA, so the gateway is just a remote 
"extension" of the SIP UA.

> second, but the second is still better than case A.

A network-assigned identity extension for SIP has been specified; 
others, less dependent on trust boundaries, are in progress. I don't see 
the need for additional work here.

> than the IXC.  So it needs to be more general.

In VoIP, I don't see how "line identification" can be useful (or even 
what this should mean).