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

From: "King, Kimberly S." <[email-masked]>
Date: Fri, 20 Sep 2002 12:03:29 -0400

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

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 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.  In addition, you aren't just
providing scenarios but also mixing comments about when
authentication/authorization could/should occur.  

"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)"?  Are you asserting a
requirement on the topology?  Are you saying that CSN signaling should be
preserved, say by encapsulation, or are you indicating some sort of
preferential treatment in the IP network should occur?

"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.  Presumably you need this so as to provide some
preferential treatment in the IP network?  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.  To provide any preferential
treatment on a gateway without first authorizing in an IP network is a setup
for security problems.   Are you making requirements of the topology and the
CSN?

Is "Topology B : IP at the Start" assumed to be a carrier that has deployed
VoIP or could this be an enterprise?  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"?  

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

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

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?  

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?  

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

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 20 Sep 2002 13:47:06 -0500

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

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

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.

>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

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

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

>VoIP or could this be an enterprise?  

As stated above, either/both

>For example, if a business has an

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

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

>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 

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

>definition topology C or are you defining something new?  

Top C

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

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