Submitted to NAT Working Group C. Zaccone Y. T'Joens, B. Sales INTERNET DRAFT Alcatel March 3, 2000 Expires September 3, 2000 RSIP generic network architecture 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 Currently, the RSIP framework [RSIP-FRAM] focus its architecture on the typical scenario where hosts on a private realm are connected to an external realm by the mean of an unique gateway where the majority of the functionality's are concentrated. The aim of this document is to extend ths scope by describing a generic architecture. Furthermore, it tries to identify the functionality's of the system, their purposes as well as the way they interwork. The benefits of this extention are an increase of the robustness of the system and an opportunity to gain benefit of multiple connection towards one or more (multi-homing) external realms (ISPs). Zaccone, et al. Expires September 3, 2000 [Page 1] Internet Draft draft-zaccone-nat-rsip-gen-arch-01.txt March 3, 2000 Table of Contents 1. Introduction 2. Generic architecture 2.1. Network topology 2.2. Functional decomposition 2.2.1. Configuration Management 2.2.2. External Session Management 2.2.3. Policy Management 2.2.4. Transport Path Management 2.2.5. Reachability Determination 2.2.6. Locality Determination 3. Functional flows 4. Operations 4.1. Outbound session 4.2. Inbound session 5. References 1. Introduction The next figure depicts the RSIP architecture as described in [RSIP- FRAM]. This architecture builds upon the assumption where two different addressing realms are connected via a single router. In this architecture, all functions of authentication, authorization, configuration and the management of RSIP clients's sessions are concentrated into a unique gateway, the RSIP server. .--. .--. RSIP | | External | | client ---- RSIP host ---- / \ server / \ ------ +--+ ------ +---------------+| |+----------------+ +--+ Addressing Addressing realm A realm B RSIP architecture The architecture to be described in this document, is designed to cover a broader set of topologies. These include connectivity to single and multiple (multi-homed environment) external realms but also single and multiple links towards those realms. It also describes a distribution of the identified functionality's with the aim to have a more robust and extensible solution. Indeed, when multiple connection scenarios are taken into account, decoupling the functions enables the system to be more scalable and manageable. Zaccone, et al. Expires September 3, 2000 [Page 2] Internet Draft draft-zaccone-nat-rsip-gen-arch-01.txt March 3, 2000 2. Generic architecture Private Externals realm realms ........................ .Configuration . . Management (CM) . | ........................ | | Edge ........................ | router i .External Session . | 1 CM <--------------------- .--. /.\ /.\ /\ /.\ /\ |-> | | Internal | | / | \ ---- Host | | ..........| | |.......... / \ | | | | | ------ | | / | \ | \./ \/ \./ \/ | TPM PM RM <---------> Name Server | /.\ /.\ /.\ |....).................| | | External .--. | | Host | | | | ---- | \./ / \ <--------/ +--+ ------ | | Routers +--+ Functional flows ESM-CM functional flow Those two blocks interact in the context of the management of the external sessions. Indeed, the CM block creates/removes external sessions but delegates the management task to the ESM. Zaccone, et al. Expires September 3, 2000 [Page 6] Internet Draft draft-zaccone-nat-rsip-gen-arch-01.txt March 3, 2000 ESM-PM functional flow Those two blocks interact in the context of users auditing/accounting. ESM-TPM functional flow Those two blocks interact in the context of the management of the transport paths related to the external sessions. When the TPM, modifies (e.g. in case of a border router failure) the transport path related to an external session it inform the ESM such as to update the related session's information. CM-PM Those two blocks interact in the context of host/user authorisation. Indeed, the access to an external realm may be policed. CM-RM functional flow Those two blocks interact in the context of host reachability. Indeed, when a host get configured for external connectivity, the related configuration information (e.g. IP address) may be used to enable the RM to resolve a name mapping for that host. CM-TPM functional flow These two blocks interact in the context of the setup of the transport path. Indeed, when the CM creates a new external session, it interact with the TPM in order to communicate the information enabling the TPM to setup a transport path between the related host and the related external realm. In the same way, when a session is removed, the TPM is informed. CM-Internal Host interaction This interaction enable the CM to configure the host. This configuration may be triggered by the host itself (e.g. after discovery that external connectivity is required) of by an external stimulus (e.g. the RM is queried about the host). RM-Name Server interaction In order to enable inbound session, the name server interact with the RM block such as to resolve hostname maping request. LD-Internal Host interaction In order to determine if a destination is local or not, the host will interact with the LD block. TPM-Routers interaction The TPM is responsible of the management of the transport paths. Therefore is has to interact with routers of the local network to Zaccone, et al. Expires September 3, 2000 [Page 7] Internet Draft draft-zaccone-nat-rsip-gen-arch-01.txt March 3, 2000 take the appropriate actions. 4. Operations This section describes how the architecture is used for both outbound and inbound sessions. 4.1 Outbound session As soon as a RSIP client determines that it needs external connectivity (interaction with LD), it interacts with the CM in order to start the external access setup procedure. This setup procedure goes through 3 phases. In the first phase, the RSIP client is authenticated (functional flow CM-PM), if the current policy authorises the RSIP client to gain external access the second phase is authorised and started otherwise the process stops here. During the second phase, the CM determines which external realm will be used and the negotiation about the parameters to assign is started. When the negotiation is done, the third phase starts. During that phase, funtional flow CM-RM occur in order to update the current reachability information concerning that RSIP client (special threatment may be applied if RSAP-IP is used for this client). Functional flow CM-ESM also occur such as to communicate the assigned parameters. In the meanwhile, after the fucntional flow CM-TPM occur the TPM setup the transport path. 4.2 Inbound session Access to hosts/servers from the Internet is possible using hostnames as global identifier. Indeed, Internet hosts should try to contact hosts/servers of the local realm by first making a name resolution request. If no IP address is available in the mapping record, the name server will interact with the RM in order to take/apply appropriate decisions/actions. The funtional flow RM-CM occur in order to trigger the configuration of the corresponding RSIP client. As a consequence of the RM-CM functional flow, the functional flow CM-PM occur such as to check if the RSIP client is authorised to accept inbound session. If this is the case, the RSIP client will be triggered. The process after this is the same as for the outbound session (except perhaps for the first phase which may be useless). Note that this scheme is not designed to operate at the port translation address reuse level as we can not know in advance which port the initiator of the name request will try to connect to. Indeed, assume that an IP address is assigned to multiple RSIP clients, let us say hosts A and B, that the name server has assigned Zaccone, et al. Expires September 3, 2000 [Page 8] Internet Draft draft-zaccone-nat-rsip-gen-arch-01.txt March 3, 2000 a record for host A and that a name request came out for host A. As the name server has a record for host A, it will resolve the mapping, but if afterwards the initiator of the name request tries to connect to host A using a port assigned to host B, the connection will not be the expected one. However, this scheme may be applicable for well known services, since for these services, one may know in advance the port that will be used. Indeed, assume that in the example above host A was offering web services (and then assigned port 80) and that the name request was for ' www.company.com', as the www port is wel know we can ensure that web request will correctly be destinated to host A. 5. References [RSIP-FRAM] M. Borella, D. Grabelsky, "Realm Specific IP: A Framework", Internet Draft , Mai 1999. [MH-MP-PROV-CON] T. Bates, Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998. [TRANSP-FRAM] C. Zaccone, Y. T'Joens, B. Sales, "Framework for end-2-end native transport", Internet Draft , February 2000. Authors Addresses Carmelo Zaccone Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-8344 Fax : 32-3-240-9932 E-mail: Carmelo.Zaccone@Alcatel.be Yves T'Joens Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-7890 Fax : 32-3-240-9932 E-mail: Yves.Tjoens@Alcatel.be Zaccone, et al. Expires September 3, 2000 [Page 9] Internet Draft draft-zaccone-nat-rsip-gen-arch-01.txt March 3, 2000 Bernard Sales Alcatel Corporate Research Center Fr. Wellesplein 1, 2018 Antwerpen, Belgium. Phone : 32-3-240-9574 Fax : 32-3-240-9932 E-mail: Bernard.Sales@Alcatel.be Zaccone, et al. Expires September 3, 2000 [Page 10]