[Ieprep] Re: draft-polk-ieprep-scenarios-00.txt

At 12:03 PM 9/20/2002 -0400, King, Kimberly  S. wrote:
>Hi James,
>
>Comments on draft-polk-ieprep-scenarios-00.txt...
>
>"2.0 Overview of IEPREP
>
>IEPREP is an international mechanism for signaling preferential treatments
>of communications used by only a select few of our population."

Fair comment. I thought about *not* having an IEPREP overview statement
because it's liable to change or cause some to question it.

>
>IEPREP isn't limited to signaling nor IP telephony.  So, the title of the
>document "IEPREP Topology Scenarios" doesn't convey your limited scope of IP
>telephony.  

I don't understand what you are saying here. Because IEPREP isn't limited
to VoIP or signaling, I have a bad title?

>I have concluded that IP telephony is the scope you are
>considering by statements even in the pure IP scenario that indicate "call"
>and example protocols of SIP and MEGACO.  

SIP and MEGACO are multimedia protocols - so they're not only voice. I also
state in a single sentence/paragraph in the introduction that SIP and
MEGACO will not be discussed - and aren't again. 

	"This memo attempts to be agnostic with regard to IP signaling or control 
	protocols (SIP, MEGACO, etc)."

I could have mentioned IM/SIMPLE and SMTP to cover 90% of what IEPREP will
cover.... should I restate to include both to be clearer?

>In addition, you aren't just
>providing scenarios but also mixing comments about when
>authentication/authorization could/should occur.  

Not "when", but "where". The "where" will have significant signaling
impact, and could justify Topologies B2 and C2 in which "IP at the Start"
has A&A in the IP part in B2, and B1 has A&A in the CSN. As well, C2 "IP at
the End" has A&A in the IP part, and C1 has A&A in the CSN. 

I thought about merely having this ID be purely a naming convention ID for
Topologies, then I added text for Topologies B & C for where A&A will be
supposing that could adjust the number of topologies up to 6 from 4. I am
looking for list comments to decide which direction to go, as well as
direction from the chairs and AD. 

Text can easily be removed or adjusted, but non-present text is hard to
comment on.

>
>
>
>
>"3.1 Topology A û IP in the Middle
>
>Otherwise known as IP Bridging two CSNs. In this topology, a CSN phone of
>any type makes a call to another CSN phone with an IP core between the two
>CSNs. This topology should behave as the GETS (in the US) or GTPS (in the
>UK) service behaves today, any IP section in the call path should be for
>transport only, though should convey the appropriate signaling for IEPREP or
>ETS behaviors within the packets (defined elsewhere)."
>
>What do you mean by "should convey the appropriate signaling for IEPREP or
>ETS behaviors within the packets (defined elsewhere)"?  

This is a Voice example because I directly speak to GETS and GTPS. 

I "mean" that today's infrastructure could traverse IP transit networks and
that transition requires GETS behaviors be conveyed through the IP portion
of Top A. How is CPC conveyed today in this situation? What about the Prec
field (it's optional but could become mandatory for GETS/ETS/IEPREP across
IP networks regardless of where the IP is within the communications path)?
I don't raise these questions in the ID, but believe they should be raised
somewhere else, perhaps because of reviewing this ID

>Are you asserting a
>requirement on the topology?  

I know there is a requirement - and thought about not stating it here, but
implied it and a few others to cause comments and maybe each be stated
somewhere else now.

>Are you saying that CSN signaling should be
>preserved

The behavior of whatever is authorized must be

>, say by encapsulation, 

Encapsulation means the IP portion of the network cannot at all react in
any way to what is only in the encapsulated part. I'm advocating the IP
portion of the signal path behave according to the contents of the set-up
message (this includes perhaps the signaling itself receiving differential
treatment), but I'm only implying it here, not stating it.

>or are you indicating some sort of
>preferential treatment in the IP network should occur?

I'm implying it because I believe it should, but I don't state it here
because this ID shouldn't state it here.

>
>
>
>"3.2 Topology B û IP at the Start
>...If the caller is authorized to perform some form of preferential
>treatment with that call, the CSN needs a mechanism to convey that
>authorization back to the caller's device in such a way that the IP network
>will understand."
>
>Your statement is referring to authorization within a CSN and it implies
>that the IP network needs to understand that the CSN has
>authorized the call.  

Couldn't the GW to the CSN be experiencing congestion that some form of HPC
would be one appropriate mechanism of use in a GETS/IEPREP/ETS scenario? If
so, then the caller's IP signaling likely needs some flag or auth token or
asserted identity that the GW will recognize and react accordingly - plus
the eventual outbound GW might not be the initial one signaled to (or won't
be with a Signaling GW)

>Presumably you need this so as to provide some
>preferential treatment in the IP network?  

Perhaps only the GW, perhaps some other marking. This is an early ID in
this WG, once this idea is fleshed out and stated somewhere else, it can
move to that ID(s)

>Unless I miss my guess, access to
>a port on a gateway is a place where real contention for resources could
>occur.  But the above idea of "authorization occurs in the CSN" presumes
>you've already been granted this resource.  

