TOC 
SPEERMINT Working GroupS. Niccolini
Internet-DraftNEC
Intended status: InformationalE. Chen
Expires: January 15, 2009NTT
 J. Seedorf
 NEC
 July 14, 2008


SPEERMINT Security Threats and Suggested Countermeasures
draft-niccolini-speermint-voipthreats-04

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 15, 2009.

Abstract

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.



Table of Contents

1.  Introduction
2.  Security Threats relevant to SPEERMINT
    2.1.  Threats Relevant to the Look-Up Function (LUF)
        2.1.1.  Threats to LUF Confidentiality
        2.1.2.  Threats to LUF Integrity
        2.1.3.  Threats to LUF Availability
    2.2.  Threats Relevant to the Location Function (LF)
        2.2.1.  Threats to LF Confidentiality
        2.2.2.  Threats to LF Integrity
        2.2.3.  Threats to LF Availability
    2.3.  Threats to the Signaling Function (SF)
        2.3.1.  Threats to SF Confidentiality
        2.3.2.  Threats to SF Integrity
        2.3.3.  Threats to SF Availability
    2.4.  Threats to the Media Function (MF)
        2.4.1.  Threats to MF Confidentiality
        2.4.2.  Threats to MF Integrity
        2.4.3.  Threats to MF Availability
3.  Suggested Countermeasures
    3.1.  Security Requirements
    3.2.  Database Security
    3.3.  DNSSEC
    3.4.  DNS Replication
    3.5.  Cross-Domain Privacy Protection
    3.6.  Digest Authentication on all requests in peering agreements
    3.7.  Use TCP instead of UDP to deliver SIP messages
    3.8.  Ingress Filtering / Reverse-Path Filtering
    3.9.  Strong Identity Assertion
    3.10.  Reliable Border Element Pooling
    3.11.  Rate limit
    3.12.  Border Element Hardening
    3.13.  SRTCP
4.  Mapping suggested countermeasures to threats
    4.1.  Current Deployment of Countermeasures
5.  Conclusions
6.  Security Considerations
7.  Acknowledgements
8.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1.  Introduction

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.



 TOC 

2.  Security Threats relevant to SPEERMINT

This section enumerates potential security threats relevant to SPEERMINT. A taxonomy of VoIP security threats is defined in [refs.voipsataxonomy] (Zar, J. and et al, “VOIPSA VoIP Security and Privacy Threat Taxonomy,” October 2005.). 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 [refs.speermintarch] (Penno, R., Malas, D., Khan, S., and A. Uzelac, “SPEERMINT Peering Architecture,” August 2007.), moreover additional threats for the SPEERMINT architecture are listed and detailed under the same classification and according the CIA (Confidentiality, Integrity and Availability) triad:



 TOC 

2.1.  Threats Relevant to the Look-Up Function (LUF)

This is one of the latest additions of the terminology draft [I‑D.ietf‑speermint‑terminology] (Malas, D. and D. Meyer, “SPEERMINT Terminology,” November 2008.). LUF is vulenrable to the same threats that affect database systems in general.



 TOC 

2.1.1.  Threats to LUF Confidentiality



 TOC 

2.1.2.  Threats to LUF Integrity

The underlying database could be vulnerable to:



 TOC 

2.1.3.  Threats to LUF Availability

The underlying database could be vulnerable to:



 TOC 

2.2.  Threats Relevant to the Location Function (LF)



 TOC 

2.2.1.  Threats to LF Confidentiality



 TOC 

2.2.2.  Threats to LF Integrity

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.



 TOC 

2.2.3.  Threats to LF Availability

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.



 TOC 

2.3.  Threats to the Signaling Function (SF)

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.



 TOC 

2.3.1.  Threats to SF Confidentiality

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:



 TOC 

2.3.2.  Threats to SF Integrity

The integrity of the SF can be violated using SIP request spoofing, SIP reply spoofing and SIP message tampering.



 TOC 

2.3.2.1.  SIP Request Spoofing

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:

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);

