One document matched: draft-niccolini-speermint-voipthreats-03.xml
<?xml version="1.0"?>
<?rfc strict="yes"?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-speermint-terminology PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-speermint-terminology.xml'>
<!ENTITY I-D.ietf-speermint-requirements PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-speermint-requirements.xml'>
<!ENTITY rfc2617 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY rfc2827 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2827.xml'>
<!ENTITY rfc3237 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3237.xml'>
<!ENTITY rfc3323 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml'>
<!ENTITY rfc3324 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3324.xml'>
<!ENTITY rfc3325 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
<!ENTITY rfc3711 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml'>
<!ENTITY rfc3893 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3893.xml'>
<!ENTITY rfc4033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4034.xml'>
<!ENTITY rfc4035 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml'>
<!ENTITY rfc4474 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY rfc4475 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4475.xml'>
]>
<rfc ipr="full3978" category="info">
<front>
<title abbrev="SPEERMINT Security BCPs">SPEERMINT Security BCPs</title>
<author initials="S." surname="Niccolini" fullname="Saverio Niccolini">
<organization abbrev="NEC">Network Laboratories, NEC Europe Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 118</phone>
<email>saverio.niccolini@netlab.nec.de</email>
<uri>http://www.netlab.nec.de</uri>
</address>
</author>
<author initials="E." surname="Chen" fullname="Eric Chen">
<organization abbrev="NTT">Information Sharing Platform Laboratories, NTT</organization>
<address>
<postal>
<street>3-9-11 Midori-cho</street>
<city>Musashino, Tokyo</city>
<code>180-8585</code>
<country>Japan</country>
</postal>
<email>eric.chen@lab.ntt.co.jp</email>
<uri>http://www.ntt.co.jp/index_e.html</uri>
</address>
</author>
<author initials="J." surname="Seedorf" fullname="Jan Seedorf">
<organization abbrev="NEC">NEC Laboratories Europe, NEC Europe
Ltd.</organization>
<address>
<postal>
<street>Kurfuersten-Anlage 36</street>
<city>Heidelberg</city>
<code>69115</code>
<country>Germany</country>
</postal>
<phone>+49 (0) 6221 4342 221</phone>
<email>seedorf@nw.neclab.eu</email>
<uri>http://www.nw.neclab.eu</uri>
</address>
</author>
<date year="2008"/>
<area>Real-time Applications and Infrastructure</area>
<workgroup>SPEERMINT Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>VoIP</keyword>
<keyword>Security</keyword>
<keyword>Threats</keyword>
<abstract>
<t>This memo presents the different security threats related to SPEERMINT classifying
them into threats to the Location Function, to the Signaling Function and to the Media
Function. The different instances of the threats are briefly introduced inside the
classification. Finally the existing security solutions in SIP and RTP/RTCP are presented
to describe the countermeasures currently available for such threats. The objective of
this document is to identify and enumerate the SPEERMINT-specific threat vectors in
order to specify security-related requirements. Once the requirements are identified,
methods and solutions how to achieve such requirements can be selected.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> With VoIP, the need for security is compounded because there is the need to protect
both the control plane and the data plane. In a legacy telephone system, security is a
more valid assumption. Intercepting conversations requires either physical access to
telephone lines or to compromise the Public Switched Telephone Network (PSTN) nodes or
the office Private Branch eXchanges (PBXs). Only particularly security-sensitive
organizations bother to encrypt voice traffic over traditional telephone lines. In
contrast, the risk of sending unencrypted data across the Internet is more significant
(e.g. DTMF tones corresponding to the credit card number). An additional security threat
to Internet Telephony comes from the fact that the signaling is sent using the same
network as the multimedia data; traditional telephone systems have the signaling network
separated from the data network. This is an increased security threat since a hacker
could attack the signaling network and its servers with increased damage potential (call
hijacking, call drop, DoS attacks, etc.). Therefore there is the need of investigating
the different security threats, to extract security-related requirements and to highlight
the solutions how to protect from such threats.</t>
</section>
<section anchor="taxonomy" title="Security Threats relevant to SPEERMINT">
<t>This section enumerates potential security threats relevant to SPEERMINT. A
taxonomy of VoIP security threats is defined in <xref target="refs.voipsataxonomy"/>.
Such a taxonomy is really comprehensive and takes into account also non-VoIP-specific
threats (e.g. loss of power, etc.). Threats relevant to the boundaries of layer-5 SIP
networks are extracted from such a taxonomy and mapped to the classification relevant
for the SPEERMINT architecture as defined in <xref target="refs.speermintarch"/>,
moreover additional threats for the SPEERMINT architecture are listed and detailed
under the same classification and according the CIA (Confidentiality, Integrity and
Availability) triad:
<list style="symbols">
<t> Look-Up Function (LUF);</t>
<t> Location Function (LF);</t>
<t> Signaling Function (SF);</t>
<t> Media Function (MF).</t>
</list>
</t>
<section anchor="lookup" title="Threats Relevant to the Look-Up Function (LUF)">
<t>This is one of the latest additions of the terminology draft
<xref target="I-D.ietf-speermint-terminology"/>. LUF is vulenrable to the same
threats that affect database systems in general.</t>
<section anchor="lufConf" title="Threats to LUF Confidentiality">
<t>
<list style="symbols">
<t> SIP URIs and peering domains harvesting - an attacker can exploit
this weakness if the underlying database has a weak authentication
system, and then use the gained knowledge to launch other kind of
attacks.</t>
</list>
</t>
</section>
<section anchor="lufInt" title="Threats to LUF Integrity">
<t> The underlying database could be vulnerable to:
<list style="symbols">
<t> Injection attack - an attacker could manipulate statements
performed on the database by the end user.</t>
</list>
</t>
</section>
<section anchor="lufAva" title="Threats to LUF Availability">
<t> The underlying database could be vulnerable to:
<list style="symbols">
<t> Denial of Service attacks - e.g. an attacker makes incomplete requests
causing the server to create an idle state for each of them causing memory
to be exhausted.</t>
</list>
</t>
</section>
</section>
<section anchor="location" title="Threats Relevant to the Location Function (LF)">
<section anchor="locConf" title="Threats to LF Confidentiality">
<t>
<list style="symbols">
<t> URI harvesting - the attacker harvests URIs and IP addresses of the existing
User Endpoints (UEs) by issuing a multitude of location requests. Direct intrusion
against vulnerable UEs or telemarketing are possible attack scenarios that would use
the gained knowledge.
</t>
<t> SIP device enumeration - the attacker discovers the IP address of each intermediate
signaling device by looking at the Via and Record-Route headers of a SIP message. Targeting
the discovered devices with subsequent attacks is a possible attack scenario.
</t>
</list>
</t>
</section>
<section anchor="locInt" title="Threats to LF Integrity">
<t> Bogus information can be accepted by LF if specific flaws are exploited (e.g. if the
LF involves a Location Server, LS, that does not correctly validate routing data such as NAPTR records,
then the LS may develop incorrect Session Establishment Data, SED). Dynamic call routing discovery and
establishment, as in scope of SPEERMINT, introduces new opportunities for such an attack. In the following
two example variants of such an attack are listed.
<list style="symbols">
<t> Man-in-the-Middle attack - the attacker has already or inserts an unauthorized node
in the signaling path modifying the SED. The results is that the attacker is then able
to read, insert and modify the multimedia communications.</t>
<t> Incorrect destinations - the attacker redirect the calls to a incorrect destination with the
purpose of establishing fraud communications like voice phishing or DoS attacks.</t>
</list>
</t>
</section>
<section anchor="locAvl" title="Threats to LF Availability">
<t> The LF can be object of DoS attacks. DoS attacks to the LF can be carried out by sending a large
number of queries to the LS or Session Manager, SM, with the result of preventing an originating SSP
from looking up call routing data of any URI outside its administrative domain. As an alternative
the attacker could target the DNS to disable resolution of SIP addresses.</t>
</section>
</section>
<section anchor="signaling" title="Threats to the Signaling Function (SF)">
<t> Signaling function involves a great number of sensitive information. Through signaling
function, user agents (UA) assert identities and VSP operators authorize billable
resources. Correct and trusted operations of signaling function is essential for
service providers. This section discusses potential security threats to the signaling
function to detail the possible attack vectors.</t>
<section anchor="sfConf" title="Threats to SF Confidentiality">
<t>SF traffic is vulnerable to eavesdropping, in particular when the data is moved across
multiple SSPs having different levels of security policies. Threats for the SF confidentiality
are listed here:
<list style="symbols">
<t>call pattern analysis - the attacker tracks the call patterns of the users
violating his/her privacy (e.g. revealing the social network of various users, the
daily phone usage, etc.), also rival SSPs may infer information about the customer
base of other SSPs in this way;</t>
<t>Password cracking - challenge-response authentication mechanism of SIP is not secure
if the attacker is able to eavesdrop a sufficient number of SIP authentication messages
exchanged between a SIP server and a SIP client.</t>
</list>
</t>
</section>
<section anchor="sfInt" title="Threats to SF Integrity">
<t>The integrity of the SF can be violated using SIP request spoofing, SIP reply spoofing
and SIP message tampering.</t>
<section title="SIP Request Spoofing">
<t>Most SIP request spoofing require first a SIP message eavesdropping but some of the
them could be also performed by guessing or exploiting broken implementations. Threats
in this category are:
<list>
<t>session tear down - the attacker uses CANCEL/BYE messages in order to tear
down an existing call at SIP layer, it is needed that the attacker replicates
the proper SIP header for the hijacking to be successful (To, From, Call-ID,
CSeq);</t>
<t>REGISTER spoofing - the attacker forges a REGISTER request and register a bogus
contact information with the objective of hijacking incoming calls.</t>
<t>Billing fraud - the same attack as in the case of the REGISTEr spoofing may lead
an attacker to be able to direct billing for calls to the victim UE and avoid
paying for the phone calls;</t>
<t>user ID spoofing - SSPs are responsible for asserting the legitimacy of user ID;
if an SSP fails to achieve the level of identity assertion that the federation it
belongs expects, it may create an entry point for attackers to conduct user ID spoofing
attacks.</t>
</list>
</t>
</section>
<section title="SIP Reply Spoofing">
<t>Threats in this category are:
<list>
<t>Forget 200 Response - the attacker sends a forged CANCEL request to terminate a
call in progress tricking the terminating UE to believe that the originating UE
actually sent it, and successfully hijacks a call sending a forged 200 OK message to
the originating UE communicating the address of the rogue UE under the attacker's
control;</t>
<t>Forget 302 Response - the attacker sends a forged "302 Moved Temporarily" reply
instead of a 200 OK, this enables the attack to hijack the call and to redirect it
to any destination UE of his choosing;</t>
<t>Forget 404 Response - the attacker sends a forged "404 Not Found" reply
instead of a 200 OK, this enables the attack to disrupt the call establishment;</t>
</list>
</t>
</section>
<section title="SIP Message Tampering">
<t>This threat involves the alternation of important field values in a SIP message or in the SDP
body. Examples of this threat could be the dropping or modification of handshake packets
in order to avoid the establishment of a secure RTP session (SRTP). The same approach could be
used to degrade the quality of media session by letting UE negotiate a poor quality codec.</t>
</section>
</section>
<section anchor="sfAvl" title="Threats to SF Availability">
<t>
<list style="symbols">
<t>Flooding attack - a SBE is susceptible to message flooding attack that may come from
interconnected SSPs;</t>
<t>Session Black Holing - the attacker (assumed to be able to make Man-in-the-Middle attacks)
intentionally drops essential packets, e.g. INVITEs, to prevent certain calls from being
established;</t>
<t>SIP Fuzzing attack - fuzzing tests and software can be used by attackersto discover and
exploit vulnerabilities of a SIP entity, this attack may result in crashing SIP entity.</t>
</list>
</t>
</section>
</section>
<section anchor="media" title="Threats to the Media Function (MF)">
<t> The Media function (MF) is responsible for the actual delivery of multimedia comunication
between the users and carries sensitive information. Through media function, UE
can establish secure communications and monitor quality of conversations.
Correct and trusted operations of MF is essential for privacy and service
assurance issues. This section discusses potential security threats to the MF
to detail the possible attack vectors.</t>
<section anchor="mfConf" title="Threats to MF Confidentiality">
<t>The MF is vulnerable to eavesdropping in which the attacker may reconstruct the
voice conversation or sensitive information (e.g. PIN numbers from DTMF tones).
SRTP and ZRTP are vulnerable to bid-down attacks, i.e. by selectively dropping
key exchange protocol packets may result in the establishment of a non-secure
communications.</t>
</section>
<section anchor="mfInt" title="Threats to MF Integrity">
<t>Both RTP and RTCP are vulnerable to integrity violation in many ways:
<list style="symbols">
<t>Media Hijack - if an attacker can somehow detect an ongoing media session and
eavesdrop a few RTP packets, he can start sending bogus RTP packets to one of the
UEs involved using the same codec. As illustrated in Fig. 8, if the bogus RTP
packets have consistently greater timestamps and sequence numbers (but within the
acceptable range) than the legitimate RTP packets, the recipient UE may accept the
bogus RTP packets and discard the legitimate ones.</t>
<t>Media Session Tear Down - the attacker sends bogus RTCP BYE messages to a target
UE signaling to tear down the media communication, please note tha tRTCP messages
are normally not authenticated.</t>
<t>QoS degradation - the attacker sends wrong RTCP reports advertising more packet
loss or more jitter than actually experimented resulting in the usage of a poor
quality codec degrading the overall quality of the call experience.</t>
</list>
</t>
</section>
<section anchor="mfAvl" title="Threats to MF Availability">
<t>
<list style="symbols">
<t>Malformed messages - the attacker tries to cause a crash or a
reboot of the DBE/UE by sending RTP/RTCP malformed messages;</t>
<t>Messages flooding - the attacker tries to exhaust the resources of
the DBE/UE by sending many RTP/RTCP messages.</t>
</list>
</t>
</section>
</section>
</section>
<section anchor="requirements" title="Security Best Practices">
<t>This section describes implementer-specific BCPs to supplement the security requirements described in
<xref target="I-D.ietf-speermint-requirements"/>. The BCPs are first described and then mapped to threats
indicating whic BCPs are recommended to be used in order to solve which threats.</t>
<section title="Database BCPs">
<t>Adequate security measures must be applied to the LUF to prevent it from being target of attacks
since it involves the use of common database systems. Common security BCPs for database include system
replication to prevent any database from being a single point of failure, and the use of parameterized
statements to prevent SQL injections. <xref target="refs.dbsec"/> is one of many existing literatures
that describe BCPs in this area.</t>
</section>
<section title="DNSSEC">
<t>In the case DNS is used by the LF, it is recommended to deploy the recent version of Domain Name System
Security Extensions (informally called "DNSSEC-bis") defined by <xref target="RFC4033"/> <xref target="RFC4034"/>
<xref target="RFC4035"/>,
to permit authentication and data integrity checking of DNS data. DNSSEC adds
new records to the DNS data which permit the validation of data in the DNS using strong cryptography.</t>
</section>
<section title="DNS Replication">
<t>DNS replication is a very important BCP to mitigate availability threats. Attacking multiple DNS servers
simultaneously with the purpose of bringing them all them is much more challenging than attacking a sole
DNS server (single point of failure).</t>
</section>
<section title="Privacy Service">
<t>Stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs are
the mechanisms described in <xref target="RFC3323" /> to protect SIP privacy. This practice allows an SSP
to hide its SIP network topology, prevents intermediate signaling equipment from becoming the target of
DoS attacks, as well as protects the privacy of UEs according to their preferences.</t>
</section>
<section title="Digest Authentication on all requests">
<t>In todays current practice, Digest authentication <xref target="RFC2617" /> is used to challenge only
REGISTER and INVITE requests. However, as a BCP, the more messages it is applied to the more prevention
from threats is assured. It is recommended to apply digest authentication to all SIP requests, including
BYE and CANCEL, to prevent attacks such as session tear-down.</t>
</section>
<section title="Use TCP instead of UDP to deliver SIP messages">
<t>Most SIP clients stay connected with the server on a persistent basis (differently from HTTP clients).
Scalability requirements are therefore much more stringent for a SIP server than for a web server.
This leads to the choice of UDP as protocol used between SSPs to carry SIP messages (especially for
providers with a large user community). New improvements in the Linux kernel <xref target="refs.tcp-scalability"/>
show a big increase of the scalability of TCP in handling large number of persistent (but idle) connections.
Therefore SSP operators still using UDP for their SIP network should consider switching to TCP. This would
increase the difficulty of performing attacks such as session teardown or forged responses.</t>
</section>
<section title="Ingress Filtering">
<t>Ingress filtering, i.e. block all traffic coming from a host that has a source address different than
the addresses that have been assigned to that host (see <xref target="RFC2827" />) can effectively prevent
UEs from sending packets with a spoofed source IP address.</t>
</section>
<section title="Strong Identity Assertion">
<t>"Caller ID spoofing" can be achieved thanks to a Weak identity assertion on the From URI of an INVITE request.
In a single SSP domain, strong identity assertion can be easily achieved by authenticating each INVITE request.
However, in the context of SPEERMINT, only the originating SSP is able to verify the identity directly.
In order to overcome this problem there are currently only two major approaches: transitive trust and cryptographic
signature.
The transitive trust approach builds a chain of trust among different SSP domains. One example of this approach
is a combined mechanism specified in <xref target="RFC3324" /> and <xref target="RFC3325" />.
Using this approach in a transit peering network scenario, the terminating SSP must establish a trust relationship
with all SSP domains on the path, which can be seen as an underlying weakness.
The use of cryptographic signatures is an alternative approach. "SIP Authenticated Identity Body (AIB)" is
specified in <xref target="RFC3893" />. <xref target="RFC4474" /> introduces two new header fields IDENTITY and
IDENTITY-INFO that allow a SIP server in the originating SSP to digitally sign an INVITE request after authenticating
the sending UE. The terminating SSP can verify if the INVITE request is signed by a trusted SSP domain. Although this
approach does not require the terminating SSP to establish a trust relationship with all transit SSPs on the path, a
PKI infrastructure is assumed to be in place.</t>
</section>
<section title="Server Pooling">
<t>Architecture and protocols for the management of server pools supporting mission-critical applications is addressed
in the RSERPOOL WG. Using this mechanisms (see <xref target="RFC3237" /> for requirements) an UE obtains support
for server failover in case of availability problems.</t>
</section>
<section title="Rate limit">
<t>Packet flooding attacks can be mitigated by limiting the rate of incoming traffic through policing or queuing.
In this way legitimate clients could be denied of the service since their traffic may be discarded. Rate limiting
can also be applied on a per-source-IP basis under the assumption that the source IP of each attack packet is not
spoofed dynamically and will all the limitations related to NAT and mobility issues.</t>
</section>
<section title="Fuzz testing">
<t>Fuzz testing is a common black box testing technique used in software engineering. Fuzz tests can be carried
out preventively to assure UE/SBE/DBE can handle unexpected data correctly without crashing.
<xref target="RFC4475" /> and <xref target="refs.protos"/> are examples of torture test cases specific for SIP
devices and freely available fuzzers, respectively. These type of tests needs to be carried out before product release.</t>
</section>
<section title="SRTCP">
<t>Secure RTCP (SRTCP) provides the same security-related features to RTCP as SRTP does for RTP. SRTCP is described in
<xref target="RFC3711" /> as optional. In order to prevent some of the RTCP threats previously described it is recommended to
turn this feature on.</t>
</section>
<section title="Mapping BCPs to threats">
<t>The following table shows how to mitigate threats with the above mentioned BCPs.</t>
<figure>
<artwork>
+---------------------------------------------------------+
| Group | Threats | BCPs |
+--------+------------------------------------------------+
| | Unauthorized access | database BCPs |
| +---------------------+--------------------------+
| LUF | SQL injection | database BCPs |
| +---------------------+--------------------------+
| | DoS to LUF | database BCPs |
+--------+---------------------+--------------------------+
| | URI harvesting | DNSSEC |
| +---------------------+--------------------------+
| | SIP equipment | |
| | enumeration | DNSSEC, privacy service |
| +---------------------+--------------------------+
| LF | MitM attack | DNSSEC |
| +---------------------+--------------------------+
| | Incorrect | |
| | destinations | DNSSEC |
| +---------------------+--------------------------+
| | DoS to LF | DNS replication |
+--------+---------------------+--------------------------+
| | Call pattern | |
| | analysis | TLS |
| +---------------------+--------------------------+
| | Password cracking | TLs |
| +---------------------+--------------------------+
| | Session Tear Down | TLS, TCP, digest auth. |
| +---------------------+--------------------------+
| | REGISTER spoofing | digest auth. |
| +---------------------+--------------------------+
| | Billing fraud | digest auth. |
| +---------------------+--------------------------+
| | User ID spoofing | strong identity assertion|
| SF +---------------------+--------------------------+
| | Forged 200 Response | TLS, TCP, ingress filt. |
| +---------------------+--------------------------+
| | Forged 302 Response | TLS, TCP, ingress filt. |
| +---------------------+--------------------------+
| | Forged 404 Response | TLS, TCP, ingress filt. |
| +---------------------+--------------------------+
| | Flooding attack | server polling, |
| | | rate limit |
| +---------------------+--------------------------+
| | Session black | DNSSEC |
| | holing | |
| +---------------------+--------------------------+
| | SIP fuzzing attack | Fuzz testing |
+--------+---------------------+--------------------------+
| | Eavesdropping | SRTP |
| +---------------------+--------------------------+
| | Media Hijack | SRTP |
| +---------------------+--------------------------+
| MF | Media session | SRTCP |
| | tear-down | |
| +---------------------+--------------------------+
| | QoS degradation | SRTCP |
| +---------------------+--------------------------+
| | Malformed messages | Fuzzing test |
| +---------------------+--------------------------+
| | Messages flooding | rate limit |
+--------+---------------------+--------------------------+
</artwork>
</figure>
</section>
</section>
<section anchor="conclusions" title="Conclusions">
<t> This memo presented the different SPEERMINT security threats classified in groups
related to the LUF, LF, SF and MF respectively. The multiple instances of the threats are
presented with a brief explanation. Afterwards the security BCPs for SPEERMINT are outlined
together with possible mitigation of the existing threats by means of them.</t>
</section>
<section anchor="security" title="Security Considerations">
<t> This memo is entirely focused on the security threats for SPEERMINT.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>This memo takes inspiration from VOIPSA VoIP Security and Privacy Threat Taxonomy. The
author would like to thank VOIPSA for having produced such a comprehensive taxonomy
which is the starting point of this draft. The author would also like to thank Cullen
Jennings for the useful slides presented at the VoIP Management and Security workshop
in Vancouver.
</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="refs.voipsataxonomy">
<front>
<title>VOIPSA VoIP Security and Privacy Threat Taxonomy</title>
<author>
<organization/>
</author>
<date month="October" year="2005"/>
</front>
</reference>
<reference anchor="refs.speermintarch">
<front>
<title>SPEERMINT Peering Architecture</title>
<author initials="R." surname="Penno" fullname="Reinaldo Penno">
<organization abbrev="Juniper Networks"/>
</author>
<author initials="D." surname="Malas" fullname="Daryl Malas">
<organization abbrev="Level 3 Communications"/>
</author>
<author initials="S." surname="Khan" fullname="Sohel Khan">
<organization abbrev="Sprint"/>
</author>
<author initials="A." surname="Uzelac" fullname="Adam Uzelac">
<organization abbrev="Global Crossing"/>
</author>
<date month="August" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-speermint-architecture-04.txt"/>
</reference>
<reference anchor="refs.zrtp">
<front>
<title>ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP</title>
<author initials="P." surname="Zimmermann" fullname="Philip Zimmermann">
<organization abbrev="Zfone Project"></organization>
</author>
<author initials="A." surname="Johnston" fullname="Alan Johnston">
<organization abbrev="Avaya"></organization>
</author>
<author initials="J." surname="Callas" fullname="Jon Callas">
<organization abbrev="PGP Corporation"></organization>
</author>
<date month="July" year="2007"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-zimmermann-avt-zrtp-04.txt"/>
</reference>
<reference anchor="refs.tlsbis">
<front>
<title>The TLS Protocol Version 1.2</title>
<author initials="T." surname="Dierks" fullname="Tim Dierks">
<organization abbrev="Indipendent"/>
</author>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla">
<organization abbrev="Network Resonance, Inc."/>
</author>
<date month="February" year="2008"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-rfc4346-bis-09.txt"/>
</reference>
&rfc3711;
&rfc4474;
&I-D.ietf-speermint-terminology;
&I-D.ietf-speermint-requirements;
<reference anchor="refs.dbsec">
<front>
<title>Handbook of Database Security</title>
<author initials="M." surname="Gertz" fullname="M. Gertz">
<organization/>
</author>
<author initials="S." surname="Jajodia" fullname="S. Jajodia">
<organization/>
</author>
</front>
</reference>
&rfc4033;
&rfc4034;
&rfc4035;
&rfc3323;
&rfc2617;
<reference anchor="refs.tcp-scalability">
<front>
<title>Scalability of TCP Servers, Handling Persistent Connections</title>
<author initials="K." surname="Shemyak" fullname="K. Shemyak">
<organization/>
</author>
</front>
</reference>
&rfc2827;
&rfc3324;
&rfc3325;
&rfc3893;
&rfc3237;
<reference anchor="refs.protos">
<front>
<title>SIP Robustness Testing for Large-Scale Use</title>
<author initials="C." surname="Wieser" fullname="C. Wieser">
<organization/>
</author>
</front>
</reference>
&rfc4475;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:28:36 |