INTERNET-DRAFT Yuqing Zhang, Gefei Zhang Intended Status: Standard Track NCNIPC,GUCAS Expires: February 28, 2013 August 28,2012 SAVI for Session Initiation Protocol draft-ncnipc-savi-sip-00 Abstract The session initiation protocol(SIP) which designed by IETF is also being considered as the core protocol for multimedia communication. This document describes a source address validation Improvement(SAVI) solution for SIP protocol or other security mechanisms. The SAVI was developed to prevent IP source address spoofing which can enable impersonation and malicious traffic redirection. The SAVI can be used in both IPV4/V6 networks. In the work we presented here, we describe the advantages of using SAVI in SIP and the approaches for using SIP in networks, whether in the registrar, redirect, and any procedures of the SIP protocol .This document describes different deployment scenarios, with solutions for when the nodes in the network using the SIP to contact each other. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Expires [Page 1] INTERNET DRAFT SAVI For Session Initiation Protocol Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License." This document may contain material from IETF Documents or IETF Contributions published or made publicly available before August 23rd 2012. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Conventions used in this document . . . . . . . . . . . . . . . 3 3 Overview of SIP . . . . . . . . . . . . . . . . . . . . . . . . 3 4 Requirements and solutions for SAVI in SIP . . . . . . . . . . 4 4.1 The communication users in the same domain: . . . . . . . . 4 4.2 The communication users in different domains: . . . . . . . 5 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 7.2 Informative References . . . . . . . . . . . . . . . . . . 8 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Expires [Page 2] INTERNET DRAFT SAVI For Session Initiation Protocol 1 Introduction This document describes a mechanism to perform IP source address validation in SIP. This mechanism performs SAVI to authenticate the registration, the redirect and some special circumstances when the SIP protocols is executing. The SAVI can prevent IP source address spoofing which can enable impersonation and malicious traffic redirection. So that the mechanism can check the source IP address of the nodes in SIP protocol, according to the mechanism we can keep the safety of dynamic configuration and any cast in the SIP. There are three main scenarios for different address assignment mechanisms in this document. The mechanism is deployed on different devices in different scenarios. The deployment detail is described in the document. When the nodes starts to execute the SIP protocol, it may call SAVI in different procedures according to the specific mobility scenario. The mechanism to handle the calling is specified in the document according to different deployment scenarios. 2 Conventions used in this document 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]. 3 Overview of SIP The main operation of SIP is inviting a new user to a call. There are several following entities for SIP: Proxy Server: receives a request and then transfer it to the current location of the caller directly, if there is another server which can have more information for the actual location of the caller, the proxy transfer request to that server. Redirect Server: A redirect server receives the request and informs the caller about the next hop server. The caller then contacts the next hop server directly. User Agent Server: A terminal equipment which be seen both as a user agent client and a user agent server; When it acts as a user agent client, the client sends message according to the users actions ; When it acts as a user agent server, the server receives the messages and can decide what to do with it, then it tells users to accept, Expires [Page 3] INTERNET DRAFT SAVI For Session Initiation Protocol reject or forward the message and sending the response back to the caller. Registrar Server: The server is used as a database which contains locations and the user preferences indicated by the user agents. And it will search the users IP address and other relevant information. SAVI MIB module (SAVI-MIB) is conformant to SAVI protocol, and is designed to: 1.Support centralized management and monitoring of SAVI protocol instance by standard SNMP protocol. 2.Support configuration and querying of SAVI protocol parameters. 3.Support configuration and querying of binding entries. Operators may insert and delete static binding entries. 4.Support querying of filtering entries. 4 Requirements and solutions for SAVI in SIP There are two transaction manners of SIP protocol, in the same domain and in different domains. We will define SAVI application for both of situations. We also use the following tables: the SAVI Filtering Table, the SAVI System Table, the SAVI binding table, the SAVI port table. 4.1 The communication users in the same domain: There will be six steps for the establish of a communication: Step 1: The users register their information and IP address in registrar server;(By using the saviObjectsPortIPVersion, saviObjectsPortIfIndex) Step 2: The user A sends a REQUEST to the proxy server to contact user B;(By using the saviObjectsBindingMacAddr, saviObjectsBindingState, saviObjectsBindingLifetime) Step 3: The proxy server sends a REQUEST to the registrar server to get the IP address and information of B and gets the IP address of B; Step 4: The proxy server forwards INVITE of A and B; Expires [Page 4] INTERNET DRAFT SAVI For Session Initiation Protocol Step 5: B sends a RESPONSE to proxy server to ACCEPT the INVITE; Step 6: The proxy server transfers the message to A and build the session. From the Steps above: the source address validation Improvement(SAVI) solution could be used in all the IP address verification for SIP. (By using the saviObjectsBindingMacAddr, saviObjectsBindingState, saviObjectsBindingLifetime) In Step 3, we describe source address validation procedure in it like this: In this procedure, the IP addresses are assumed to have passed the verifications of the register server or other security mechanisms. It has the following steps: 1. Extract the IP address source(from the function: saviObjectsFilteringIpAddress, also testing the saviObjectsPortValidationStatus to support the configuration and collection of SAVI parameters) and MAC source(from the function: saviObjectsFilteringMacAddr) from the registrar server. Test if the MAC address in the MAC-IP Mapping Table exists in the MAC-IP pair(by checking saviObjectsPortValidationStatus, saviObjectsPortDhcpTrustStatus, saviObjectsBindingIpAddress, saviObjectsBindingMacAddr, saviObjectsBindingRowStatus). If it does, forwards the packet. Or else, go to next step. 2. Lookup the IP address source in the IP-MAC Mapping Table and check if the IP address exists. If yes, compare the MAC address source in the entry and the MAC address in the registrar server(from the function: saviObjectsBindingTable) ; If no, insert a new entry into the IP-MAC Mapping Table and forward the registrar server, compare the MAC again. If yes, forward the packet. Else drop the registrar server. The functions using in the above also contains the functions in the following tables: saviObjectsSystemTable; saviObjectsPortTable; saviObjectsBindingTable; saviObjectsFilteringTable. 4.2 The communication users in different domains: There will be nine steps for the establish of a communication: Step 1: The users register their information and IP address in registrar server; (By using the saviObjectsPortIPVersion, saviObjectsPortIfIndex) Step 2: The user A sends a REQUEST to the proxy server of domain A to contact user B; (By using the saviObjectsBindingMacAddr, saviObjectsBindingState, saviObjectsBindingLifetime) Expires [Page 5] INTERNET DRAFT SAVI For Session Initiation Protocol Step 3: The proxy server inquiries the IP address and information of B on the redirect server(the redirect server may in domain A or domain B or domain A and B); Step 4: The redirect server sends the IP address and other information of B to the proxy server; Step 5: The proxy server gets the IP address of B; Step 6: The proxy server forwards INVITE of A to the proxy server of domain B; Step 7: B sends a RESPONSE to proxy server of domain B to ACCEPT the INVITE; (By using the saviObjectsBindingMacAddr, saviObjectsBindingState, saviObjectsBindingLifetime) Step 8: The proxy server of domain B transfers the RESPONSE to proxy server of domain A; (By using the saviObjectsBindingMacAddr, saviObjectsBindingState, saviObjectsBindingLifetime) Step 9: The proxy server of domain A forwards the RESPONSE to A and builds the session. (By using the saviObjectsBindingMacAddr, saviObjectsBindingState, saviObjectsBindingLifetime) From the Steps above: the source address validation Improvement(SAVI) solution could be used in all the IP address verification for SIP. In Step 4 and 5, we describe source address validation procedure in it like this: In this procedure, the IP addresses are assumed to have passed the verifications of the register server or other security mechanisms. It has the following steps: 1. Extract the IP address source and MAC source from the registrar server. Test if the MAC address in the MAC-IP Mapping Table exists in the MAC-IP pair. If it does, forwards the packet. Or else, go to next step. 2. Lookup the IP address source in the IP-MAC Mapping Table and check if the IP address exists. If yes, compare the MAC address source in the entry and the MAC address in the registrar server; If no, insert a new entry into the IP-MAC Mapping Table and forward the registrar server, compare the MAC again. If yes, forward the packet. Else drop the registrar server. In Step 3, we describe source address validation procedure in redirect server like this: In this procedure, the IP address is assumed to have passed the verifications of the redirect server or other security mechanisms. It has the following steps: Expires [Page 6] INTERNET DRAFT SAVI For Session Initiation Protocol 1. Extract the IP address source (from the function: saviObjectsFilteringIpAddress, also testing the saviObjectsPortValidationStatus to support the configuration and collection of SAVI parameters) and MAC source (from the function: saviObjectsFilteringMacAddr) from the redirect server. Test if the MAC address in the MAC-IP Mapping Table exists in the MAC-IP pair(by checking saviObjectsPortValidationStatus, saviObjectsPortDhcpTrustStatus, saviObjectsBindingIpAddress, saviObjectsBindingMacAddr, saviObjectsBindingRowStatus). If it does, forwards the packet. Or else, go to next step. 2. Lookup the IP address source in the IP-MAC Mapping Table and check if the IP address exists. If yes, compare the MAC address source in the entry and the MAC address in the redirect server(from the function: saviObjectsBindingTable); If no, insert a new entry into the IP-MAC Mapping Table and forward the redirect server, compare the MAC again. If yes, forward the packet. Else drop the redirect server. The functions using in the above also contains the functions in the following tables: saviObjectsSystemTable; saviObjectsPortTable; saviObjectsBindingTable; saviObjectsFilteringTable. 5 Security Considerations The security of address allocation methods matters the security of this mechanism. Thus it is necessary to improve the security of stateless auto-configuration and DHCP firstly. 6 IANA Considerations There is no IANA Consideration currently. 7 References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, April 1 1995. [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, April 1 1996. [RFC3979] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. [RFC4879] Narten, T., "Clarification of the Third Party Expires [Page 7] INTERNET DRAFT SAVI For Session Initiation Protocol DisclosureProcedure in RFC 3979", BCP 79, RFC 4879, April 2007. 7.2 Informative References [RFC4862] Thomson, S., Narten, T. and Jinmei, T., "IPv6 Stateless Autoconfiguration", RFC4862, September, 2007. [RFC3315]R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC3315, July, 2003. [RFC1883]S. Deering, R. Hinden: "Internet Protocol Version 6",RFC 1883, IETF, Dec. 1995. [RFC3261]J. Rosenberg, H. Schulzrinne, G. Camarillo, A.Johnston, J. Peterson, R. Sparks, M. Handley, E.Schooler: "SIP: Session Initiation Protocol", RFC3261, IETF, June 2002 [RFC3363]R. Bush, A. Durand, B. Fink, O.Gudmundsson, T.Hain: "Representing Internet Protocol version 6(IPv6) Addresses in the Domain Name System(DNS)", RFC 3363, IETF, August 2002 [RFC1933]R. Gilligan, E. Nordmark, :" Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, IETF, April 1996 [RFC2663]P. Srisuresh, M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999 [I-D.ietf-savi-framework]Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, "Source Address Validation Improvement Framework", draft-ietf-savi-framework-04 (work in progress), March 2011. [I-D.ietf-savi-mix]Jun Bi, Guang Yao, J. Halpern and E. Levy- Abegnoli, "SAVIfor Mixed Address Assignment Methods Scenario", draft-ietfsavi-mix-00 (work in progress), March 2011. [I-D.ietf-savi-mib]C. An, J. Yang, J. Wu, J. Bi. "Definition of Managed Objects for SAVI Protocol", draft-an-savi-mib- 02(work in progress), December 2011. Expires [Page 8] INTERNET DRAFT SAVI For Session Initiation Protocol 8. Authors' Addresses Yuqing Zhang National Computer Network Intrusion Protection Center Graduate University of the Chinese Academy of Sciences, Beijing, 100049 P.R. China E-Mail: zhangyq@nipc.org.cn Gefei Zhang National Computer Network Intrusion Protection Center Graduate University of the Chinese Academy of Sciences, Beijing, 100049 P.R. China E-Mail: zhanggf@nipc.org.cn Expires [Page 9]