REGISTER spoofing - the attacker forges a REGISTER request and register a bogus contact information with the objective of hijacking incoming calls.

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;

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.



 TOC 

2.3.2.2.  SIP Reply Spoofing

Threats in this category are:

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;

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;

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;



 TOC 

2.3.2.3.  SIP Message Tampering

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.



 TOC 

2.3.3.  Threats to SF Availability



 TOC 

2.4.  Threats to the Media Function (MF)

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.



 TOC 

2.4.1.  Threats to MF Confidentiality

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.



 TOC 

2.4.2.  Threats to MF Integrity

Both RTP and RTCP are vulnerable to integrity violation in many ways:



 TOC 

2.4.3.  Threats to MF Availability



 TOC 

3.  Suggested Countermeasures

This section describes implementer-specific countermeasures against the threats described in the previous section to supplement the security requirements described in [I‑D.ietf‑speermint‑requirements] (Mule, J., “SPEERMINT Requirements for SIP-based Session Peering,” October 2009.). These countermeasures are described in this section and then mapped to threats in the following section, indicating which countermeasure is recommended to be used in order to solve which threat.



 TOC 

3.1.  Security Requirements

The security requirements for SPEERMINT have been moved from an earlier version of this draft to the requirements draft for speermint [I‑D.ietf‑speermint‑requirements] (Mule, J., “SPEERMINT Requirements for SIP-based Session Peering,” October 2009.). These security requirements are the following [I‑D.ietf‑speermint‑requirements] (Mule, J., “SPEERMINT Requirements for SIP-based Session Peering,” October 2009.):



 TOC 

3.2.  Database Security

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 Best Current Practises (BCPs) for database systems include replication to prevent any database from being a single point of failure, and the use of parameterized statements to prevent SQL injections. [refs.dbsec] (Gertz, M. and S. Jajodia, “Handbook of Database Security,” .) is one of many existing literatures that describe BCPs in this area.



 TOC 

3.3.  DNSSEC

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 [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.) [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.) [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.), 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.



 TOC 

3.4.  DNS Replication

DNS replication is a very important countermeasure 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).



 TOC 

3.5.  Cross-Domain Privacy Protection

Stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs are the mechanisms described in [RFC3323] (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.) 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.



 TOC 

3.6.  Digest Authentication on all requests in peering agreements

In today's current practice, Digest authentication [RFC2617] (Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.) is used to challenge only REGISTER and INVITE requests. However, 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 in peering agreements, including BYE and CANCEL, to prevent attacks such as session tear-down.



 TOC 

3.7.  Use TCP instead of UDP to deliver SIP messages

SIP clients need to 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 [refs.tcp‑scalability] (Shemyak, K., “Scalability of TCP Servers, Handling Persistent Connections,” .) 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. Since look-up and SED data should be exchanged securely (see security requirements), it is further recommended to not only use TCP but TLS for messages exchanged between SSPs.



 TOC 

3.8.  Ingress Filtering / Reverse-Path Filtering

Ingress filtering, i.e., blocking all traffic coming from a host that has a source address different than the addresses that have been assigned to that host (see [RFC2827] (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.)) can effectively prevent UEs from sending packets with a spoofed source IP address. This can be achieved by reverse-path filtering, i.e., only accepting ingress traffic if responses would take the same path.



 TOC 

3.9.  Strong Identity Assertion

"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 [RFC3324] (Watson, M., “Short Term Requirements for Network Asserted Identity,” November 2002.) and [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.). 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 [RFC3893] (Peterson, J., “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format,” September 2004.). [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) 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.



 TOC 

3.10.  Reliable Border Element Pooling

It is advisable to implement reliable pooling on border elements. An architecture and protocols for the management of server pools supporting mission-critical applications are addressed in the RSERPOOL WG. Using this mechanisms (see [RFC3237] (Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, “Requirements for Reliable Server Pooling,” January 2002.) for requirements) a UE obtains support for server failover in case of availability problems.



 TOC 

3.11.  Rate limit

Packet flooding attacks can be mitigated by limiting the rate of incoming traffic through policing or queuing. In this way legitimate clients can 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. It may be preferable to limit the number of concurrent 'sessions', i.e., ongoing calls instead of the messaging associated with it (since session use more resources on backend-systems). When calculating rate limits all entities along the session path should be taken into account. SIP entities on the receiving end of a call may be the limiting factor (e.g., the number of ISDN channels on PSTN gateways) rather than the ingress limiting device.



 TOC 

3.12.  Border Element Hardening

To prevent attackers from hacking SPEERMINT border elements these implementations should be seurity hardened. For instance, fuzz testing is a common black box testing technique used in software engineering. Also, security vulnerability tests can be carried out preventively to assure a UE/SBE/DBE can handle unexpected data correctly without crashing. [RFC4475] (Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, “Session Initiation Protocol (SIP) Torture Test Messages,” May 2006.) and [refs.protos] (Wieser, C., “SIP Robustness Testing for Large-Scale Use,” .) are examples of torture test cases specific for SIP devices and freely available security testing tools, respectively. These type of tests needs to be carried out before product release and in addition throughout the product life cycle.



 TOC 

3.13.  SRTCP

Secure RTCP (SRTCP) provides the same security-related features to RTCP as SRTP does for RTP. SRTCP is described in [RFC3711] (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) as optional. In order to prevent some of the RTCP threats previously described it is recommended to turn this feature on.



 TOC 

4.  Mapping suggested countermeasures to threats

The following table shows how to mitigate threats with the appropriate countermeasures listed in section Section 3 (Suggested Countermeasures).

          +---------------------------------------------------------+
          | Group  |       Threat        | Suggested Countermeasure |
          +--------+------------------------------------------------+
          |        | Unauthorized access | database BCPs            |
          |        +---------------------+--------------------------+
          |  LUF   | SQL injection       | database BCPs            |
          |        +---------------------+--------------------------+
          |        | DoS to LUF          | database BCPs            |
          +--------+---------------------+--------------------------+
          |        | URI harvesting      | DNSSEC                   |
          |        +---------------------+--------------------------+
          |        | SIP equipment       | DNSSEC,                  |
          |        | enumeration         | privacy protection	    |
          |        +---------------------+--------------------------+
          |  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     | reliable border element  |
          |        |                     | pooling, rate limit      |
          |        +---------------------+--------------------------+
          |        | Session black       | DNSSEC                   |
          |        | holing              |                          |
          |        +---------------------+--------------------------+
          |        | SIP fuzzing attack  | border element hardening |
          +--------+---------------------+--------------------------+
          |        | Eavesdropping       | SRTP                     |
          |        +---------------------+--------------------------+
          |        | Media Hijack        | SRTP                     |
          |        +---------------------+--------------------------+
          |  MF    | Media session       | SRTCP                    |
          |        | tear-down           |                          |
          |        +---------------------+--------------------------+
          |        | QoS degradation     | SRTCP                    |
          |        +---------------------+--------------------------+
          |        | Malformed messages  | border element hardening |
          |        +---------------------+--------------------------+
          |        | Messages flooding   | rate limit               |
          +--------+---------------------+--------------------------+


 TOC 

4.1.  Current Deployment of Countermeasures

At the time of writing this document not all suggested countermeasures are widely deployed. In particular, the following measures to prevent attacks suggested in section Section 3 (Suggested Countermeasures) have not seen wide deployment:

Nevertheless, these protocols and solutions can provide effective means for preventing some of the attacks with respect to the SPEERMINT architecture described in this document. It is envisioned that these countermeasures will be more widely deployed in the future. Therefore, these mechanisms are listed in this document even though they are not widely deployed today.



 TOC 

5.  Conclusions

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 suggested countermeasures for SPEERMINT were outlined together with possible mitigation of the existing threats by means of them.



 TOC 

6.  Security Considerations

