Internet DRAFT - draft-ncnipc-savi-sip
draft-ncnipc-savi-sip
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
<Zhang et al.> Expires <February 28, 2013> [Page 1]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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
<Zhang et al.> Expires <February 28, 2013> [Page 2]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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,
<Zhang et al.> Expires <February 28, 2013> [Page 3]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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;
<Zhang et al.> Expires <February 28, 2013> [Page 4]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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)
<Zhang et al.> Expires <February 28, 2013> [Page 5]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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:
<Zhang et al.> Expires <February 28, 2013> [Page 6]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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
<Zhang et al.> Expires <February 28, 2013> [Page 7]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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.
<Zhang et al.> Expires <February 28, 2013> [Page 8]
INTERNET DRAFT SAVI For Session Initiation Protocol <August 28, 2012>
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
<Zhang et al.> Expires <February 28, 2013> [Page 9]
