Session Initiation Protocol (SIP)
Extensions for Blocking VoIP Spam Using PSTN Validationjdrosen.netMonmouthNJUSjdrosen@jdrosen.nethttp://www.jdrosen.netCisco170 West Tasman DriveMS: SJC-21/2San JoseCA95134USA+1 408 421-9990fluffy@cisco.comStonyfishmarc@stonyfish.com
RAI
VIPRVerification Involving PSTN Reachability (ViPR) is a new
technique for inter-domain federation of SIP calls. ViPR makes
use of the PSTN as an introduction mechanism to verify the
correctness of mappings from phone numbers to domains. The PSTN
introduction mechanism can also be used as a technique for
blocking spam - a SIP caller is only authorized when its
calling domain has previously called that same number over the
PSTN. This document describes an extension to SIP which enables
authorization of SIP calls based on a prior PSTN introduction.
This documents and the information contained therein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.The anti-spam tickets described in this specification are the key
security mechanism in ViPR for mitigation of SPAM. The domain
originating a call inserts a ticket in the SIP INVITE sent to the other
domain. The Border Element in the domain receiving the call (see ) can check the ticket to ensure that this
originating domain has been authorized by the terminating domain. This
document relies heavily on the concepts and terminology defined in and will not make
sense if you have not read that document first.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 .The Border Element will receive the TLS ClientHello which begins
the TLS handshake. The Border Element will present its own configured
cert. Once TLS handshaking is complete, the Border Element notes the
domain from the SubjectAltName on the other side of the TLS connection,
and associates it with that connection.Next, the Border Element will receive an INVITE. This INVITE will
contain a ticket in the ViPR-Ticket header field value. The
Border Element extracts this header field. This call flow assumes it is
present. The Border Element parses it, and obtains the epoch value
encoded in the ticket. This is matched against the current epoch value
for the configured password. If they match, processing continues. The
Border Element verifies the signature is correct. Next, it examines the
start and stop time of the validity. If the current time is between the
start and stop times, the check is passed. Next, the Border Element
checks the granted-to domain in the ticket. It compares that domain
against the domain name in the SubjectAltName of the peer on the other
side of the TLS connection, as noted above. Next, it takes the
Request-URI of the SIP INVITE. That will be of the form
sip:+number@domain. If it is not in that form, and if the number does
not begin with a plus, the request is dropped. The value, including the
plus, is then compared to the number in the ticket. If it is equal, the check
has passed. The Border Element leaves the header field in the request,
but forwards to the Call Agent.In addition, the Border Element will typically be configured to apply
its SIP message validation logic, and enforce restrictions on the sizes
of various SIP header fields. This provides an additional layer of
security in case malicious SIP messages are sent.The Border Element will also apply port forwarding in the case of
NAT, so that the incoming request is forwarded to the appropriate Call
Agent node.The Call Agent will receive incoming SIP INVITEs.
The Request-URI of the INVITE will contain an E.164 number as indicated
by a leading plus. If the Request-URI is not an E.164, the request must
be rejected with a 403. Only E.164 numbers can be accepted on a ViPR
trunk.The routes stored to other domains in the Call Agent will each store
a ticket to utilize with calls to that route. The Call Agent learns
about these routes and the information needed to construct the ticket
from the VAP
protocol. When sending a SIP request to one of these domains, the
Call Agent MUST include the ticket in any dialog forming request or
request that is not in an existing dialog. This ticket is a sequence of characters. These MUST be placed into a
ViPR-Ticket SIP header field value. Consequently the format for
this header field is:This header field MUST be utilized in all dialog forming requests and all
out-of-dialog requests. It is not utilized in responses. The
ticket-value is a modified base64 encoded version of an object that is composed
of a series of TLVs. Each TLV is a 16 bit type, a 16 bit length, and a
variable length value. The length field refers to the length of the
value portion of the TLV, measured in bytes. The following TLV types are
defined:Ticket Unique ID: This TLV has a type of 0x0001. It contains a
128 bit ID that has a unique identifier for this ticket. The value
MUST contain a 128 bit UUID defined by . This TLV MUST be present. However at this
time it is used for diagnostic purposes only.Salt: This TLV has a type of 0x0002. It contains a value which
MUST be at least 32 bits, and contains a random number. Its presence
ensures that each ticket contains sufficient randomness. This TLV
MUST be present.Validity: This TLV has a type of 0x0003. It contains two 64 bit
NTP times. The first is the start of the validity of the ticket, the
next is the end time for the validity of the ticket. This TLV MUST
be present.Number: This TLV has a type of 0x0004. It contains a string which
has an E.164 number, included the "+", which may be called using this
ticket. The TLV has variable length. This TLV MUST be present.Granting Node: This TLV has a type of 0x0005. It contains a 128
bit value which is the Node-ID of the node which granted the ticket.
This TLV MUST be present.Granting Domain: This TLV has a type of 0x0006. The domain which
granted the ticket. A string, up to 256 characters, each of which
must be a valid domain name character. The TLV has variable length.
This TLV MUST be present.Granted-To Domain: This TLV has a type of 0x0007. The domain to
which the ticket is granted. A string, up to 256 characters, each of
which must be a valid domain name character. The TLV has a variable
length. This TLV MUST be present.Epoch: This TLV has a type of 0x0008. It contains a 32 bit epoch
value. It is used to select a key. This TLV MUST be present.Integrity: This TLV has a type of 0x0009. It contains a 160 bit
integrity value, computed using HMAC-SHA1. This TLV MUST be
present and MUST be the last TLV in the object.The base64 encoding uses the base64url encoding from RFC4648, with the exception of the pad
character, which is a "." instead of an "=". This ensures that the
output is a valid SIP token.To compute the MAC, the following is done. First, the key is
obtained. The key is actually a 128 bit key, configured into the system.
The key, P, is then used to compute Km:Km = HMAC-SHA1(P, S | Epoch)Based on PBKDF2 from PKCS #5 with
HMAC-SHA1 as PRF and iteration count of 1. Where S is the 32 bit salt
and Epoch is the 32 bit Epoch, from the ticket. This produces a 160 bit
Km. The MAC is then computed as another HMAC-SHA1, over the entire
ticket up to but not including the Integrity itself, using Km as the
key. This produces the 160 bit MAC.TBD
This document defines a new SIP header field: ViPR-Ticket.
Its syntax is defined in .
This header field must be registered by IANA in the SIP Parameters registry under the Header Fields subregistry with the following information:
ViPR-TicketnoneThanks to Patrice Bruno for his comments, suggestions and questions that helped to improve this document.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their 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.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
PKCS #5: Password-Based Cryptography Specification Version 2.0This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information for the Internet community.A Universally Unique IDentifier (UUID) URN NamespaceMicrosoft1 Microsoft WayRedmondWA98052US+1 425-882-8080paulle@microsoft.comRefactored Networks, LLC1635 Old Hwy 41Suite 112, Box 138KennesawGA30152US+1-678-581-9656michael@refactored-networks.comhttp://www.refactored-networks.comDataPower Technology, Inc.1 Alewife CenterCambridgeMA02142US+1 617-864-0455rsalz@datapower.comhttp://www.datapower.comURN, UUIDThis specification defines a Uniform Resource Name namespace for
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
Unique IDentifier). A UUID is 128 bits long, and can
guarantee uniqueness across space and time. UUIDs were originally
used in the Apollo Network Computing System and later in the Open
Software Foundation's (OSF) Distributed Computing Environment (DCE),
and then in Microsoft Windows platforms.This specification is derived from the DCE specification with the
kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been
incorporated into this document.The Base16, Base32, and Base64 Data EncodingsThis document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]Verification Involving PSTN Reachability: Requirements and Architecture OverviewThe Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications. Though it was designed from the outset to support inter-domain federation over the public Internet, such federation has not materialized. The primary reasons for this are the complexities of inter-domain phone number routing and concerns over security. This document reviews this problem space, outlines requirements, and then describes a new model and technique for inter-domain federation with SIP, called Verification Involving PSTN Reachability (ViPR). ViPR addresses the problems that have prevented inter-domain federation over the Internet. It provides fully distributed inter- domain routing for phone numbers, authorized mappings from phone numbers to domains, a new technique for automated VoIP anti-spam, and privacy of number ownership, all while preserving the trapezoidal model of SIP.Verification Involving PSTN Reachability: The ViPR Access Protocol (VAP)Verification Involving PSTN Reachability (ViPR) is a technique for inter-domain SIP federation. ViPR hybridizes the PSTN, P2P networks, and SIP, and in doing so, addresses the phone number routing and VoIP spam problems that have been a barrier to federation. The ViPR architecture uses a server, the ViPR server, which performs P2P and validation services on behalf of call agents, which acts as clients to the server. Such an architecture requires a client/server protocol between call agents and the ViPR server. That protocol, defined here, is called the ViPR Access Protocol (VAP).This section must be removed before publication as an RFC.Renamed Ticket to ViPR-Ticket to synchronize with -overview.Renamed X-Cisco-ViPR-Ticket to Ticket and filled the IANA section.Moved to new Working Group.Added terminology section.NitsShorter I-Ds references.Changed issued-to to granted-to.Fixed the ABNF.The tickets is used in all dialog forming requests, not only INVITE.The Number TLV has a variable length.The Integrity TLV MUST be the last in the object.Fixed a discrepancy in the epoch length.