I'm in my Cisco office with only a Cisco IP Telephony infrastructure. If a
GETS authorizable user is visiting me, and wants to make a GETS call from
my office phone, s/he calls the 710 area code and enters a PIN#
authenticating/authorizing that call for HPC, does the IP-CSN GW know about
it or not? IEPREP ought to be working towards making sure that it can. But
something from that signaling to the CSN should be conveyed back to IP
network in the case where the IP network has another GW for 710 calls, or
the signaling path is separate from the media path. This example gets more
complex in the case where my company's network connects to an IP Telephony
Provider and not a CSN provider. At that point, a redirection is more
likely to occur

>To provide any preferential
>treatment on a gateway without first authorizing in an IP network is a setup
>for security problems.   

That person in my office dialing 710, are they authenticating twice (once
in IP and once in CSN)? That's asking for failure and much more complexity.
If there is a redirect to a new GW with congestion, the authorization token
returned by the original signaling could be placed in the IP signal packet
to the new GW to convey over the D channel of a PRI requesting HPC on the
Class 5 over that PRI (the Class 5 couldn't realistically learn any other
way I believe)

>Are you making requirements of the topology and the
>CSN?

This is not a requirements ID, but does state some things to consider. The
text can be removed, but the requirements implied shouldn't go away.

>
>Is "Topology B : IP at the Start" assumed to be a carrier that has deployed
>VoIP or could this be an enterprise?  

As stated above, either/both

>For example, if a business has an
>IP-PBX and a local gateway with say a PRI into the CSN's end office, is this
>"IP at the start"?  

SIP doesn't have IP-PBXs. 

I wasn't clear on where IP is in my ID. I've had a few comments already to
this effect, so I'll be clearer in the next version of my ID prior to
Atlanta. For now, my ID is exploring the general (if simplistic) network
Topology examples of where IP is, and where IP is not. From that, I believe
good gap analysis can be made. Without it, I don't believe it can be made.

I believe all Requirements ID(s) should specify which topology each
requirement is referring to (and this ID provides names for each Topology),
because I read failings without those distinctions. Once the A&A issues are
addressed, clearly the text in this ID shouldn't remain.

>
>What is "the start"?  

Caller/initiator of an ETS/IEPREP communication from an IP device (not
necessarily voice - but in the GETS example network that exists, it's a
good place to reference)

>If a customer has a POTS phone connected to a LEC's
>gateway into a LEC IP network, is this IP at the start?  

Clearly this would either be Top A or C, as it would start CSN-based, then
GW into IP. Whether or not it GWs back to CSN or not determines Top A or C

>
>
>
>"This topology has the calling party placing the call from an CSN phone 
>(somewhere), and the called party being in an IP network. 
>
>Authentication/Authorization in topology C should occur within the CSN on 
>the originating side of the call path. 

What if the CSN portion is a Enterprise that hasn't converted (for whatever
reason) over to VoIP and their Provider is IP based, with the GW at the
Provider edge to the customer. In this case, the customer shouldn't be
responsible for A&A on 50,000 GETS capable users within the US (it get more
complex once this becomes international)

Is IEPREP going to address A&A in the IP portion of the network? Clearly
for every application other than Voice it must, so why not voice also?

>In time, there might be situations 
>where the CSN is only a transport into the IP network of an IEPREP call, 
>therefore similar attributes to topology B should occur within C; where 
>the IP authentication/authorization mechanism must be conveyed to the CSN 
>Gateway (and on to the calling user) in such a way as to identify that 
>call on an e2e basis to behave according to the goals set forth by the 
>IEPREP WG for that call."
>
>I'm afraid I don't understand what you mean.    

Take Top A and move the A&A function into the IP portion of that Topology

>
>Is "In time, there might be situations 
>where the CSN is only a transport into the IP network of an IEPREP call," by
>definition topology C or are you defining something new?  

Top C

>
>Is the 
>"'where' in 'In time, there might be situations 
>where the CSN is only a transport into the IP network of an IEPREP call, 
>therefore similar attributes to topology B should occur within C; where 
>the IP authentication/authorization mechanism must be conveyed to the CSN 
>Gateway (and on to the calling user) in such a way as to identify that 
>call on an e2e basis to behave according to the goals set forth by the 
>IEPREP WG for that call" 
>referring to topology B or topology C?  

Top C. Clearly the first Topology isn't spoken about in this ID, and that's
what present today (all CSN - which the IETF doesn't deal with). I see Top
A in place in some situations as well, but All CSN is prevalent. I see Top
B (IP at the Start) becoming more widespread because the adoption of VoIP
(the first app for our use) is being implemented at the edges of the CSN.
This is also likely the first Topology in which the A&A function will move
"from" the CSN "to" the IP portion of a comm path.

>
>
>
>"4.0 Security Considerations
>
>This document does not suggest anything other than a common naming 
>convention within IEPREP WG discussions, therefore there should be no 
>special security considerations"
>
>The document suggests more than a naming convention since it talks about the
>possible placement of authentication and authorization.  

All that text is intended to cause A&A to be addressed in other IDs (Reqs
and FW).

Do you have suggestions on text that ought to be in this ID for the Sec
Considerations?

cheers,
James 

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

_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep