One document matched: draft-wing-sip-e164-rrc-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY rfc3265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY I-D.ietf-sipping-sbc-funcs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-sbc-funcs.xml">
<!ENTITY I-D.fischer-sip-e2e-sec-media SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fischer-sip-e2e-sec-media.xml">
<!ENTITY ITU.E164.1991 SYSTEM "http://xml.resource.org/public/rfc/bibxml2/reference.ITU.E164.1991.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-sip-e164-rrc-01" ipr="full3978">
<front>
<title abbrev="SIP E.164 RRC">SIP E.164 Return Routability Check (RRC)</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<date year="2008" />
<abstract>
<t>SIP lacks a mechanism to determine which domain can claim ownership
of a certain telephone number. Due to this, it is impossible to
establish meaningful identity or to authenticate endpoints that use
telephone number URIs and domain names in their From address. This document proposes a
solution to this problem using a return routability test.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC3261">SIP</xref> allows using both email-style
addresses (user@domain) and telephone-style addresses (1234@domain). The
latter is most often used with <xref target="ITU.E164.1991">E.164</xref>
numbers (designated with ";user=phone") especially between different administrative domains.</t>
<t>
<!--
As described in <xref
target="I-D.elwell-sip-e164-problem-statement"></xref>,
-->
SIP's use of
E.164 numbers poses several problems. This draft provides a solution to
one of the problems: determining if a domain name rightfully 'owns' an
E.164 phone number. In order to do this, a new SIP request is routed
towards that E.164 and, if it is received by the same domain, that
domain is deemed to 'own' that E.164 number. This is termed a 'return
routability check' (RRC).</t>
<t>The return routability check relies on SIP routing to ascertain which
domain 'owns' a certain E.164 number.</t>
<!--
<t>The return routability check works through <xref
target="I-D.ietf-sipping-sbc-funcs">session border controllers
(SBCs)</xref> between the calling party and the called party, even if
those SBCs modify the domain of the "From:" address to be their domain
-- so long as they route the SIP return routability check (the SUBSCRIBE
request) all the way to the domain that owns the E.164 number, and the
originating domain sent their original request using an SBC-surviving
signature <xref target="I-D.fischer-sip-e2e-sec-media"></xref>.</t>
-->
</section>
<section title="Notational Conventions">
<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="Operation">
<t>In order to check if a domain actually 'owns' the E.164 number it
claims to own, a new SIP request is sent towards that E.164. Upon
receipt of a SIP request conaining an E.164 number in the From address,
the verifying agent in the receiving domain sends a new, out-of-dialog
request (a SUBSCRIBE) towards that E.164 using the verifiering domain's
normal routing rules. This SUBSCRIBE contains a body (with a nonce) that
the verifying domains wants the owner of the E.164 to sign. That SIP
SUBSCRIBE request is routed to the 'owner' of that E.164. Upon receipt
of the SUBSCRIBE, the owner of that E.164 number generates a NOTIFY
request. This is signed, using RFC4474, and sent to the verifying
domain. The verifing domain verifies the signature on the NOTIFY. If it
verified, and if the same public key was used in the original SIP
request and in this NOTIFY, the verifying domain has now verified the
remote domain 'owns' that E.164 number. If a different public key was
used in the original SIP request and in this NOTIFY, the verifying
domain has no verified the remote domain does not own that E.164
number.</t>
<section anchor="sec-verifier-operation" title="Verifier Operation">
<t>Upon receipt of an INVITE where the From: address contains a SIP
URI with an E.164, a Verifier (as defined in <xref
target="RFC4474"></xref>) needs to verify if the signer is authorized
to sign for that domain. To do this, the Verifier has an additional
task: it sends an out of dialog SIP SUBSCRIBE request containing a
random nonce to that E.164, using the Verifier's default SIP routing
rules for routing an E.164 address. The domain that owns the E.164
will sign the nonce and send a NOTIFY request back.</t>
<t>The steps the Verifier uses to perform this operation are:<list
style="numbers">
<t>Strip the domain name of the From: of the incoming INVITE. This
results in a TEL URI. For example, "sip:+14085551234@example.com;user=phone"
is rewritten to "tel:+14085551212".</t>
<t>Rewrite the TEL URI to a SIP URI, following the Verifier's
default routing rules. For example, if outgoing calls are
sent to the service provider example.net, then "tel:+14085551212" is
rewritten to "sip:+14085551212@example.net;user=phone".</t>
<t>Generate a random nonce.</t>
<t>Using the SIP URI constructed in step (2), construct a SIP
SUBSCRIBE message with Request-URI and To headers that use that
SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains the
random nonce in its body as Content-Type
application/return-routability-nonce.</t>
<t>Send the SUBSCRIBE message. This will cause the calling party
to send a NOTIFY.</t>
</list>Upon receipt of the NOTIFY message, the Verifier performs the
following steps:<list style="numbers">
<t>Validate the <xref target="RFC4474"></xref> signature of the
NOTIFY.</t>
<t>Extract the application/return-routability-nonce from the
NOTIFY, and compare it to the nonce that was sent in the
SUBSCRIBE.</t>
<t>Compare the certificate used to sign the NOTIFY is the same
certificate used to sign the original SIP request that it is
attempting to validate with this procedure.<list style="letters">
<t>If they match, the E.164 return routability test has
succeeded.</t>
<t>If they do not match, the E.164 return routability test has
failed.</t>
</list></t>
</list></t>
</section>
<section anchor="sec-authentication-operation"
title="Authentication Service or Calling Endpoint Operation">
<t>The steps described in this section can be performed by the
authentication service or by the calling endpoint.</t>
<t>The authentication service or the calling endpoint, upon receiving
a SUBSCRIBE for the return-routability event package, performs the
following steps:<list style="numbers">
<t>The SUBSCRIBE should be immediately acknowledged with a 200 Ok
message.</t>
<t>A NOTIFY should be immediately created, containing the same
application/return-routability-nonce copied from the SUBSCRIBE.
This NOTIFY contains a To and Request-URI which match the From of
the SUBSCRIBE.</t>
<t>This NOTIFY is sent.</t>
<t>The RFC4474 authentication service, operating at the domain,
will create a signature over the NOTIFY. This is used by the
remote domain's verification service (see <xref
target="sec-verifier-operation"></xref>).</t>
</list></t>
</section>
</section>
<section title="Performance Considerations">
<t>To reduce SUBSCRIBE/NOTIFY traffic, a verifier SHOULD cache
successful and failed return routability checks. Successful checks will
only become unsuccessful if SIP E.164 routing is changed to a different
terminating domain. This only occurs when a domain relinquishes an
E.164, so it is RECOMMENDED that the result of ssuccessful tests be
cached for 24 hours. However, unsuccessful tests could be a result of
misconfiguration and it is useful to re-verify such failures in the
event the misconfiguration is fixed. Thus, it is RECOMMENDED that the
result of unsuccessful tests be cached for 1 hour.</t>
</section>
<section title="Deployment Considerations">
<t>Intermediate SIP elements (proxies, SBCs, B2BUAs) MUST all forward
the application/return-routability-nonce Content-Type.</t>
</section>
<section anchor="sec-security-considerations"
title="Security Considerations">
<t>An attacker could cause a domain to perform public key operations by
sending a bunch of bogus SUBSCRIBE messages. This can be thwarted by
only responding with NOTIFYs if there is an active INVITE dialog.
However, that could disclose information about active calls, and also
restricts the usefulness of this feature to INVITEs. More evaluation of
countermeasures against such an attack is needed.</t>
<t>[[This section will be completed in a later version of this
document.]]</t>
</section>
<section anchor="examples" title="Examples">
<t></t>
<figure anchor="fig-successful-messge-flow"
title="Message Flow -- Return Routability Check Success">
<preamble>Example message flow for a successful return routability
check.</preamble>
<artwork><![CDATA[
Calling Auth. Called
UA Service proxies Verifier UA
------- ------- -------- -------- ------ --------
| | | | | ^
| INVITE | | | | |
|--------->| | | | |
| | | | | |
| (signs request) | | | |
| | | | | |
|100 | INVITE | | | | steps which
|<---------|--------->| | | | are part of
| | | | | | normal RFC4474
| |100 | INVITE | | |
| |<---------|--------->| | |
| | | | | |
| | |100 | | |
| | |<---------| | |
| | | | | |
| | | (validates | |
| | | signature) | V
| | | | | ----------
| | |SUBSCRIBE | |
| | |(containing nonce) |
| |SUBSCRIBE |<---------| |
| |<---------| | |
| | | | |
| |200 Ok | | |
| |--------->|200 Ok | |
| | |--------->| |
| NOTIFY | | | |
| (containing nonce) | | |
| +----| | | |
| | | | | |
| +--->| | | |
| | | | |
| (signs NOTIFY) | | |
| | | | |
| |NOTIFY | | |
| |--------->|NOTIFY | |
| | |--------->| |
| | | | |
| | |200 Ok | |
| |200 Ok |<---------| |
| |<---------| | |
| | | | |
| | | (validates NOTIFY |
| | | signature, and |
| | | checks that same |
| | | cert. signed both |
| | | the INVITE and |
| | | the NOTIFY) |
| | | | |
| | | | INVITE |
| | | |--------->|
| | | | |
| | | | |display e.164
| | | | |------------>
| | | | |
]]></artwork>
<postamble></postamble>
</figure>
<figure anchor="fig-failed-messge-flow"
title="Message Flow -- Return Routability Check Failure">
<preamble>Example message flow for an unsuccessful return routability
check, where the NOTIFY is signed by a different RFC4474
authentication service:</preamble>
<artwork><![CDATA[ Calling E.164
User's Owner's
Calling Auth. Auth. Called
UA Service Service proxies Verifier UA
------- ------- ------- ------- -------- ------
| | | | | |
| INVITE | | | | |
|--------->| | | | |
| | | | | |
| (signs request) | | | |
| | | | | |
|100 | INVITE | | | |
|<---------|-------------------->| | |
| | | | | |
| |100 | | INVITE | |
| |<--------------------|--------->| |
| | | | | |
| | | |100 | |
| | | |<---------| |
| | | | | |
| | | | (validates |
| | | | signature) |
| | | | | |
| | | |SUBSCRIBE | |
| | |SUBSCRIBE |(containing nonce) |
| | |<---------| | |
| | |200 Ok | | |
| | |--------->|200 Ok | |
| | NOTIFY | |--------->| |
| | (containing nonce) | | |
| | +----| | | |
| | | | | | |
| | +--->| | | |
| | | | | |
| | (signs NOTIFY) | | |
| | | | | |
| | |NOTIFY | | |
| | |--------->|NOTIFY | |
| | | |--------->| |
| | | | | |
| | | |200 Ok | |
| | |200 Ok |<---------| |
| | |<---------| | |
| | | | | |
| | | | (NOTIFY validates; |
| | | | however, different |
| | | | cert. was used for |
| | | | INVITE) |
| | | | | |
| | | | | |
| | | | | INVITE |
| | | | |--------->|
| | | | | |
| | | | | |display
| | | | | |e.164
| | | | | |------>
| | | | | |
]]></artwork>
<postamble></postamble>
</figure>
</section>
<section title="IANA Considerations">
<t>IANA is requested to register the following new event package and one
new media type.</t>
<section anchor="sec-event-package" title="Reverse-Route Event Package">
<t>This specification registers an event package, based on the
registration procedures defined in <xref target="RFC3265"></xref>. The
following is the information required for such a registration:</t>
<t>Package Name: reverse-route</t>
<t>Package or Package-Template: This is a package.</t>
<t>Published Specification: <this document>.</t>
<t>Person to Contact: Dan Wing, <dwing@cisco.com></t>
</section>
<section title="The "application/return-routability-nonce" Media Type">
<t>Type name: application </t>
<t>Subtype name: return-routability-nonce</t>
<t>Required parameters: None. </t>
<t>Optional parameters: None. </t>
<t>Encoding considerations: The nonce is primarily binary content.</t>
<t>Security considerations: See <xref
target="sec-security-considerations"></xref> of <this
document>.</t>
<t>Interoperability considerations: See <this document>.</t>
<t>Published specification: <this document></t>
<t>Applications which use this media type: SIP.</t>
<t>Additional information: </t>
<t>Magic number(s): None. </t>
<t>File extension(s): None.</t>
<t>Macintosh File Type Code(s): none.</t>
<t>Person & email address to contact for further information: Dan
Wing <dwing@cisco.com></t>
<t>Intended Usage: COMMON</t>
<t>Author/Change Controller: Dan Wing <dwing@cisco.com></t>
</section>
</section>
<section title="Acknowledgements">
<t>Thanks to Paul Kyzivat and Hannes Tschofenig for their review and
comments on this document. Thanks to Joel Halpern for pointing out
the missing ";user=phone" parameter.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc4474;
&rfc3265;
&rfc3261;
<!--
&I-D.fischer-sip-e2e-sec-media;
-->
<!--
<reference anchor="I-D.elwell-sip-e164-problem-statement">
<front>
<title>SIP E.164 Problem Statement</title>
<author fullname="John Elwell" initials="J" surname="Elwell">
<organization></organization>
</author>
<date day="28" month="January" year="2008" />
<abstract>
<t></t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-elwell-sip-e164-problem-statement-00" />
<format target="http://www.ietf.org/internet-drafts/draft-elwell-sip-e164-problem-statement-00.txt"
type="TXT" />
</reference>
-->
</references>
<references title="Informational References">
<!--
&I-D.ietf-sipping-sbc-funcs;
-->
&ITU.E164.1991;
</references>
<section title="Changes">
<t>[[RFC Editor: Please remove this section prior to publication.]]</t>
<section title="Changes from -00 to -01">
<t><list style="symbols">
<t>Added ";user=phone" to identify E.164 number.</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:05:58 |