Hossam Afifi INTERNET DRAFT INRIA France 13 July 2001 Charles E. Perkins Expires 13 December 2001 Hannu Flinck Nokia Research Center Internet General Packet Radio Service (IGPRS) Service Description draft-hossam-igprs-00.txt Status of this Memo This document is an individual contribution for consideration by the Mobile IP Working Group of the Internet Engineering Task Force. Comments should be submitted to the mailing list. Distribution of this memo is unlimited. 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 IGPRS integrates Mobile IPv6 into the GPRS architecture (UMTS version). IGPRS provides mobility management and authentication to native IP protocols through the legacy cellular signaling. IGPRS provides a transition mechanism to migrate towards Mobile IPv6 in a way that remains compatible with the existing GPRS architecture. It does this by using the same HLR, GPRS state machines, and air interfaces, co-existing with and re-using the cellular protocols. IGPRS supports GPRS roaming by maintaining the subscriber database (HLR). The IGPRS architecture is based on a set of servers that Afifi, Perkins, Flinck Expires 30 December 2001 [Page i] Internet Draft IGPRS 31 July 2001 co-exist with the GPRS entities and hence support GPRS terminals by maintaining the air interface and the necessary state machines. Afifi, Perkins, Flinck Expires 30 December 2001 [Page ii] Internet Draft IGPRS 31 July 2001 Contents 1. Introduction 1 2. Scope and Scenario of Operation 1 3. Abbreviations and Terminology 1 3.1. MAP Messages List . . . . . . . . . . . . . . . . . . . . 3 3.2. Functions List . . . . . . . . . . . . . . . . . . . . . 4 3.3. RRC messages List . . . . . . . . . . . . . . . . . . . . 5 3.4. Errors List . . . . . . . . . . . . . . . . . . . . . . . 5 3.5. Timers List . . . . . . . . . . . . . . . . . . . . . . . 5 3.6. State List . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Mobile IPv6 Sub-Options List . . . . . . . . . . . . . . 6 4. Protocol and Architecture Overview 7 4.1. Protocol Entities and Identification . . . . . . . . . . 7 4.1.1. Identification . . . . . . . . . . . . . . . . . 9 4.1.2. Address Assignment and Lower Layer Assumptions . 9 4.2. Core Network Assumptions . . . . . . . . . . . . . . . . 9 4.3. The Mobile Node and IGSS State Machines and procedures . 9 4.3.1. PMM-DETACHED State . . . . . . . . . . . . . . . 10 4.3.2. PMM-IDLE State . . . . . . . . . . . . . . . . . 10 4.3.3. PMM-CONNECTED State . . . . . . . . . . . . . . . 10 4.4. State transition in the MN and IGSS . . . . . . . . . . . 11 4.4.1. Moving from PMM-DETACHED to PMM-CONNECTED . . . . 11 4.4.2. Moving to PMM-DETACHED . . . . . . . . . . . . . 12 4.4.3. Moving from PMM-IDLE to PMM-CONNECTED . . . . . . 12 5. IGPRS Procedures and Functions 12 5.1. Periodic RA Update Timer Function . . . . . . . . . . . . 12 5.2. Mobile Reachable Timer Function . . . . . . . . . . . . . 13 5.3. Attach Function . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Stateless Address Autoconfiguration . . . . . . . 14 5.3.2. Routing Updates within the same IGPRS domain . . 15 5.3.3. Inter-IGSS Attach . . . . . . . . . . . . . . . . 15 5.3.4. Erroneous Attach . . . . . . . . . . . . . . . . 16 5.4. Detach Function . . . . . . . . . . . . . . . . . . . . . 16 5.5. Updating the HLR . . . . . . . . . . . . . . . . . . . . 18 5.6. Deleting authentication info . . . . . . . . . . . . . . 19 6. Security Functions and Data Elements 19 6.1. Authentication of Subscriber . . . . . . . . . . . . . . 19 6.2. P-TMSI Signature . . . . . . . . . . . . . . . . . . . . 21 7. Message Formats 22 Afifi, Perkins, Flinck Expires 30 December 2001 [Page iii] Internet Draft IGPRS 31 July 2001 7.1. List of RRC Messages . . . . . . . . . . . . . . . . . . 22 7.2. IMSI/MSISDN transport in NAI . . . . . . . . . . . . . . 22 7.3. Messages for an attach procedure: first time . . . . . . 22 7.3.1. AR to MN . . . . . . . . . . . . . . . . . . . . 23 7.3.2. AR to AAAF . . . . . . . . . . . . . . . . . . . 24 7.3.3. IGSS to HA and HLR . . . . . . . . . . . . . . . 24 7.3.4. AAAH to AAAF IGSS . . . . . . . . . . . . . . . . 25 7.3.5. IGSS to AR . . . . . . . . . . . . . . . . . . . 25 7.3.6. Router Advertisement after Attach . . . . . . . . 25 7.3.7. Messages for attach within the AAA domain . . . . 26 7.3.8. Router Advertisement after Attach . . . . . . . . 26 7.3.9. Authentication Error . . . . . . . . . . . . . . 27 7.3.10. Detach . . . . . . . . . . . . . . . . . . . . . 27 7.4. Messages for an attach procedure: inter-IGSS . . . . . . 27 7.4.1. Second Time Attach . . . . . . . . . . . . . . . 27 7.4.2. IGSS Response . . . . . . . . . . . . . . . . . . 28 7.5. Link Layer messages . . . . . . . . . . . . . . . . . . . 28 7.5.1. Router Advertisements . . . . . . . . . . . . . . 28 8. Additional Security Considerations 30 Addresses 33 Afifi, Perkins, Flinck Expires 30 December 2001 [Page iv] Internet Draft IGPRS 31 July 2001 1. Introduction The IGPRS architecture aims at the integration of the IPv6 protocol [IPv6 ] in the GPRS [GPRS ] infrastructure. The IGPRS data and signaling protocol suite is based on Mobile IPv6 [mipv6 ]. It uses the existing GPRS infrastructure for lower layer data and signaling transport. Since IGPRS is targeted to co-exist with GPRS, it specifies also a translation of MAP [MAP ] specifications to Internet protocols and eventually the transport of RANAP [RANAP ] into DIAMETER messages. IGPRS uses Mobile IPv6 as the data protocol and DIAMETER [diam ] as the main signaling protocol for Authentication, Authorization, and Accounting [AAA ]. If the network does not support DIAMETER authentication the mobile node can still be authenticated using the conventional GPRS method. At the boundaries we interface the Internet protocols with the conventional GPRS entities (e.g. HLR) in order to keep the necessary user management consistency. The IGPRS interface will be complementary to GPRS protocols and co-exist with them. Hence, it enables a smooth migration to a Mobile IPv6 enabled network. An IGPRS terminal will be able to directly reach the Internet (or intranet) infrastructure for data and signaling transmission. A GPRS Radio Network Controller that has the additional functions defined in this document will be able to translate all the traffic coming from an enhanced GPRS terminal to a conventional IPv6 protocol suite. We assume that the identification of the subscriber is based on the GPRS network procedures, through the use of IMSI or the MSISDN. However compabatibility with AAA infrastructure has been preserved. 2. Scope and Scenario of Operation This specification defines MIPv6 connectivity in an infrastructure that can be built on top of existing GPRS systems. This infrastructure exploits the GPRS link and physical layers. It interworks with HLRs/VLRs. It does not however use GPRS main data-plane infrastructure (GTP) since data transmission is provided by Mobile IPv6. This specification allows a Mobile Node to start a session in IGPRS and terminate it in GPRS, or vice versa. 3. Abbreviations and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [rfc2119 ]. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 1] Internet Draft IGPRS 31 July 2001 This document uses terms defined in Mobile IPv6 [mipv6 ], Neighbor Discovery [nd], and Stateless Address Autoconfiguration [AUTO ]. In addition, this document uses the following terms: Access Router (AR) the router offering connectivity to the mobile node at IP network level. BA Binding Acknowledgement Destination Option [mipv6 ] BSS Base Station subsystem. The base station controler in GSM. BU Binding Update Destination Option [mipv6 ] GSM Global System for Mobile communications. Public cellular network based on TDMA. GTP GPRS Tunneling Protocol. The tunneling protocol between SGSN and GGSN in GPRS (GSM version). GTP-U GPRS Tunneling Protocol User Plane. The tunneling protocol between RNC, SGSN and GGSN in GPRS (UMTS version). GTP-C GPRS Tunneling Protocol Control. The signaling protocol between SGSN and GGSN in GPRS (UMTS version). HA Home Agent.The node maintains an association between mobile node's static home address and the varying care of address. HLR The active database storing AAA like information in public cellular networks. IGSS Internet GPRS Support Server. Server defined in IGPRS The main authentication node, performing the functions of AAAF and AAAH according to [AAA ] and [AAA6 ]. IMEI International Mobile station Equipment Identities. Terminal H/W identification. IMSI International Mobile Subscriber Identity [imsi ] and [imsi2 ]. Kc The key used for GSM/GPRS ciphering (8 bytes). K_i The secret key related to an IMSI stored in HLR and MN. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 2] Internet Draft IGPRS 31 July 2001 NAI Network Access Identifier. MIPv6 Mobile IPv6. MN Mobile Node. MSISDN Mobile Station International ISDN Number. The telephone number as specified in ITU-T. RA Routing Area; space of administration for a single IGSS server. RAC Routing Area Code; the access router's IPv6 address. RANAP Radio Access Network Application Part. The control protocol between SGSN and RNCs. RAND Challenge used to authenticate GPRS users. RES Challenge response. RNC Radio Network Controller. The base station controler in UMTS. TLLI Temporary Logical Link Identity. A MAC Address identifying a session with a terminal. TMSI Temporary Mobile Subscriber Identity. A local authentication number generated within a RA. XRES Expected Result: Authentication result expected by hashing the RAND number with a secret key. UMTS Universal Mobile Telecommunication System. Public cellular access part based on FDMA. UTRAN UMTS Terrestrial Radio Access Network: UTRAN is a conceptual term identifying that part of the network which consists of RNCs and Node Bs between Iu an Uu. USIM User Services Identity Module. Module that stores a subscribers secret keys. 3.1. MAP Messages List The messages in this section are the relevant messages from the MAP specification [MAP ]. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 3] Internet Draft IGPRS 31 July 2001 MAP-PROVIDE-SUBSCRIBER-LOCATION Sent to the HLR to request the current know location for a MN. MAP_Send_Authentic_Info_Req Sent to the HLR to request authentication information for a given IMSI. MAP_Send_Authentic_Info_Rsp Authentication set list response containing necessary authentication keys for a given IMSI. Check_IMEI_Ind Message Sent to verify the terminal identity through the IMEI identifier. Check_IMEI_Pos_Rsp Answer from the EIR about equipment status SendParameters Operation done by the AAAH to request the MN secret key K_i Update_Location_Ind Message sent to update the HLR for a given IMSI. Update_Location_Pos_Rsp Response to UpdateLocationInd from the HLR. Insert_Subscriber_Data_Req Message sent from the HLR to assert a subscriber in a new authentication server. Cancel_Location_Req Message sent from the HLR to cancel a IMSI entry. Open_Req Message sent to begin a new MAP dialogue between two MAP service users. Close_Req Message sent to release an active MAP dialogue. 3.2. Functions List Attach A set of procedures that enable the mobile node to configure a valid global address. Detach A set of procedures to disconnect the mobile node. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 4] Internet Draft IGPRS 31 July 2001 3.3. RRC messages List Note that this is not an exhaustive list. Attach A message that enable the mobile node to authenticate itself and to have access to the network. Detach A set of procedures to disconnect the mobile node. Routing Area Update Request It lets the MN periodically advertise its location or when it camps on a new routing area. Authentication and ciphering request The network is requiring authentication from the MN Activate PDP Context One side (MN or Network) asks for a valid address and for user data air resources. 3.4. Errors List DIAMETER_ERROR_AUTH_FAILURE Diameter Error when Authentication fails (AMAv6) IGPRS Authentication_Error_Reject Error code sent in Binding Acknowledgement (code 139). 3.5. Timers List Periodic RA Update Timer Maintained in Mobile Node to send a (embedded) BU Mobile Reachable Timer Maintained in IGSS to cancel the MN entry 3.6. State List PMM-DETACHED Maintained in the MN. Means that the mobile is not communicating. PMM-IDLE Maintained in Mobile Node and IGSS. Means that the mobile was communicating but that it currently does not have a valid care-of address. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 5] Internet Draft IGPRS 31 July 2001 PMM-CONNECTED Maintained in the Mobile and IGSS. Means that the authentication and mobility management are up to date and that the mobile can communicate. It means also that a signalling channel is established with the RNC. 3.7. Mobile IPv6 Sub-Options List IMSI Allows the MN to identify itself; used with the Binding Update. MSISDN A node's ITU-T telephone number. P-TMSI Allows the SGSN to send a temporary key shared with the MN (BU and Binding Acknowledgement). P-TMSI signature Enables the MN to sign the P-TMSI sub-option (BU). RAND A Challenge. Previous Care-of Address The MN's care-of address at its previous IGPRS. IMSI Attach Confirm Allows the MN to send its identity and to confirm the attachment to the AR (BU) and then to the IGSS (Optional). DIAMETER Command List and Features AMRv6 AA-Mobile-Node-Request-v6 sent from the AAAF to the AAAH AMAv6 AA-Mobile-Node-Answer-v6 sent from the AAAH to the AAAF HARv6 Home-Agent-Request-v6 Update to the HA sent from the AAAH HAAv6 Home-Agent-Answer-v6 Confirmation from the HA to the AAAH Features MIPv6-Feature-Vector Afifi, Perkins, Flinck Expires 30 December 2001 [Page 6] Internet Draft IGPRS 31 July 2001 4. Protocol and Architecture Overview In this section we describe the main organization of IGPRS, the different entities and the organization of the overall system. 4.1. Protocol Entities and Identification The GPRS architecture is divided into a control plane and a data plane. It is mainly composed of - a mobile node (MN), - a base station controller (RNC in UMTS), - a tunneling end-point (SGSN), - a router to external data networks (GGSN) and - databases (HLR and MSC/VLR). Data is tunneled through two different GPRS Tunneling Protocols: PDCP and GTP-U. The first protocol is necessary at the radio access for compression and context relocation. The second is used for forwarding mobile terminals data to their new location. Mobile IPv6 is mainly an alternative to GTP-U. The figures below show a simplified view of the GPRS control and data planes. MS RNC SGSN GGSN HLR +--------+ +------------+ +----------+ +-----+ +-----+ |IP | | | | | IP | | IP | | MAP | |--------| | | | | GTPr| | GTPr| | SS7 | | RRC | | RRC |RANAP| |RANAP | +-----+ +-----+ | RLC | | RLC |SS7 | | SS7 | | MAC | | MAC | | +----------+ | UTRAN | |UTRAN | | +--------+ +------+-----+ Figure 1: GPRS protocol and entities in the UMTS (Control Plane) The proposed IGPRS protocol suite will co-exist with the legacy GPRS infrastructure, re-use most of its components and lower layers and enable gradual replacement as desired. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 7] Internet Draft IGPRS 31 July 2001 We first define the IGSS, which will co-exist with the SGSN. The IGSS is a Authentication-Authorization-Accounting (AAA) server running IPv6 with additional DIAMETER, routing and security functions. It is not simply named a AAA server because it has to support several other procedures that are not in the scope of the AAA. The MIPv6 Home Agent may co-exists with the GGSN. The base station controller (RNC) implements IP routing and plays the role of an access router. The mobile node implements GPRS in addition to Mobile IPv6. There is no overhead in this assumption since any GPRS terminal supporting IPv6 should support Mobile IPv6 also. All IGPRS signalling is done using the RRC signalling developed for GPRS. This means that IPv6 packets are encapsulated in the RRC signalling. The advantage of this method is to have one message that is updating at the same time the UMTS infrastructure and the Mobile IPv6 plane. AAAF MN RNC IGSS@SGSN HA@GGSN AAAH HLR +------+ +----------+ +--------+ +-----+ +--------+---+ |MIPv6 | |(MIPv6) | |DIAMETER| |MIPv6| |DIAMETER|MAP| |------| |----------| | | | | | | | | PDCP | |PDCP| | +-----+--+ +-----+ +--------+---+ +------+ +----|RANAP| |RANAP| | | UMTS | |UMTS| | +-----+--+ +------+ +----|-----+ @ means co-resident with Figure 2: IGPRS protocols and entities In IGPRS, IPv6 is implemented on top of RRC [24.008 ]. Implementation of the Mobile node MN, RNC, SGSN are affected by IGPRS. The GGSN is not used (replaced by the Home Agent). A proxy is responsible for dealing with the HLR MAP query/responses. The MN interacts with its Home Agent and with the RNC. Mobile IPv6 is used by the MN, the IGSS (through DIAMETER) and the HA. The following section describes the interaction of the IPv6 layer with GPRS states. IGPRS is synchronized with GPRS mobility management and session management procedures. It uses hence the same GPRS timers. Authentication is mandatory in IGPRS. IGPRS can use GPRS authentication procedures, it can use AAA DIAMETER based procedures or both. When AAA authentication is used the IGSS Afifi, Perkins, Flinck Expires 30 December 2001 [Page 8] Internet Draft IGPRS 31 July 2001 initiates security functions and updates the HLR with any necessary mobility management information. 4.1.1. Identification The identification of a MN is based on information built in the Subscriber Identification Module (SIM). IGPRS can use two different identifiers. The first is the IMSI [imsi ]. It is a number usually assigned with the subscription of the MN to the network. It usually remains hidden in the network and is mainly used in the GPRS/GSM network. The second is the MSISDN. It corresponds to the telephone number assigned to the MN and is a public information. The MN may use two identifications if it needs to authenticate itself to a different ISP than the public operator. 4.1.2. Address Assignment and Lower Layer Assumptions The MN uses Stateless Address Autoconfiguration [AUTO ] and Router Advertisements [nd] to get its Care-of Address. These IPv6 messages are encapsulated in the RRC messages for a unique rapid and efficient configuration 7. IGPRS uses the same address for signalling (mobility and authentication). This does not mean that the MN is unable to obtain additional addresses. IGPRS is based on the IPv6 specifications and hence a MN can create as many as addresses as necessary by the normal IPv6 configuration procedures, and use IGPRS with any or all of its (routable) addresses. 4.2. Core Network Assumptions The IGPRS core network is composed of access routers, Home agents and AAA servers. These elements require AAA connectivity. This implies that the necessary security procedures for AAA requirements be implemented and operated before any session establishement with mobile elements. There should therefore be a valid session between neighbor AAA servers, between AAA servers and their respective home agents and between AAA servers and their access routers. 4.3. The Mobile Node and IGSS State Machines and procedures The IGPRS states are directly related to GPRS states. Each time the MN or the IGSS needs to send Mobile IPv6 related information it uses the RRC messages defined in [24.008 ]. This means that Mobile Afifi, Perkins, Flinck Expires 30 December 2001 [Page 9] Internet Draft IGPRS 31 July 2001 IPv6, MAC Mobility Management and MAC Session Management are tightly coupled. 4.3.1. PMM-DETACHED State In the PMM-DETACHED state there is no communication between the MN and the 3G-SGSN and hence no communication neither between MN and IGSS. In the MAC layer, the MN Mobility Management state machine does not react on system information related to the 3G-SGSN. The MN is not reachable by a 3G-SGSN, as the MN location is not known. In order to establish MAC MM contexts in the MN and the IGSS, the MN shall perform the GPRS Attach procedure5.3. When the signalling connection is established between the MN and the IGSS for performing the GPRS attach, the state changes to PMM-CONNECTED in the IGSS and in the MN MAC layer. The MAC signalling connection is made up of two parts; an RRC connection and an Iu connection. In IPv6, the network is unreachable when the MN is in PMM-DETACHED state. The MN typically maintains knowledge of home agent and home addresses. 4.3.2. PMM-IDLE State The MN location is known in the IGSS with an accuracy of a routing area (subnet). The MN has been authenticated to the network. Paging is needed in order to reach the MN, e.g., for signalling. The MN MAC and IGSS have established MM contexts. The MS shall perform a routeing area update if the RA changes. Signalling towards the HLR is needed if the IGSS does not have an MM context for this MN. The MN MAC and IGSS shall enter the PMM-CONNECTED state when the signalling connection is established between the MN and the IGSS. GPRS detach changes the state to PMM-DETACHED. The IGSS may perform an implicit GPRS detach 5.4 any time after the MN reachable timer expiry. The MN's MAC MM context is deleted, preferably after a certain (implementation dependent) time. The HLR may be informed about the deletion. 4.3.3. PMM-CONNECTED State The MN location is known in the IGSS with an accuracy of a serving RNC. In the PMM-CONNECTED state, the location of the MN is tracked by the serving RNC. The MN performs the MAC routeing area update procedure when RAI in the MM system information changes. A Routeing area update is always accompanied with an IPv6 Binding Update. When an MN MAC layer and a IGSS are in the PMM-CONNECTED state, a signalling connection is established between the MS and the IGSS. The Afifi, Perkins, Flinck Expires 30 December 2001 [Page 10] Internet Draft IGPRS 31 July 2001 MN shall enter the PMM-IDLE state when its signalling connection to the IGSS has been released or broken. This release or failure is explicitly indicated by the RNC to the MN MAC layer or detected by the MN MAC (RRC connection failure). After a signalling procedure (e.g., routeing area update), the IGSS may decide to release the signalling connection, after which the state is changed to PMM-IDLE. GPRS detach changes the state to PMM-DETACHED. 4.4. State transition in the MN and IGSS This section gives details on the events when a MN changes its state. A state transition depends on the current state (PMM-DETACHED, PMM-IDLE, or PMM-CONNECTED) and the event which occurred (e.g., IGPRS attach). We describe the necessary IPv6 actions when each such transition happens. +------------+ +------------+ /|PMM-DETACHED| /|PMM-DETACHED| / +------------+ / +------------+ / / \ / / \ | V ^ | V ^ | | | ^ | | | \ / | \ / _ | +-------------+ | +-------------+/ \ ^ |PMM-CONNECTED| ^ |PMM-CONNECTED| v | +-------------+ | +-------------+\_/ | / \ | / \ | V ^ | V ^ | | | | | | \ \ / \ \ / \ +------------+ \ +----------+ \|PMM-IDLE | \| PMM-IDLE| +------------+ +----------+ MN IGSS Figure 3: MM state diagrams for MN and IGSS 4.4.1. Moving from PMM-DETACHED to PMM-CONNECTED This requires executing the IGPRS Attach procedure as described in Section 5.3. It happens when a user needs to communicate or in Afifi, Perkins, Flinck Expires 30 December 2001 [Page 11] Internet Draft IGPRS 31 July 2001 response to paging. When in CONNECTED mode, the MN has a valid IPv6 address. It can send and receive data. This means that the MN is in PMM-CONNECTED and ACTIVE GPRS modes. 4.4.2. Moving to PMM-DETACHED After moving to the PMM-DETACHED state, the MN is not allowed to use its care-of address. The MN goes into PMM-DETACHED state after executing either of these functions: - Detach: The IGSS returns to PMM-DETACHED after expiration of the Mobile Reachable timer. This can happen also in the MN by receiving a ``PMM-IDLE failure'' signal from the MAC layer. The MN may ask explicitly to detach itself by sending a zero lifetime BU to the HA (See Section 5.4). - Cancel_Location: The IGSS acting as a AAAH receives a MAP Cancel_Location_Req message from the HLR. The AAAH forwards a Session Termination DIAMETER message to the HA, a Session Termination DIAMETER message to the AAAF and in turn sends it to the access router. The AR sends a ``Router Advertisement'' message with Lifetime set to zero to the MN. 4.4.3. Moving from PMM-IDLE to PMM-CONNECTED The mobile node moves from PMM-IDLE to PMM-CONNECTED state when it establishes an RRC signalling connection. The list of RRC signalling messages is in Section 7. 5. IGPRS Procedures and Functions This section describes functions related to timers and to mobility management maintained for IGPRS in both the MN and network sides. 5.1. Periodic RA Update Timer Function In IGPRS BU frequency should be the same as Routeing Area Updates. This maintains the MM consistency between MIPv6 and the GPRS that is the main idea of IGPRS. The Periodic Routing Area Update Timer function controls the periodic transmission of BU with IGPRS Authentication messages from the MN. The BU messages containing IGPRS specific authentication data are sent to the AR. They are forwarded Afifi, Perkins, Flinck Expires 30 December 2001 [Page 12] Internet Draft IGPRS 31 July 2001 through DIAMETER extensions to the IGSS/AAAF for this routing area, using same terminology as in GPRS. When the Routing Area update timer expires, the MN starts a Periodic Routing Area Update procedure by sending a binding update to the AR (see Section 5.3.2) with the P-TMSI authentication. In the MAC layer between IPv6 and the RRC, a Binding Request may be generated and injected to the node in order to force it to send the BU. In this way the IPv6 layer can remain unchanged and ``lower layer independent''. 5.2. Mobile Reachable Timer Function The Mobile Reachable Timer function resides in the IGSS. It controls the transition from the PMM-IDLE state to the PMM-DETACHED state. The ``Mobile Reachable Timer'' is slightly longer than the periodic Routing Area update timer used by an MN. It is stopped when the PMM-CONNECTED state is entered, reset and started when the state returns to PMM-IDLE. When the timer expires, no more IGPRS messages are sent to the MN. Therefore, the IGSS acting as AAAF sends a DIAMETER message to the IGSS acting as AAAH that forwards the Session Termination to the HA. A session termination is also sent to the access router to invalidate the MN careof address. 5.3. Attach Function The main role of an attach is the authentication of the MN. An IGPRS attach is mapped onto a RRC Attach request and an RRC activate PDP context. The IGPRS Attach procedure results into assignment of the new careof address for the MN. After the IGPRS Attach, the HA knows also where to find the MN. The MN sends in the GPRS-ATTACH request a BU. Any AAA challenge and Challenge response should happen during this attach procedure with the help of the Authentication and ciphering request RRC messages Section 7. An IGPRS attach is made with the access router, local and home IGSS, and home agent. It results in validating the MN global IPv6 address. In the attach procedures, the MN provides its identity as explained in Section 6.1. A temporary identification should also be used (P-TMSI). After executing the IGPRS attach, the MN is in PMM-CONNECTED state. IGPRS does not make distinction between ACTIVE and PASSIVE GPRS modes. From IGPRS perspective, the MN is always in ACTIVE mode. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 13] Internet Draft IGPRS 31 July 2001 If the Attach Request cannot be accepted, the IGSS returns a Result Code AVP with DIAMETER_ERROR_AUTH_FAILURE error code (see section 7.3.9) in a DIAMETER session termination message (STI). This is sent to the AAAF and AR. The AR sends a Binding Acknowledgement with Status field containing the Authentication Error code (139). The BA is sent during the ATTACH response procedure from the RNC. 5.3.1. Stateless Address Autoconfiguration The attach function covers several situations. The first happens when the MN is attached to the network for the first time. We assume that the MN has pre-configured HA and Home Addresses. If this is not the case, the MN uses the extensions described in [diammip ] and MIPv6 (Home Address set to zero) in order to ask for a HA. The attach procedure is then augmented in the IGPRS system with an access to the HLR (AAAH may request from its HLR information about the most appropriate HA for the current MN location). Authentication is performed between the MN and access router using the MIPv6 sub-options field as described in Section 6.1. It continues between the access router and IGSS with DIAMETER extensions. Authentication can be achieved using AAA only or using both AAA and GPRS authentication procedures. In the attach procedure, the MN sends a Binding Update with a challenge response. This signature (called RES in GPRS) is forwarded in a DIAMETER AMRv6 message to the IGSS. After the MN is authenticated, the IGSS may send back a P-TMSI and P-TMSI signature that will be used for any subsequent authentication to the same IGSS. Challenge and Challenge response use the specifications for [AAA6 ]. Messages are encapsulated in the RRC Authentication and Ciphering Request and Response [24.008 ]. +-------+ MAP +-------+ HAR +-------+ | HLR |------| AAAH |--------| HA | +-------+ +-------+ HAA +-------+ \ \ AMA \AMR \ +------+ BU,BA +----+ AMR +------+ | MN |-------| AR |-----| IGSS | +------+ +----+ AMA +------+ Figure 4: Attach function in a new IGPRS domain Afifi, Perkins, Flinck Expires 30 December 2001 [Page 14] Internet Draft IGPRS 31 July 2001 5.3.2. Routing Updates within the same IGPRS domain The attach function in the same IGPRS domain is faster, since the mobile node continues to roam in the same core network and thus can re-use the authorization already known by the IGPRS/AAAF. The new access router (NAR) receives the Binding Update with the IMSI, P-TMSI, P-TMSI signature and Old Prefix sub-option fields. Note that the Old Prefix sub-option is not important when the MN remains in the same AAAF domain (since the AAAF knows the previous MN location) but it is useful for performance reasons when the MN comes to a new AAAF (same principles as in the GPRS). NAR includes the Binding Update in an AMRv6 DIAMETER message and sends it to the IGSS/AAAF. Since the IGSS/AAAF already has authorization information for the mobile node, it can directly validate the request without going to the home domain (or, specifically, the HLR). Upon approving the MN, the IGSS/AAAF sends back a DIAMETER reply (AMAv6) to the access router to update the MN. Since the Binding Update was not yet sent to the home agent, the access router then completes the forwarding operation for it after the authentication. AAAF AAAH +------+ BU +----+ AMR +------+ +------+ +----+ | MN |------| AR |------| IGSS |--| IGSS |--| HA | +------+ BA +----+ AMA +------+ +------+ +----+ Figure 5: Attach function for a second time. 5.3.3. Inter-IGSS Attach This function is called an Inter-IGSS attach because it consists in a change of AAAF server for the mobile node (see Fig. 6). Note that the HA typically SHOULD not change. The MN sends a BU destination option (IMSI, P-TMSI, P-TMSI signature, old prefix) to the access router. The access router builds a DIAMETER AMRv6 message and sends it to the IGSS. The new AAAF IGSS sends DIAMETER Mobile IPv6 Request message to the home IGSS (AAAH) containing its new address. If the mobile node supplies the IPv6 address or NAI of its previous IGSS, that previous IGSS should receive an authenticated DIAMETER teardown message, the Session Termination Indication (STI). Sending the STI allows closer adherence to the GPRS design model and may improve response time. However, this requires additional security Afifi, Perkins, Flinck Expires 30 December 2001 [Page 15] Internet Draft IGPRS 31 July 2001 associations. The new IGSS has hence to send in its STI, the P-TMSI, P-TMSI signature values as a verification element. The IGSS/AAAH sends an Authentication Request MAP message (see section 5.5) to the HLR to retrieve the necessary information. If the old IGSS/AAAF was not yet informed about the change of MN's location, IGSS/AAAH sends a DIAMETER (STI) with the IMSI as a reference key. The IGSS/AAAH knows from the HLR that the old IGSS/AAAF was not informed Section 5.5. IGSS/AAAH updates the HLR with the new IGSS/AAAF address (MAP Update Location). If the HLR sends back a Insert Subscriber Data with the GPRS subscription information, the AAAH will have to answer back and either confirm or reject the presence of the MN in the visited routing area, using the Insert_Subscriber_Data_Ack MAP message). If the security functions fail to authenticate the MN or the MN is not allowed to roam in the area, then the AMRv6 message is rejected, and the new IGSS returns a DIAMETER AMAv6 with Result-Code AVP set to DIAMETER_ERROR_AUTH_FAILURE. The Access Router sends a Binding Acknowledgement with the IGPRS-authentication-Reject error code (139) Status Field. When authentication succeeds the new IGSS updates its own registers with the MN entry (new care-of address, P-TMSI and P-TMSI signature). It sends an AMA message to the access router. The access router returns the Binding Acknowledgement to the MN containing the new P-TMSI suboption. The MN optionally acknowledges the new P-TMSI by returning an IMSI-Attach confirm sub-option (see section 6.1) to the AR. An access router that receives the packet will have to forward a DIAMETER AMR message to the IGSS containing the MN confirmation in a MIPv6-Feature-AVP. 5.3.4. Erroneous Attach If for any reason, or during an intrusion trial, the MN sends a wrong P-TMSI or a wrong signature in the BU destination option, the authentication procedure will be longer. The MN will have to authenticate itself like for a first time attach. 5.4. Detach Function The Detach Function allows an MN to inform the network that it wants to make a GPRS IMSI detach, and it allows the network to disconnect/inform an MN that it has been IMSI-detached by the network. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 16] Internet Draft IGPRS 31 July 2001 HAAv6 +-------+ MAP +-------+ HARv6+-------+ | |-----+ IGSS +------+ | | HLR | ---+ AAAH |--- | HA | +-------+ / +-------+ \ +-------+ / \ / \ AMRv6 / AMAv6 AMRv6 \ AMAv6 / \ AAAF / \ +----------+ +-----------+ | New IGSS | | Old IGSS | +----------+ +-----------+ | AAAF AMRv6|AMAv6 | +------+ | AR | +------+ RS | RA BU | BA | +-------+ | MN | +-------+ Figure 6: Attach function in a new domain The MN is detached from IGPRS either explicitly or implicitly. - Explicit detach: The network or the MN explicitly requests detach. - Implicit detach: The network detaches the MN, without notifying the MN, a configuration-dependent time after the mobile reachable timer expires, or after an unrecoverable radio error causes disconnection of the logical link. In the explicit detach case sent by the node, a BU with Lifetime set to zero is sent to the access router. The AR sends a Session Termination Indication (STI) to the AAAF. The DIAMETER message is forwarded to the AAAH that has to notify the HA of detach request in order to stop forwarding packets to the MN. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 17] Internet Draft IGPRS 31 July 2001 In the explicit detach initiated by the network, the same procedure updates the HA and the AR. An ICMP v6 Router Advertisement with Lifetime=0 is sent to the MN IPv6 destination address in order to de-allocate the routing information. This is sent in the Detach Request RRC message. 5.5. Updating the HLR When the AAAH receives a DIAMETER AMRv6 message to update the new MN location, it has to update the HLR and the old IGSS. The HLR operations happen before AAAH sends the HARv6 to the mobile node's home agent. AAAH HA HLR Old-AAAF New-AAAF --------- --- ------ -------- ------- +--- MAP Update Location--->+ +<-----Cancel Location------+ + + +----- HARv6---> +<-----HAAv6---+ +-------DIAMETER Session Termination------>+ +<-----DIAMETER Session Termination Ack----+ + + +----Cancel Location Ack--->+ +<--Insert Subscriber Data--+ +----------------- DIAMETER AMAv6---------------------->+ +-Insert Subscr. Data Ack-->+ Figure 7: AAAH dialogue with HLR, using MAP messages, for mobility management The Update Location message contains the SGSN number, IGSS address and IMSI (as required by the GPRS specifications). When the HLR responds with a Cancel Location, the message is proxied by the AAAH and transformed into a DIAMETER Session Termination message. It is sent to the old IGSS. The Session Termination Ack triggers a Cancel Location Ack from the AAAH to the HLR with the IMSI parameter. The Insert Subscriber Data message is necessary to confirm that both mobility and authentication were valid in the HLR side. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 18] Internet Draft IGPRS 31 July 2001 5.6. Deleting authentication info When the AAAH is informed of a new IGSS location, it sends a MAP-PROVIDE-SUBSCRIBER-LOCATION message to the HLR. If the HLR is not updated with the correct IGSS/AAAF, an STI message is sent to the old IGSS/AAAF as described earlier. 6. Security Functions and Data Elements GPRS uses Authentication_Request and Response messages to achieve a mutual authentication of the MN and the network. IGPRS proceeds in the same manner. IPv6 AAA [AAA6 ] options are sent during the GPRS authentication. 6.1. Authentication of Subscriber HLR AAAH Old-AAAF New-AAAF --------- ------ -------- ------- + + + +<------ DIAMETER AMRv6 -------+ + + +--- Send Authentication--->+ + + (when the MN is new to the AAAH) +<---Send Authent. Ack------+ + + + + + +------- DIAMETER AMAv6 ------>+ Figure 8: AAAH dialogue with HLR, using MAP messages, for authentication When a mobile node arrives in a new cell (with a new prefix), it will receive the router advertisement encapsulated in the RRC authentication message 7. The challenge is contained in the RRC authentication message. The MN proceeds like in the GSM/GPRS system and uses the K_i to crypt the challenge. It does not trust yet the network. The MN issues a BU encapsulated in the RRC authentication response with the following sub-options: - IMSI, - P-TMSI, Afifi, Perkins, Flinck Expires 30 A 2001 [Page 19] Internet Draft IGPRS 31 July 2001 - P-TMSI signature, - RES and - old prefix. At this time the MN is authenticated from a GPRS point of view but not yet from an IPv6 point of view. The access router should build a DIAMETER AMRv6 message with the following AVPs: - Insert a MN NAI containing the IMSI marked as belonging to the "imsi" realm - (if the MSISDN is used) insert a MN NAI containing the MSISDN in the "msisdn" realm. - Similarly, the P-TMSI should be inserted as a P-TMSI NAI. - The P-TMSI signature should be inserted as a MN-Reg-Request AVP. - The Challenge is inserted in a Nonce AVP. - The Challenge response (RES) is sent in the MN-Reg-Request AVP. MN AR AAAF AAAH HLR --------- ---- ----- ---- --- +<--- RAND ----+ + + + + +-BU (IMSI,PTMSI,RES, -->+ + RAND) +---AMR---->+ + + (when the + + MN is new + to the AAAH) ++---AMR------>+ + Request K_i + Authenticate ++<--AMA-------+ + +<--AMA-----+ +<--------BA(PTMSI,------+ AUTN) Figure 9: AAA Procedure in details Afifi, Perkins, Flinck Expires 30 December 2001 [Page 20] Internet Draft IGPRS 31 July 2001 If the AAAF has already authenticated the MN (it compares the IMSI (or MSISDN), P-TMSI with its local information) it will issue an AMAv6 message to the AR and the AR forwards a Binding Acknowledgement to the MN. If not, the AAAF forwards this information to the AAAH. The AAAH obtains information about the subscriber using the IMSI (or MSISDN). It sends a MAP_Send_Authentication_Info_Request MAP message to the HLR. The HLR responds with an MAP_Send_Authentication_Info_rsp. The AAAH proceeds further and asks for the MN secret key. When the HLR gives back the secret key to the colocated AAAH, the AAAH will be able to apply the secret key on the random number (Nonce or RAND) and to compare it with RES. If this comparison is successful the AAAH proceeds with the HARv6 and AMAv6 messages. If the comparison fails the AAAH sends back a failure to the AAAF as described in the DIAMETER protocol with the Authentication_Failure error. In case of failure the AR sends a Binding Acknowledgement with the status field set to the appropriate error. Upon success, the AAAH sends its AUTN number that enables the MN to verify the network identity. The AAAH sends also the integrity key and cipher key to the AAAF in a AMAv6 message. The AAAF may construct a P-TMSI and a P-TMSI signature. They are forwarded to the AR. The AR constructs a Binding Acknowledgement, inserts the AUTN, P-TMSI and P-TMSI signature. It sends the Binding Acknowledgement to the MN encapsulated in the RRC attach accept (described in Sec. 7.3.4). At this time, the MN can verify the authenticity of the network and continue the connexion. If this not achieved, the MN asks for a Detach procedure. It encapsulates the BU with Lifetime zero and gives the Authentication Error reason in the RRC Detach message. 6.2. P-TMSI Signature P-TMSI Signature is optionally sent by the IGSS to the MN. It consists simply in a random number associated with a terminal and a P-TMSI. The only difference between the P-TMSI and its signature is that the P-TMSI signature is sent inside the ciphered data. Also the couple P-TMSI and P-TMSI Signature are always sent when a secured ciphered channel is established between the MN and the network. If the P-TMSI Signature has been sent by the IGSS to the MN since the current P-TMSI was allocated, then the MN includes the P-TMSI Signature in future Binding Updates for identification checking purposes. The access router forwards this sub-option in the DIAMETER AMR message. In the Routing Update procedure, the IGSS compares the P-TMSI Signature sent by the MN with the signature stored in the IGSS. If the values do not match, the IGSS should send a DIAMETER AMA error to the AR. The AR sends back the Binding Acknowledgement with Authentication error (Status field) to the MN. The P-TMSI Signature Afifi, Perkins, Flinck Expires 30 December 2001 [Page 21] Internet Draft IGPRS 31 July 2001 parameter has significance only to the IGSS that allocated it. All the 3GPP security algorithms are described in [SEC ]. 7. Message Formats This section describes the format for IGPRS messages. We identify IGPRS messages from the MN to AR, from the AR to the IGSS, between IGSS (serving either as AAAF or AAAH) and from the IGSS to the HLR. AAAH translates DIAMETER messages into the MAP protocol. Finally we identify messages from the Home IGSS/AAAH to the home agent. Messages sent from and to the MN are encapsulated in the RRC signalling. We therefore list the main RRC messages that are going to be used during IGPRS exchange. We do not list them exhaustively however. Coding of RRC is described in [24.008 ]. 7.1. List of RRC Messages - Attach Request: This is the first message sent by a MN to access the network. It is accepted or rejected (with the corresponding messages). The authentication should happen before accepting the MN. - Detach Request. It is sent by the MN or by the Network to disconnect the peer. - Routing Area Update. Message sent to update the Reachable timer or to advertise for a movement. - PDP-Activate-Req: To be able to send user data. - Authentication Req: It is sent by the network to request authentication from the MN. 7.2. IMSI/MSISDN transport in NAI The IMSI and P-TMSI are sent in Sub-Options from the MN to the AR, and as an NAI in the DIAMETER messages. The IMSI is a number not more than 15 digits long. The coded form for the IMSI in BU is as follows: 7.3. Messages for an attach procedure: first time All IGPRS Attach messages are encapsulated in RRC Attach messages (MN to AR and AR to MN). As it was previously stated IPv6 ismapped in a Afifi, Perkins, Flinck Expires 30 December 2001 [Page 22] Internet Draft IGPRS 31 July 2001 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sub-Option Type| Sub-Option Len| status| IMSI +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0000 Normal Operation 0001 Attach Confirm Figure 10: Sub-Option Type should contain the IMSI-Attach Type new RRC Information Element Identifier. As described earlier, the attach can happen in these three contexts: first time attach, intra-IGSS attach, and the inter-IGSS attach. We describe the messages sent from and to the MN in the first case. 7.3.1. AR to MN The AAAF sends an Authentication Request to the MN. The AR encapsulates a RA message with the Challenge as described in [AAA6 ]. The MN answers in the Authentication response with the Challenge Response. The IPv6 messages are here and in all the scenarios mapped in RRC messaging with the new IGPRS RRC Information Element Identifier. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 23] Internet Draft IGPRS 31 July 2001 7.3.2. AR to AAAF A DIAMETER message is formed in the AR to the AAAF. ::= [ // IMSI or MSISDN ] //RES(Challenge R* *esponse) [] [] [] [ _ // Old P-TMSI ] // Old Prefix // RAND //P-TMSIsi* *gnature 7.3.3. IGSS to HA and HLR The IGSS acting as AAAF sends through DIAMETER Mobile IP Registration request the received parameters to the AAAH. It is to be noted that for minimizing additional protocol extensions to IGPRS, the RES field is sent in the MIP-Reg-Request AVP. Specifically in the Identification field as shown in the figure ?? . 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification = SRES + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- "caption-"label-fig:diamamr" DIAMETER AMR message format" Afifi, Perkins, Flinck Expires 30 December 2001 [Page 24] Internet Draft IGPRS 31 July 2001 The AAAH sends a Send_Authentication_Info message to the HLR and receives a Send_Authentication_Info_Ack message. The AAAH updates the HA with the new MN address after receiving the confirmation from the HLR through the HARv6 message. ::= ] 7.3.4. AAAH to AAAF IGSS When the HLR sends an answer to the AAAH. It is forwarded to the AAAF with a AA-Mobile-Node-v6-Answer: ::= [] [] [] // New P-TMSI [ // AUTN ] // P-TMSI Signa* *ture AUTN is a way for the MN to verify the network identity. 7.3.5. IGSS to AR The IGSS will generate a new P-TMSI AVP (Section 6.2). 7.3.6. Router Advertisement after Attach The router advertisement should be sent after the IGPRS-ATTACH is accepted. The IPv6 packet is mapped into the ATTACH-ACCEPT RRC message. The IGPRS attach has also the BA containing the P-TMSI and P-TMSI Signature sub-options. All the IPv6 messages coming through the IGPRS MAC layer should contain at least one of these sub-options in order to clarify the nature of the UMTS stratum. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 25] Internet Draft IGPRS 31 July 2001 7.3.7. Messages for attach within the AAA domain The MN uses a P-TMSI and a P-TMSI signature to authenticate itself when it is not the first time attach. This is carried in two separate Sub-Options in BUs. The Sub-Option length should be expressed as in the GPRS [24.008 ] standard. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P-TMSI | Sub-Option Len| padding | octet 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 3 | 4 | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The signature Sub-Option contains hexadecimal code obtained by hashing the P-TMSI and by using the IMSI related secret code algorithms. The Sub-Option length should be expressed in bytes; a typical value is three bytes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P-TMSI Sign | Sub-Option Len| hexadecimal value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When the BU is received in the AR. The IGPRS specific sub-options are extracted. The IMSI, MSISDN and P-TMSI are coded as NAIs as follows: IMSI(in decimal digits notation)@imsi.gprs MSISDN (in decimal)@msisdn.gprs P-TMSI (in hexadecimal)@p-tmsi.gprs 7.3.8. Router Advertisement after Attach The router advertisement should be sent after the IGPRS-ATTACH is accepted. The IPv6 packet is mapped in the RRC GPRS-ATTACH-ACCEPT with the specific Information Element Identifier MIPv6. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 26] Internet Draft IGPRS 31 July 2001 The Valid Lifetime should be set to the Periodic Update time from the RRC layer. 7.3.9. Authentication Error In case of authentication failure or denial of service, the IGSS sends back an Authentication Error Result AVP. It is forwarded in the Binding Acknowledgement with the status field set to Authentication Error. 7.3.10. Detach The MN may detach itself by sending a BU to the HA with Lifetime set to zero. 7.4. Messages for an attach procedure: inter-IGSS 7.4.1. Second Time Attach When the MN has already a valid P-TMSI, it will send it along with the signature in two Sub-Options to the IGSS. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 27] Internet Draft IGPRS 31 July 2001 7.4.2. IGSS Response The response contains the same information as in the first attach, i.e. the P-TMSI and P-TMSI signature. 7.5. Link Layer messages This section describes the procedures that have to be implemented in the MAC layer to fulfill the necessary IGPRS functions. We identify two messages carrying IGPRS signalling. The first is the Activate PDP Context. It is sent simultaneously with the GPRS attach message. It corresponds to the first BU sent from the mobile node. The second is the Routing Area Update Request. It is sent twice from the MN to the Network. In the first Routing Area Update, a normal GPRS message is sent. In the second, the information related to the BU is inserted in the message. Before we give the details of these RRC messages, we have to describe the mapping between Routing Area Identity and IPv6 prefix. 7.5.1. Router Advertisements GPRS information contained in periodic physical layer broadcasts has to be used by the MN in place of IPv6 Router Advertisement messages in IPv6. RAC has hence to be translated into IPv6 prefix. The structure of a Routing Area Identity is defined in [24.008 ] and is as follows. +----------------------------------------------+-------+ | 8 7 6 4 3 2 1 | | |------------------------------------------------------| | Routing Area Identification IEI |octet 1| | MCC digit 2 MCC digit 1 |octet 2| | MNC digit 3 MCC digit 3 |octet 3| | MNC digit 2 MNC digit 1 |octet 4| | LAC |octet 5| | LAC contd |octet 6| | RAC |octet 7| +------------------------------------------------------+ The first BU sent from the node is encapsulated in a ACTIVATE PDP Context message. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 28] Internet Draft IGPRS 31 July 2001 +------------------------------------------+ |IEI Information Element Length| |Protocol discriminator 1/2 | |Transaction identifier 1/2- 3/2| |Activate PDP context req. message id. 1 | |Requested NSAPI 1 | |Requested LLC SAPI 1 | |Requested QoS 12 | |Requested PDP address(Home Address) 17 | |Access point name (BU) 102 | |Protocol configuration options 3-253 | +------------------------------------------+ As we can see from the ACTIVATE PDP CONTEXT message, the BU is inserted in the field usually reserved for a domain name. Additionnally, the Home Address corresponding to the Mobile Node is inserted in the Requested PDP Address. The PDP Type ``IGPRS'' will have to be inserted in the Protocol Configuration Option in order to inform the network that this is not a normal GPRS terminal but one supporting IGPRS specifications. The remaining procedure corresponds to the periodic Routing Area Updates and to Routing Area Updates sent when the MN camps in a new routing are. When the GPRS layers are notified by a change in the Routing Area Identity, a router advertisement is generated locally to inform the IPv6 layer of the change in the routing subnet. This triggres the normal GPRS Routing Area Update Request procedure and triggers the IGPRS Routing Area Request message. Afifi, Perkins, Flinck Expires 30 December 2001 [Page 29] Internet Draft IGPRS 31 July 2001 +---------------------------------------------------------------+ | Field Type Length | | Protocol discriminator 1/2 | | Skip indicator 1/2 | | Routing area update request message identity 1 | | Update type 1/2 | | GPRS ciphering key sequence number 1/2 | | Old routing area identification 6 | | MS Radio Access capability 6-52 | | Old P-TMSI signature 4 | | Requested READY timer value 2 | | DRX parameter 3 | | TMSI status 1 | | P-TMSI Mobile identity 7 | | MS network capability 4/10 | | Access point name (BU) 102 | +---------------------------------------------------------------+ Note also that in the Routing Area Update used for IGPRS, the Update Type is set to IGPRS (bits=111) so that there is no possible confusion with other messages or syntax errors. The BU is sent in the Access point Name field that is not usually used in the routeing area update. 8. Additional Security Considerations The security of IGPRS depends on the security functions provided in Mobile IPv6 as well as the basic security architecture defined for GPRS. References [3gpp] . All the documents and drafts are available at http://www.3gpp.org/3G_Specs/spec_series.htm . [RANAP] 3GPP TS 25.413 V3.3.0 (2000-09). Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu Interface RANAP Signalling (Release 1999). [imsi] . ETSI EN 300 927 V5.4.0 (2000-08) Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification (GSM 03.03 version 5.4.0 Release 1996). Afifi, Perkins, Flinck Expires 30 December 2001 [Page 30] Internet Draft IGPRS 31 July 20* *00 [imsi2] ITU-T Recommendation E.212: "Identification plan for land mobile stations". [SEC] 3GPP TS 33.102 V3.6.0 (2000-10) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 1999). [nai] B. Aboba, M. Beadles. January The Network Access Identifier. RFC 2486. [diammip] . Calhoun, C. Perkins. DIAMETER Mobile IP Extensions. Internet Draft. September 2000. [diam] P. Calhoun, A. Rubens, H. Akhtar. E. Guttman. DIAMETER Base Protocol. Internet Draft. July 2000 [AAA] S. Farrell et Al. "AAA Authorization Requirements," , October 1999. [AUTO] S. Thomson, T. Narten. Request For Comments: 2462. IPv6 Stateless Address Autoconfiguration [GPRS] 3GPP TS 23.060 V3.5.0 (2000-10). Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; Stage 2 (Release 1999). [imsi] SM ETSI TS 100 977 V8.3.0 (2000-08). RTS/SMG-091111Q8R1. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM 11.11 version 8.3.0 Release 1999). [ICMPv6] A. Conta, S. Deering.Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Request for Comments: 2463 [IPv6] B. Hinden, S. Deering. IP Version 6 Addressing Architecture. Request for Comments: 2373. July 1998 [mipv6] D. Johnson, C. Perkins. Mobility Support in IPv6. Internet Draft. 27 April 2000 ETSI ETS 300 599 ed.9 (2000-08) Draft [MAP] 3GPP TS 29.002 V3.6.0 (2000-09)Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Application Part (MAP) specification (Release 1999) Afifi, Perkins, Flinck Expires 30 December 2001 [Page 3* *1] Internet Draft IGPRS 31 October 20* *00 [nd] T. Narten, E. Nordmark, W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments: 2461. December 1998 [24.008] 3GPP TS 24.008 V3.5.0 (2000-09). Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface layer 3 specification; Core Network Protocols - Stage 3 (Release 1999) [rfc2119] S. Bradner Key words for use in RFCs to Indicate Requirement Levels.Request for Comments: 2119. IETF. [diammip] P. Calhoun, C. Perkins. DIAMETER Mobile IPv6 Extensions. Internet Draft. Work in Progress. September 2000. [nasreq] P. Calhoun, W. Bulley, A. Rubens, J. Haag. DIAMETER NASREQ Extensions Internet Draft. IETF. [mipnai] P. Calhoun, C. Perkins. Mobile IP Network Access Identifier Extension for IPv4. Request for Comments: 2794. March 2000 [AAA6] N. Asokan, P. Flykt, C. Perkins, T. Eklund. AAA for IPv6 Network Access. draft-perkins-aaav6-02.txt [MIPCHAP] C. Perkins, P. Calhoun. Mobile IPv4 Challenge/Response Extensions. INTERNET DRAFT June 2000. [IGUA] R. Hinden, M. O'Dell, S. Deering. An IPv6 Aggregatable Global Unicast Address Format. Request for Comments: 2374. [rfc2406] S. Kent, R. Atkinson. Request for Comments: 2406 IP Encapsulating Security Payload (ESP) [imsi] SM ETSI TS 100 977 V8.3.0 (2000-08). RTS/SMG-091111Q8R1. Digital cellular telecommunications system (Phase 2+); Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface (GSM 11.11 version 8.3.0 Release 1999). Afifi, Perkins, Flinck Expires 30 December 2001 [Page 3* *2] Internet Draft IGPRS 31 October 2000 Addresses Questions about this memo can also be directed to the authors: Hossam Afifi Charles E. Perkins INRIA Sophia Antipolis Communications Systems Lab France Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: afifi@sophia.inria.fr EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Hannu Flinck Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2402 EMail: hannu.flinck@nokia.com Fax: +1 650 625-2502 Afifi, Perkins, Flinck Expires 30 December 2001 [Page 33]