This memo is entirely focused on the security threats for SPEERMINT.



 TOC 

7.  Acknowledgements

This memo takes inspiration from VOIPSA VoIP Security and Privacy Threat Taxonomy. The authors would like to thank VOIPSA for having produced such a comprehensive taxonomy which is the starting point of this draft. The authors would also like to thank Cullen Jennings for the useful slides presented at the VoIP Management and Security workshop in Vancouver. Further, the authors thank Hendrik Scholz for providing extensive and very helpful comments to this draft.



 TOC 

8. Informative References

[refs.voipsataxonomy] Zar, J. and et al, “VOIPSA VoIP Security and Privacy Threat Taxonomy,” October 2005.
[refs.speermintarch] Penno, R., Malas, D., Khan, S., and A. Uzelac, “SPEERMINT Peering Architecture,” draft-ietf-speermint-architecture-04.txt (work in progress), August 2007.
[refs.zrtp] Zimmermann, P., Johnston, A., and J. Callas, “ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP,” draft-zimmermann-avt-zrtp-04.txt (work in progress), July 2007.
[refs.tlsbis] Dierks, T. and E. Rescorla, “The TLS Protocol Version 1.2,” draft-ietf-tls-rfc4346-bis-09.txt (work in progress), February 2008.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT).
[RFC4474] Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” RFC 4474, August 2006 (TXT).
[I-D.ietf-speermint-terminology] Malas, D. and D. Meyer, “SPEERMINT Terminology,” draft-ietf-speermint-terminology-17 (work in progress), November 2008 (TXT).
[I-D.ietf-speermint-requirements] Mule, J., “SPEERMINT Requirements for SIP-based Session Peering,” draft-ietf-speermint-requirements-09 (work in progress), October 2009 (TXT).
[refs.dbsec] Gertz, M. and S. Jajodia, “Handbook of Database Security.”
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” RFC 4033, March 2005 (TXT).
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” RFC 4034, March 2005 (TXT).
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” RFC 4035, March 2005 (TXT).
[RFC3323] Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” RFC 3323, November 2002 (TXT).
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” RFC 2617, June 1999 (TXT, HTML, XML).
[refs.tcp-scalability] Shemyak, K., “Scalability of TCP Servers, Handling Persistent Connections.”
[RFC2827] Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” BCP 38, RFC 2827, May 2000 (TXT).
[RFC3324] Watson, M., “Short Term Requirements for Network Asserted Identity,” RFC 3324, November 2002 (TXT).
[RFC3325] Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” RFC 3325, November 2002 (TXT).
[RFC3893] Peterson, J., “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format,” RFC 3893, September 2004 (TXT).
[RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J., and M. Stillman, “Requirements for Reliable Server Pooling,” RFC 3237, January 2002 (TXT).
[refs.protos] Wieser, C., “SIP Robustness Testing for Large-Scale Use.”
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, “Session Initiation Protocol (SIP) Torture Test Messages,” RFC 4475, May 2006 (TXT).


 TOC 

Authors' Addresses

  Saverio Niccolini
  Network Laboratories, NEC Europe Ltd.
  Kurfuersten-Anlage 36
  Heidelberg 69115
  Germany
Phone:  +49 (0) 6221 4342 118
Email:  saverio.niccolini@netlab.nec.de
URI:  http://www.netlab.nec.de
  
  Eric Chen
  Information Sharing Platform Laboratories, NTT
  3-9-11 Midori-cho
  Musashino, Tokyo 180-8585
  Japan
Email:  eric.chen@lab.ntt.co.jp
URI:  http://www.ntt.co.jp/index_e.html
  
  Jan Seedorf
  NEC Laboratories Europe, NEC Europe Ltd.
  Kurfuersten-Anlage 36
  Heidelberg 69115
  Germany
Phone:  +49 (0) 6221 4342 221
Email:  seedorf@nw.neclab.eu
URI:  http://www.nw.neclab.eu


 TOC 

Full Copyright Statement

Intellectual Property