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

James,

There are so many issues here.  Just a sample...

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

Let's say it is Top C.  You say in Topology C, "Authentication/Authorization
in topology C should occur within the CSN on 
the originating side of the call path. "

Where between a customers POTS phone and a LEC's gateway will the
authentication/authorization occur?

There are a whole host of issues but the main point is this topology draft
seems to want to design an implementation.  Perhaps others have different
views but the authorization stuff, implicit statements about requirements,
and requirements on the CSN seem a bit much for a topology draft.

Kimberly

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Friday, September 20, 2002 2:47 PM
> To: King, Kimberly S.
> Cc: Ieprep (E-mail)
> Subject: 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