One document matched: draft-rosenberg-dispatch-vipr-sip-antispam-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="yes" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-rosenberg-dispatch-vipr-sip-antispam-03"
ipr="trust200902">
<front>
<title abbrev="ViPR SPAM Blocking">Session Initiation Protocol (SIP)
Extensions for Blocking VoIP Spam Using PSTN Validation</title>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization>jdrosen.net</organization>
<address>
<postal>
<street></street>
<city>Monmouth</city>
<region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@jdrosen.net</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>MS: SJC-21/2</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Marc Petit-Huguenin" initials="M."
surname="Petit-Huguenin">
<organization>Stonyfish</organization>
<address>
<email>marc@stonyfish.com</email>
</address>
</author>
<date day="25" month="October" year="2010" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>Verification 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.</t>
</abstract>
<note title="Legal">
<t>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.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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 <xref
target="fig-arch"></xref>) 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 <xref
target="VIPR-OVERVIEW"></xref> and will not make sense if you have not
read that document first.</t>
<figure anchor="fig-arch" title="Architecture ">
<artwork><![CDATA[
+-+ +-+
| | | | +------+
| | +-----| |---|Enroll|
| | | | | +------+
|I| | |I|
|n| +-----+ |n|
VAP |t| | ViPR| |t|
+----------|r|---|Srvr |--|e|-----------------
| |a| | | |r| P2P-Validation
| |n| +-----+ |n|
| |e| |e|
| |t| |t|
+-----+ SIP | | +-----+ | |
| CA |-------|F|---| |--|F| ---------------
+-----+ |i| | | |i| SIP/TLS
. |r| | . | |r|
SIP/ . |e| | | |e|
MGCP/ . |w| | BE | |w|
TDM . |a| | | |a|
. |l| | | |l|
+-----+ |l| | | |l|
| UA |-------| |---| |--| |-----------------
+-----+ | | +-----+ | | SRTP
| | | |
+-+ +-+
| |
+--------------------+-----------------+
|
Single administrative domain
]]></artwork>
</figure>
</section>
<section title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Terminating Side Procedures">
<t>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.</t>
<t>Next, the Border Element will receive an INVITE. This INVITE will
contain a ticket in the X-Cisco-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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Originating Side Procedures">
<t>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 <xref target="VIPR-VAP">VAP protocol</xref>. 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.</t>
</section>
<section title="Tickets">
<t>This ticket is a sequence of characters. These MUST be placed into a
X-Cisco-ViPR-Ticket SIP header field value. Consequently the format for
this header field is:</t>
<figure>
<artwork><![CDATA[Ticket = "X-Cisco-ViPR-Ticket" HCOLON ticket-val
ticket-val = 1*(alphanum / "-" / "_" / ".")
]]></artwork>
</figure>
<t></t>
<t>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:</t>
<t><list style="numbers">
<t>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 <xref
target="RFC4122"></xref>. This TLV MUST be present. However at this
time it is used for diagnostic purposes only.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>The base64 encoding uses the base64url encoding from <xref
target="RFC4648">RFC4648</xref>, with the exception of the pad
character, which is a "." instead of an "=". This ensures that the
output is a valid SIP token.</t>
<t>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:</t>
<t>Km = HMAC-SHA1(P, S | Epoch)</t>
<t>Based on PBKDF2 from <xref target="RFC2898">PKCS #5</xref> 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.</t>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD - Register SIP Header</t>
<t>TBD - Form IANA registry for Ticket TLVs</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Patrice Bruno for his comments, suggestions and questions
that helped to improve this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>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: <list>
<t>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.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14" />
<seriesInfo name="RFC" value="2119" />
<format octets="4723"
target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT" />
<format octets="17491"
target="http://xml.resource.org/public/rfc/html/rfc2119.html"
type="HTML" />
<format octets="5777"
target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
type="XML" />
</reference>
<reference anchor="RFC2898">
<front>
<title>PKCS #5: Password-Based Cryptography Specification Version
2.0</title>
<author fullname="B. Kaliski" initials="B." surname="Kaliski">
<organization></organization>
</author>
<date month="September" year="2000" />
<abstract>
<t>This 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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2898" />
<format octets="68692"
target="http://www.rfc-editor.org/rfc/rfc2898.txt" type="TXT" />
</reference>
<reference anchor="RFC4122">
<front>
<title abbrev="UUID URN">A Universally Unique IDentifier (UUID) URN
Namespace</title>
<author fullname="Paul J. Leach" initials="P." surname="Leach">
<organization>Microsoft</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country>
</postal>
<phone>+1 425-882-8080</phone>
<email>paulle@microsoft.com</email>
</address>
</author>
<author fullname="Michael Mealling" initials="M." surname="Mealling">
<organization>Refactored Networks, LLC</organization>
<address>
<postal>
<street>1635 Old Hwy 41</street>
<street>Suite 112, Box 138</street>
<city>Kennesaw</city>
<region>GA</region>
<code>30152</code>
<country>US</country>
</postal>
<phone>+1-678-581-9656</phone>
<email>michael@refactored-networks.com</email>
<uri>http://www.refactored-networks.com</uri>
</address>
</author>
<author fullname="Rich Salz" initials="R." surname="Salz">
<organization>DataPower Technology, Inc.</organization>
<address>
<postal>
<street>1 Alewife Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country>
</postal>
<phone>+1 617-864-0455</phone>
<email>rsalz@datapower.com</email>
<uri>http://www.datapower.com</uri>
</address>
</author>
<date month="July" year="2005" />
<keyword>URN, UUID</keyword>
<abstract>
<t>This 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.</t>
<t>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.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4122" />
<format octets="59319"
target="http://www.rfc-editor.org/rfc/rfc4122.txt" type="TXT" />
<format octets="82717"
target="http://xml.resource.org/public/rfc/html/rfc4122.html"
type="HTML" />
<format octets="62931"
target="http://xml.resource.org/public/rfc/xml/rfc4122.xml"
type="XML" />
</reference>
<reference anchor="RFC4648">
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname="S. Josefsson" initials="S." surname="Josefsson">
<organization></organization>
</author>
<date month="October" year="2006" />
<abstract>
<t>This 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]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4648" />
<format octets="35491"
target="http://www.rfc-editor.org/rfc/rfc4648.txt" type="TXT" />
</reference>
<reference anchor="VIPR-OVERVIEW">
<front>
<title>Verification Involving PSTN Reachability: Requirements and
Architecture Overview</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<author fullname="Marc Petit-Huguenin" initials="M."
surname="Petit-Huguenin">
<organization></organization>
</author>
<date day="17" month="October" year="2010" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>The 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.</t>
</abstract>
<note title="Legal">
<t>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.</t>
</note>
</front>
<seriesInfo name="Internet-Draft"
value="draft-rosenberg-dispatch-vipr-overview-04" />
<format target="http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-overview-04.txt"
type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="VIPR-VAP">
<front>
<title>Verification Involving PSTN Reachability: The ViPR Access
Protocol (VAP)</title>
<author fullname="Jonathan Rosenberg" initials="J.R."
surname="Rosenberg">
<organization></organization>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization></organization>
</author>
<author fullname="Marc Petit-Huguenin" initials="M."
surname="Petit-Huguenin">
<organization></organization>
</author>
<date day="17" month="October" year="2010" />
<area>RAI</area>
<workgroup>dispatch</workgroup>
<abstract>
<t>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).</t>
</abstract>
<note title="Legal">
<t>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.</t>
</note>
</front>
<seriesInfo name="Internet-Draft"
value="draft-rosenberg-dispatch-vipr-vap-03" />
<format target="http://www.ietf.org/internet-drafts/draft-rosenberg-dispatch-vipr-vap-03.txt"
type="TXT" />
</reference>
</references>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
<section title="Modifications between rosenberg-03 and rosenberg-02">
<t><list style="symbols">
<t>Added terminology section.</t>
<t>Nits</t>
<t>Shorter I-Ds references.</t>
<t>Changed issued-to to granted-to.</t>
<t>Fixed the ABNF.</t>
<t>The tickets is used in all dialog forming requests, not only
INVITE.</t>
<t>The Number TLV has a variable length.</t>
<t>The Integrity TLV MUST be the last in the object.</t>
<t>Fixed a discrepancy in the epoch length.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:10:12 |