Internet Engineering Task Force James M. Polk Internet Draft Cisco Systems Expiration: March 17th, 2003 File: draft-polk-ieprep-scenarios-00.txt IEPREP Topology Scenarios September 17th, 2002 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo attempts, without going into too much complexity, to articulate the likely topological scenarios which should be encountered, thus focused on by this working group when writing requirements, gap analysis and other solutions documents. Polk IEPREP Topology Scenarios Page 1 Internet Draft draft-polk-ieprep-scenarios-00.txt Sept 17th, 2002 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.0 Overview of IEPREP . . . . . . . . . . . . . . . . . . . . . . . . 2 3.0 IEPREP Topologies . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Topology A û IP in the Middle . . . . . . . . . . . . . . . . . . 3 3.2 Topology B û IP at the Start . . . . . . . . . . . . . . . . . . . 4 3.3 Topology C û IP at the End . . . . . . . . . . . . . . . . . . . . 5 3.4 Topology D û IP End-to-End . . . . . . . . . . . . . . . . . . . . 5 4.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . . 6 6.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.0 Authors Information . . . . . . . . . . . . . . . . . . . . . . . . 7 1.0 Introduction This memo attempts, without going into too much complexity, to articulate the likely topological scenarios which should be encountered, thus focused on by this working group when writing requirements, gap analysis and other documents. There has been much confusion on the IEPREP list as well as within each meeting (including the interim) as to the topologies IEPREP is referring to. Hopefully this document will give each reader a reference to which they can point to and say (with conviction) in scenario A, x happens, or y is broken; instead of consistently having list and session contributors have to describe the topology to which they are referring to as well as their point to be made. This memo attempts to be agnostic with regard to IP signaling or control protocols (SIP, MEGACO, etc). 1.2 Motivation Simply put, to get everyone referencing the same (named) topologies in order to have useful and less confusing dialog to further this WG's efforts. 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. These are authorized individuals trained in the usage of Emergency Preparedness Polk IEPREP Topology Scenarios Page 2 Internet Draft draft-polk-ieprep-scenarios-00.txt Sept 17th, 2002 Methods and Mechanisms. [1] details the framework of the IEPREP effort, and several requirements IDs can be found at the IEPREP WG homepage at: http://www.ietf.org/html.charters/ieprep-charter.html. Further information regarding the WG efforts should be researched there and the list archives. 3.0 IEPREP Topologies There are 4 often mentioned, but very little documented topologies discussed within this WG's work so far. The following subsections will go through each of the 4 that were first articulated by Scott Bradner in an analysis he did as a result of a side conversation regarding the SIP Resource Priority Header ID [2] and its usefulness within the IEPREP charter. The 4 topologies are (quickly): Topology A û IP in the Middle Topology B û IP at the Start Topology C û IP at the End Topology D û IP End-to-End Within each topology listed above, and detail in the following sections, is the question of "where is the authentication/authorization occurring"? This should add another dimension to Topologies B and C (making a total of six topologies, but with this first version of this document, explanation of it is left to within the explanation section for B and C respectively. As far as topologies A and D, with regard to where authentication/ authorization occurs, it's most likely in the topology A that authentication/authorization will occur in the Circuit Switched Network (CSN) on either side the IP core, therefore auth/auth in the IP section of the network will not (yet) be discussed further. For topology D, auth/auth can only occur within the IP network. The following sections detail each of the 4 topologies. 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). User authentication and authorization should occur within the CSN as it occurs in today's CSN only network. This topology should simplistically look like this: Polk IEPREP Topology Scenarios Page 3 Internet Draft draft-polk-ieprep-scenarios-00.txt Sept 17th, 2002 Circuit Internet Circuit Switched or Switched Network IP Segment Network -----------+ +--------------+ +----------- | +----+ | IP | +----+ | CSN | | | | | | | | CSN Phone --------| GW |------------------------| GW |-------- Phone | | | | | | | | | +----+ | | +----+ | -----------+ +--------------+ +--------- Figure 1. Topology A û IP in the Middle 3.2 Topology B û IP at the Start This topology has the calling party placing the call from an IP Phone, and the called party being in the CSN (somewhere). Internet Circuit or Switched IP Segment Network +-------------------+ +--------------- | +----+ | IP | | | | CSN Phone -------------------| GW |-------- Phone | | | | | +----+ | +-------------------+ +--------------- Figure 2. Topology B û IP at the Start The added dimension is the question of where the authentication/ authorization is done for the IEPREP or ETS service. If it is done within the CSN, it can only be performed by the caller in a form that the CSN understands: digits on the keypad of the phone, or speaker recognition (which isn't currently used in the CSN, but could be). 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. Polk IEPREP Topology Scenarios Page 4 Internet Draft draft-polk-ieprep-scenarios-00.txt Sept 17th, 2002 3.3 Topology C û IP at the End This topology has the calling party placing the call from an CSN phone (somewhere), and the called party being in an IP network. Circuit Internet Switched or Network IP Segment +-------------------+ +--------------- | +----+ | CSN | | | | IP Phone -------------------| GW |-------- Phone | | | | | +----+ | +-------------------+ +--------------- Figure 3. Topology C û IP at the End 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. 3.4 Topology D û IP End-to-End This topology has no circuit switched sections in the call path. Therefore, authentication/authorization must occur in IP, and in such a way to provide the end station enough information (tokens, strings, etc) to convey an IEPREP desired behavior for that call throughout the IP network. Polk IEPREP Topology Scenarios Page 5 Internet Draft draft-polk-ieprep-scenarios-00.txt Sept 17th, 2002 Internet or IP Network +-----------------------------------------+ | | +---------+ +-----------+ | | | IP IP | | Phone --------------------------------------------- Phone | | | +---------+ +-----------+ | | +-----------------------------------------+ Figure 4. Topology D û IP End to End 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 5.0 IANA Considerations There are no IANA considerations within this document 6.0 Acknowledgements Scott Bradner for his articulation in a prior discussions outlining these topologies that are described here 7.0 References [1] K. Carlberg and I. Brown, "Framework for supporting IEPS in IP telephony," Internet Draft, Internet Engineering Task Force, Jun 24, 2002. Work in progress. [2] J. Polk, H. Schulzrinne, "SIP Resource Priority Header", Internet Draft, Internet Engineering Task Force, March 2002. Work in progress. Polk IEPREP Topology Scenarios Page 6 Internet Draft draft-polk-ieprep-scenarios-00.txt Sept 17th, 2002 8.0 Authors Information James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA jmpolk@cisco.com "Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." The Expiration date for this Internet Draft is: March 17th, 2003 Polk IEPREP Topology Scenarios Page 7