[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-niccolini-speermint-voipthreats) 00 01 02 03 04 05 06 07 08 09 RFC 6404

SPEERMINT Working Group                                       J. Seedorf
Internet-Draft                                              S. Niccolini
Intended status: Informational                                       NEC
Expires: February 17, 2012                                       E. Chen
                                                                     NTT
                                                               H. Scholz
                                                              VOIPFUTURE
                                                         August 16, 2011


Session Peering for Multimedia Interconnect (SPEERMINT) Security Threats
                     and Suggested Countermeasures
                  draft-ietf-speermint-voipthreats-09

Abstract

   The Session PEERing for Multimedia INTerconnect working group
   (SPEERMINT) provides a peering framework that leverages the building
   blocks of existing IETF-defined protocols such as SIP and ENUM for
   the interconnection between SIP Service Providers (SSPs).  The
   objective of this document is to identify and enumerate SPEERMINT-
   specific threat vectors and to give guidance for implementers on
   selecting appropriate countermeasures.  Security requirements for
   SPEERMINT which have been derived from the threats detailed in this
   document can be found in RFC 6271; this document provides concrete
   countermeasures to meet those SPEERMINT security requirements.  In
   this document, the different security threats related to SPEERMINT
   are classified into threats to the Lookup Function (LUF), to the
   Location Routing Function (LRF), to the Signaling Function (SF), and
   to the Media Function (MF) of a specific SIP Service Provider.
   Various instances of the threats are briefly introduced inside the
   classification.  Finally, existing security solutions for SIP and
   RTP/RTCP are presented to describe countermeasures currently
   available for such threats.  Each SSP may have connections to one or
   more remote SSPs through peering or transit contracts.  A potentially
   compromised remote SSP which attacks other SSPs is out of the scope
   of this document; this document focuses on attacks on an SSP from
   outside the trust domain such an SSP may have with other SSPs.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.



Seedorf, et al.         Expires February 17, 2012               [Page 1]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   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."

   This Internet-Draft will expire on February 17, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






























Seedorf, et al.         Expires February 17, 2012               [Page 2]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Security Threats relevant to SPEERMINT . . . . . . . . . . . .  6
     2.1.  Threats to the Look-Up Function (LUF)  . . . . . . . . . .  6
       2.1.1.  Threats to LUF Confidentiality . . . . . . . . . . . .  6
       2.1.2.  Threats to LUF Integrity . . . . . . . . . . . . . . .  7
       2.1.3.  Threats to LUF Availability  . . . . . . . . . . . . .  7
     2.2.  Threats to the Location Routing Function (LRF) . . . . . .  7
       2.2.1.  Threats to LRF Confidentiality . . . . . . . . . . . .  7
       2.2.2.  Threats to LRF Integrity . . . . . . . . . . . . . . .  8
       2.2.3.  Threats to LRF Availability  . . . . . . . . . . . . .  8
     2.3.  Threats to the Signaling Function (SF) . . . . . . . . . .  8
       2.3.1.  Threats to SF Confidentiality  . . . . . . . . . . . .  8
       2.3.2.  Threats to SF Integrity  . . . . . . . . . . . . . . .  9
       2.3.3.  Threats to SF Availability . . . . . . . . . . . . . . 10
     2.4.  Threats to the Media Function (MF) . . . . . . . . . . . . 11
       2.4.1.  Threats to MF Confidentiality  . . . . . . . . . . . . 11
       2.4.2.  Threats to MF Integrity  . . . . . . . . . . . . . . . 11
       2.4.3.  Threats to MF Availability . . . . . . . . . . . . . . 12
   3.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 13
     3.1.  Security Requirements from SPEERMINT requirements draft  . 13
     3.2.  How to fulfill the security requirements for SPEERMINT . . 13
   4.  Suggested Countermeasures  . . . . . . . . . . . . . . . . . . 15
     4.1.  Database Security BCPs . . . . . . . . . . . . . . . . . . 17
     4.2.  DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     4.3.  DNS Replication  . . . . . . . . . . . . . . . . . . . . . 18
     4.4.  Cross-Domain Privacy Protection  . . . . . . . . . . . . . 18
     4.5.  Secure Exchange of SIP messages  . . . . . . . . . . . . . 18
     4.6.  Ingress Filtering / Reverse-Path Filtering . . . . . . . . 19
     4.7.  Strong Identity Assertion  . . . . . . . . . . . . . . . . 19
     4.8.  Reliable Border Element Pooling  . . . . . . . . . . . . . 20
     4.9.  Rate limit . . . . . . . . . . . . . . . . . . . . . . . . 20
     4.10. Topology Hiding  . . . . . . . . . . . . . . . . . . . . . 20
     4.11. Border Element Hardening . . . . . . . . . . . . . . . . . 20
     4.12. Securing Session Establishment Data  . . . . . . . . . . . 21
     4.13. Encryption and Integrity Protection of Media Stream  . . . 21
   5.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 26
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29








Seedorf, et al.         Expires February 17, 2012               [Page 3]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


1.  Introduction

   With Voice-over-IP (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 devices may be addressed directly by
   attackers as they use the same underlying networking technology 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, Denial-of-Service (DoS) attacks [RFC4732], etc.).  Therefore
   there is the need of investigating the different security threats, to
   extract security-related requirements, and to highlight potential
   solutions on how to protect from such threats.

   The Session PEERing for Multimedia INTerconnect working group
   (SPEERMINT) provides a peering framework that leverages the building
   blocks of existing IETF-defined protocols such as SIP and ENUM for
   the interconnection between SIP servers [RFC5486].  The objective of
   this document is to identify and enumerate SPEERMINT-specific threat
   vectors and to give guidance for implementers on selecting
   appropriate countermeasures.  Security requirements for SPEERMINT can
   be found in RFC 6271 "Requirements for SIP-Based Session Peering"
   [RFC6271].  These security requirements for SPEERMINT are derived
   from the threats which are detailed in this document; they have been
   moved from an earlier version of this draft to the SPEERMINT
   requirements draft [RFC6271].  In addition to being the base for
   those security requirements, this document provides to implementers
   advice and examples for concrete countermeasures on how to meet these
   security requirements for SPEERMINT with technical means.  The
   SPEERMINT terminology outlined in [RFC5486] is used throughout this
   document.

   In this document, the different security threats related to SPEERMINT
   are classified into threats to the Lookup Function (LUF), to the
   Location Routing Function (LRF), to the Signaling Function (SF), and
   to the Media Function (MF) of a specific SIP Service Provider (SSP).
   Various instances of the threats are briefly introduced inside the
   classification.  Finally, existing security solutions for SIP and



Seedorf, et al.         Expires February 17, 2012               [Page 4]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   RTP/RTCP are presented to describe countermeasures currently
   available for such threats.  Each SSP may have connections to one or
   more remote SSPs through peering or transit contracts.  A potentially
   compromised remote SSP which attacks other SSPs is out of the scope
   of this document; this document focuses on attacks on an SSP from
   outside the trust domain such an SSP may have with other SSPs.













































Seedorf, et al.         Expires February 17, 2012               [Page 5]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


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].  This taxonomy is 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 this taxonomy and mapped to the functions of the
   SPEERMINT architecture as defined in [refs.speermintarch].  Moreover,
   additional threats for the SPEERMINT architecture are listed and
   detailed under the same classification of SPEERMINT functions and
   according to the CIA (Confidentiality, Integrity and Availability)
   triad:

   o  Look-Up Function (LUF);

   o  Location Routing Function (LRF);

   o  Signaling Function (SF);

   o  Media Function (MF).

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

   The LUF provides a mechanism to determine for a given request the
   identity of the requested resource on the terminating domain.  The
   returned identity can be used to look up Session Establishment Data
   (SED) using the Location Routing Function (LRF).  In direct peerings
   the LUF is usually hosted locally whereas in a federation context
   this function may be offered by a third party.

   If the LUF is hosted locally it is vulnerable to the same threats
   that affect database systems in general.  If the SSP relies on a
   remote 3rd party to provide the LUF functionality, confidentiality,
   integrity, and authenticity of the responses are at risk.

2.1.1.  Threats to LUF Confidentiality

   The Look-Up Function (LUF) determines for a given request the target
   domain to which the request should be routed.  The following attacks
   are relevant with respect to eavesdropping on LUF messages:

   o  SIP URIs and peering domains harvesting - an attacker can exploit
      this weakness if the underlying database has a weak authentication
      system or if SIP messages are sent unencrypted, and then use the
      gained knowledge to launch other kinds of attacks.





Seedorf, et al.         Expires February 17, 2012               [Page 6]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   o  3rd party information - a LUF providing information to multiple
      companies / third parties can be attacked to obtain information
      about third party peering configurations and possible contracts.

2.1.2.  Threats to LUF Integrity

   The underlying database or LUF messages could be vulnerable to input/
   output message modification attacks:

   o  Injection attack - an attacker could manipulate statements
      performed on the database LUF messages sent to a third party.  A
      specific version of this attack is known as SQL injection.  An SQL
      injection is a code insertion into the LUF due to incorrect input
      validation.

2.1.3.  Threats to LUF Availability

   The underlying database or third party LUF service could be
   vulnerable to:

   o  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.

2.2.  Threats to the Location Routing Function (LRF)

   The LRF determines the location of the Signaling Function (SF) for
   the target domain of a given request.  Optionally it may return
   additional SED.

2.2.1.  Threats to LRF Confidentiality

   Similar to the LUF, the following attacks are related to
   eavesdropping on LRF messages:

   o  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.

   o  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.






Seedorf, et al.         Expires February 17, 2012               [Page 7]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


2.2.2.  Threats to LRF Integrity

   An attacker may modify messages, e.g. by feeding bogus information to
   the LRF, if the routing data is not correctly validated or sent
   unencrypted.  Dynamic call routing discovery and establishment, as in
   the scope of SPEERMINT, introduce opportunities for attacks such as
   the following:

   o  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.

   o  Incorrect destinations - the attacker redirects the calls to an
      incorrect destination with the purpose of establishing fraud
      communications like voice phishing or DoS attacks.

2.2.3.  Threats to LRF Availability

   The LRF can be object of DoS attacks.  DoS attacks to the LRF 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.

2.3.  Threats to the Signaling Function (SF)

   The signaling function involves a great number of sensitive
   information.  Through the signaling function, user agents (UA) assert
   identities and 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.

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:

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




Seedorf, et al.         Expires February 17, 2012               [Page 8]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   o  Password cracking - the challenge-response authentication
      mechanism of SIP Digest can be attacked with offline dictionary
      attacks.  With such attacks, an attacker tries to exploit weak
      passwords that are used by incautious users.

   o  Network discovery - the attacker may learn information about the
      internal network structure of peering partner that is directly or
      indirectly connected by looking at SIP routing information (i.e
      Record-Route, Via or Contact headers).

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.

2.3.2.1.  SIP Request Spoofing

   Most SIP request spoofing attacks require first a SIP message
   eavesdropping.  However, some of these attacks can be also performed
   by estimating certain fields in SIP headers (e.g. by exploiting the
   fact that weak implementations may generate predictable SIP Dialog
   parameters) or exploiting broken implementations which do not
   properly verify the content of certain headers.  Threats in this
   category are:

   o  session teardown - An attacker can send CANCEL/BYE messages in
      order to tear down an existing call at the SIP layer; for such an
      attack the attacker either needs to know (e.g. by eavesdropping a
      SIP INVITE message) the SIP Dialog of the call to be hijacked (To-
      tag, From-tag, Call-ID) or alternatively may rely on SIP
      implementations which do not properly authenticate requests based
      on the SIP Dialog;

   o  Billing fraud - the attacker can modify and replay an intercepted
      INVITE request, in order to bill a call to a victim UE and avoid
      paying for the phone call;

   o  user ID spoofing - SSPs are responsible for asserting the
      legitimacy of a 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;

   o  Unwanted requests - the attacker sends requests to interfere with
      regular operation, e.g. by sending a REGISTER request in order to
      hijack calls.  The SPEERMINT architecture as defined in
      [refs.speermintarch] does not require registrations between the
      signaling functions (SF) of the connected SSPs.  Hence,



Seedorf, et al.         Expires February 17, 2012               [Page 9]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


      superfluous requests like REGISTERs should be rejected.

2.3.2.2.  SIP Reply Spoofing

   Threats in this category are:

   o  Forged 199 Response - the attacker sends a forged 199 response to
      terminate an early dialog.  The forged response will not terminate
      the entire session but may alter the direction of the session;

   o  Forged 200 Response - Having seen the contents of an INVITE
      request, an eavesdropper can inject a 200 response, affecting the
      processing of the transaction of all proxies between the injection
      point and the originating UA and at the originating UA itself.  In
      the extreme case, this can result in a hijacked call.  In many
      cases, however, such an attack will leave signalling artifacts
      that may allow it to be detected (e.g., the element receiving the
      forged 200 response may also receive other SIP reply messages from
      the actual terminating UE);

   o  Forged 302 Response - Having seen the contents of an INVITE
      request, an eavesdropper could also inject a forged "302 Moved
      Temporarily" reply, affecting the processing of the transaction at
      intermediate entities and the originating UA.  This may allow the
      attacker to successfully redirect the call to any destination UE
      of his choosing;

   o  Forged 404 Response - Having seen the contents of an INVITE
      request, an eavesdropper could also inject a forged "404 Not
      Found" reply, affecting the processing of the transaction at
      intermediate entities and the originating UA.  Such an attack may
      result in disrupting the call establishment.

2.3.2.3.  SIP Message Tampering

   This threat involves the alteration 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.

2.3.3.  Threats to SF Availability

   o  Flooding attack - a SBE is susceptible to message flooding attack
      that may come from interconnected SSPs;





Seedorf, et al.         Expires February 17, 2012              [Page 10]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


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

   o  SIP Fuzzing attack - fuzzing tests and software can be used by
      attackers to discover and exploit vulnerabilities of a SIP entity.
      This attack may result in crashing a SIP entity.

2.4.  Threats to the Media Function (MF)

   The Media function (MF) is responsible for the actual delivery of
   multimedia communication between the users and carries sensitive
   information.  Through the media function, the 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.

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).  Some SRTP key exchange mechanisms
   (e.g.  [RFC4568]) are vulnerable to bid-down attacks, where an
   attacker selectively changes key exchange protocol fields in order to
   enforce the establishment of a less secure or even non-secure
   communication.

2.4.2.  Threats to MF Integrity

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

   o  Media Injection - 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.  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.

   o  Media Session Teardown - the attacker sends bogus RTCP BYE
      messages to a target UE signaling to tear down the media
      communication, please note that RTCP messages are normally not
      authenticated.

   o  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



Seedorf, et al.         Expires February 17, 2012              [Page 11]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


      degrading the overall quality of the call experience.

2.4.3.  Threats to MF Availability

   o  Malformed messages - the attacker tries to cause a crash or a
      reboot of the DBE/UE by sending RTP/RTCP malformed messages;

   o  Messages flooding - the attacker tries to exhaust the resources of
      the DBE/UE by sending many RTP/RTCP messages.










































Seedorf, et al.         Expires February 17, 2012              [Page 12]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


3.  Security Requirements

3.1.  Security Requirements from SPEERMINT requirements draft

   The security requirements for SPEERMINT have been moved from an
   earlier version of this draft to the SPEERMINT requirements
   [RFC6271].  The security requirements for SPEERMINT are the following
   [RFC6271]:

   o  Requirement #15: The protocols used to query the Lookup and
      Location Routing Functions should support mutual authentication.

   o  Requirement #16: The protocols used to query the Lookup and
      Location Routing Functions should provide support for data
      confidentiality and integrity.

   o  Requirement #17: The protocols used to enable session peering must
      not interfere with the exchanges of media security attributes in
      SDP.  Media attribute lines that are not understood by SBEs must
      be ignored and passed along the signaling path untouched.

3.2.  How to fulfill the security requirements for SPEERMINT

   Requirements #15 and #16 demand that the LUF and LRF should support
   mutual authentication, data confidentiality, and integrity.  In
   principle, these requirements can be fulfilled technically with
   transport layer security (TLS or DTLS) [RFC5246] [RFC4347] or IP
   layer security (IPSec) [RFC4301].  From a pure security perspective
   both solutions fulfill the security requirements for SPEERMINT, just
   on a different layer, and both solutions are widely deployed.

   However, from a more practical perspective, transport layer security
   (i.e., TLS or DTLS) has the advantage that the application using it
   is aware of security (or rather the corresponding security features)
   being enabled or not.  For instance, using TLS has the consequence
   that the connection fails if the corresponding connection endpoint
   cannot authenticate properly.

   While IPSec fulfills the same requirements from a security
   perspective, IPSec is somewhat de-coupling security from the
   application using it.  For instance, IPsec is often provided by
   dedicated entities in such a way that from the application layer it
   cannot be recognized if IPSec or certain security features are turned
   on or not ("bump-in-the-wire").

   In summary, TLS (or DTLS) has some notable advantages over IPsec for
   addressing the SPEERMINT security requirements.  In particular,
   transport layer security is preferable over IPSec for SPEERMINT



Seedorf, et al.         Expires February 17, 2012              [Page 13]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   because with TLS (or DTLS) security is more closely coupled to the
   LUF or LRF.  From a mere technical perspective, however, both
   solutions (transport layer security or IPSec) fulfill the SPEERMINT
   security requirements and there may be particular cases where IPSec
   is a preferable solution.














































Seedorf, et al.         Expires February 17, 2012              [Page 14]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


4.  Suggested Countermeasures

   This section describes implementer-specific countermeasures against
   the threats described in the previous sections and for addressing the
   SPEERMINT security requirements described in [RFC6271].  The
   countermeasures listed in this section are not meant to be
   exhaustive; rather, the suggested countermeasures are aimed to serve
   as starting points and to give guidance for implementers that are
   trying to select appropriate countermeasures against certain threats.

      The following table provides a map of the relationships between
      threats and countermeasures.  The suggested countermeasures are
            discussed in detail in the subsequent subsections.

   +-------+---------------+-------------------------------------------+
   | Group | Threat        | Suggested Countermeasure                  |
   +-------+---------------+-------------------------------------------+
   |  LUF  | Unauthorized  | database security BCPs (Section 4.1),     |
   |       | access        | Secure Exchange of SIP messages           |
   |       |               | (Section 4.5)                             |
   |       |               |                                           |
   |       | SQL injection | database security BCPs (Section 4.1),     |
   |       |               | Secure Exchange of SIP messages           |
   |       |               | (Section 4.5)                             |
   |       |               |                                           |
   |       | DoS to LUF    | database security BCPs (Section 4.1),     |
   |       |               | Secure Exchange of SIP messages           |
   |       |               | (Section 4.5)                             |
   |       |               |                                           |
   |       |               |                                           |
   |  LRF  | URI           | privacy protection (Section 4.4), Secure  |
   |       | harvesting    | Exchange of SIP messages (Section 4.5)    |
   |       |               |                                           |
   |       | SIP equipment | privacy protection (Section 4.4), Secure  |
   |       | enumeration   | Exchange of SIP messages (Section 4.5)    |
   |       |               |                                           |
   |       | MitM attack   | DNSSEC (Section 4.2), Secure Exchange of  |
   |       |               | SIP messages (Section 4.5)                |
   |       |               |                                           |
   |       | Incorrect     | DNSSEC (Section 4.2), Secure Exchange of  |
   |       | destinations  | SIP messages (Section 4.5)                |
   |       |               |                                           |
   |       | DoS to LRF    | DNS replication (Section 4.3)             |
   |       |               |                                           |
   |       |               |                                           |
   |   SF  | Call pattern  | Secure Exchange of SIP messages           |
   |       | analysis      | (Section 4.5), Securing Session           |
   |       |               | Establishment Data (Section 4.12)         |



Seedorf, et al.         Expires February 17, 2012              [Page 15]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   |       | Password      | Secure Exchange of SIP messages           |
   |       | cracking      | (Section 4.5)                             |
   |       |               |                                           |
   |       | Network       | Securing Session Establishment Data       |
   |       | discovery     | (Section 4.12), Topology Hiding           |
   |       |               | (Section 4.10)                            |
   |       |               |                                           |
   |       | Session       | Secure Exchange of SIP messages           |
   |       | teardown      | (Section 4.5), ingress filtering          |
   |       |               | (Section 4.6)                             |
   |       |               |                                           |
   |       | Billing fraud | strong identity assertion (Section 4.7)   |
   |       |               |                                           |
   |       | User ID       | strong identity assertion (Section 4.7)   |
   |       | spoofing      |                                           |
   |       |               |                                           |
   |       | Forged 200    | Secure Exchange of SIP messages           |
   |       | Response      | (Section 4.5), ingress filtering          |
   |       |               | (Section 4.6)                             |
   |       |               |                                           |
   |       | Forged 302    | Secure Exchange of SIP messages           |
   |       | Response      | (Section 4.5), ingress filtering          |
   |       |               | (Section 4.6)                             |
   |       |               |                                           |
   |       | Forged 404    | Secure Exchange of SIP messages           |
   |       | Response      | (Section 4.5), ingress filtering          |
   |       |               | (Section 4.6)                             |
   |       |               |                                           |
   |       | Flooding      | reliable border element pooling           |
   |       | attack        | (Section 4.8), rate limit (Section 4.9)   |
   |       |               |                                           |
   |       | Session black | DNSSEC (Section 4.2)                      |
   |       | holing        |                                           |
   |       |               |                                           |
   |       | SIP fuzzing   | border element hardening (Section 4.11)   |
   |       | attack        |                                           |
   |       |               |                                           |
   |       |               |                                           |
   |   MF  | Eavesdropping | Encryption and Integrity Protection of    |
   |       |               | Media Stream (Section 4.13)               |
   |       |               |                                           |
   |       | Media         | Encryption and Integrity Protection of    |
   |       | injection     | Media Stream (Section 4.13)               |
   |       |               |                                           |
   |       | Media session | Encryption and Integrity Protection of    |
   |       | teardown      | Media Stream (Section 4.13)               |
   |       |               |                                           |




Seedorf, et al.         Expires February 17, 2012              [Page 16]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   |       | QoS           | Encryption and Integrity Protection of    |
   |       | degradation   | Media Stream (Section 4.13)               |
   |       |               |                                           |
   |       | Malformed     | border element hardening (Section 4.11)   |
   |       | messages      |                                           |
   |       |               |                                           |
   |       | Message       | rate limit (Section 4.9)                  |
   |       | flooding      |                                           |
   +-------+---------------+-------------------------------------------+

4.1.  Database Security BCPs

   Adequate security measures must be applied to the LUF to prevent it
   from being a target of attacks often seen on common database systems.
   Common security Best Current Practices (BCPs) for database systems
   include the use of strong passwords to prevent unauthorized access,
   parameterized statements to prevent SQL injections and server
   replication to prevent any database from being a single point of
   failure. [refs.dbsec] is one of many existing documents that describe
   BCPs in this area.

4.2.  DNSSEC

   If DNS is used by the LRF, it is recommended to deploy the recent
   version of Domain Name System Security Extensions (informally called
   "DNSSEC-bis") defined by [RFC4033][RFC4034][RFC4035].  DNSSEC has
   been designed to protect DNS against well-known attacks such as DNS
   cache poisoning or man-in-the-middle attacks on DNS queries.
   Essentially, DNSSEC is a set of public key cryptography extensions to
   DNS which provide authentication of DNS data, integrity protection
   for DNS entries, and authenticated denial of existence regarding non-
   existing DNS entries.  In the context of SSP peering, DNSSEC can
   provide authentication and integrity regarding the location of a
   Signaling Function (SF) entity retrieved via DNS.  Using DNSSEC can
   thus help to defend against MitM attacks on DNS queries invoked by
   the LRF, session blackholing and other attacks that lead traffic to
   incorrect destinations.

   DNSSEC has been deployed at the root level and in several top-level
   domains (e.g., .com and .net).  Although at the time of this writing
   DNSSEC is still not yet widely deployed on the Internet, even limited
   deployment can add significant integrity protection and
   authentication to the LRF for Signaling Function locations received
   via DNS entries.  Neither end-users nor terminals are involved in the
   DNS resolution process of the LRF.  Hence, if a) the sending SSP uses
   a DNS resolver which supports DNSSEC extensions, b) the receiving SSP
   stores the location of its Signaling Function cryptographically
   signed (using DNSSEC extensions) in the DNS, and c) the sending SSP



Seedorf, et al.         Expires February 17, 2012              [Page 17]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   can obtain an authentication chain (i.e. a series of linked DS and
   DNSKEY records) to the receiving SSP, the LRF can be secured with
   DNSSEC.  In the context of SPEERMINT, all these three requirements
   can be fulfilled even in the case of partial DNSSEC deployment.  In
   particular, even without Internet-wide deployment of DNSSEC it may be
   possible for a sending SSP to obtain a suitable trust anchor for
   verifying the receiving SSP's public key.  For instance, a suitable
   trust anchor could be configured for that specific SSP's top level
   domain or for the particular SSP's domain directly.  If the sending
   and the receiving SSP use a common ENUM tree, DNSSEC use with the
   ENUM tree's trust anchor is "straightforward".

4.3.  DNS Replication

   DNS replication is a very important countermeasure to mitigate DoS
   attacks on LRF.  Simultaneously bringing down multiple DNS servers
   that support LRF is much more challenging than attacking a sole DNS
   server (single point of failure).

4.4.  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]
   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.  This practice is effective in
   preventing SIP equipment enumeration that exploits LRF.

4.5.  Secure Exchange of SIP messages

   SIP can be used on top of UDP or TCP as transport protocol [RFC3261].
   However, look-up and SED data should be exchanged securely (see
   security requirements (Section 3.2)), e.g. to increase the difficulty
   of performing session teardown and forging responses (200, 302, 404
   etc).  If UDP is used to carry SIP messages, DTLS should be used to
   secure SIP message exchange between SSPs.  If TCP is used as a
   transport protocol, it can be secured with TLS.  Therefore, depending
   on the underlying transport protocol, SSPs should use either DTLS or
   TLS to secure SIP message delivery.

   In general, encryption and integrity protection of signaling messages
   can be achieved on the transport layer (with TLS or DTLS) or on the
   network layer (with IPSec).  Both solutions are technically sound,
   but transport layer security has some advantages.  Please refer to
   the subsection on fulfilling the SPEERMINT security requirements
   (Section 3.2) for a discussion on using TLS/DTLS or IPSec for
   protecting the confidentiality and integrity of signalling messages.



Seedorf, et al.         Expires February 17, 2012              [Page 18]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


   Similar to strong identity assertion, a PKI infrastructure is assumed
   to be in place for TLS/DTLS (or IPSec) deployment so that SSPs can
   obtain and trust the keys necessary to decrypt messages and verify
   signatures sent by other SSPs.

   Message oriented protection such as [RFC3261] Authentication does not
   fullfil the SPEERMINT requirements (e.g., mutual authentication).

4.6.  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]) 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.  This practice is
   effective in preventing session teardown and forged SIP replies (200,
   302, 404 etc), if the recipient correctly verifies the source IP
   address for the authenticity of each incoming SIP message.

4.7.  Strong Identity Assertion

   "Caller ID spoofing" can be achieved thanks to the 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] and [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 [RFC3893].  [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.







Seedorf, et al.         Expires February 17, 2012              [Page 19]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


4.8.  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 such mechanisms and protocols (see [RFC5351]
   [RFC5352] [RFC5353] for details), a UE can effectively increase its
   capacity in handling flooding attacks.

4.9.  Rate limit

   Flooding attacks on SF and MF can also 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.

4.10.  Topology Hiding

   Topology hiding applies to both the signaling and media plane and
   consists of limiting the amount of topology information exposed to
   peering partners.  Topology hiding requires B2BUA functionality.  The
   most common way is the use of a Session Border Controller (SBC) as
   SBE.  Topology hiding is explained in [RFC5853]

4.11.  Border Element Hardening

   To prevent attacks which exploit vulnerabilities (such as buffer
   overflows, format string vulnerabilities, etc.) in SPEERMINT border
   elements these implementations should be security 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] and [refs.protos] 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.




Seedorf, et al.         Expires February 17, 2012              [Page 20]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


4.12.  Securing Session Establishment Data

   Session establishment data (SED) contains critical information for
   the routing of SIP sessions.  In order to prevent attacks such as
   service hijacking and denial of service that exploit SED, SSPs should
   adopt a secure transport protocol that provides authentication,
   confidentiality and integrity to exchange SED among themselves.
   Further details can be found in [I-D.ietf-drinks-spprov].

4.13.  Encryption and Integrity Protection of Media Stream

   The Secure Real-time Transport Protocol (SRTP) [RFC3711] prevents
   eavesdropping on plain RTP by encrypting the data flow.  It uses AES
   as the default cipher and defines two modes of operation(Segmented
   Integer Counter Mode and f8-mode), which is agreed upon after
   negotiation.  It also uses HMAC-SHA1 and index keeping to enable
   message authentication/integrity and replay protection required to
   prevent media injection attacks.  Secure RTCP (SRTCP) provides the
   same security-related features to RTCP as SRTP does for RTP.  SRTCP
   is described in [RFC3711] as optional.  In order to prevent media
   session teardown, it is recommended to turn this feature on.  The
   choice of the external key management protocol is left to the
   deployment, a PKI infrastructure is necessary to implement the
   security requirements of the SPEERMINT requirements document.



























Seedorf, et al.         Expires February 17, 2012              [Page 21]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


5.  Conclusions

   This document presented the different SPEERMINT security threats
   classified in groups related to the LUF, LRF, SF and MF respectively.
   The multiple instances of the threats were presented with a brief
   explanation.  Finally, suggested countermeasures for SPEERMINT were
   outlined together with possible mitigation of the existing threats by
   means of them.











































Seedorf, et al.         Expires February 17, 2012              [Page 22]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


6.  Security Considerations

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















































Seedorf, et al.         Expires February 17, 2012              [Page 23]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


7.  IANA Considerations

   The objective of this document is to identify and enumerate
   SPEERMINT-specific threat vectors and to give guidance for
   implementers on selecting appropriate, existing countermeasures.
   There are thus no IANA considerations.













































Seedorf, et al.         Expires February 17, 2012              [Page 24]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


8.  Acknowledgements

   This document has originally been inspired by the VOIPSA VoIP
   Security and Privacy Threat Taxonomy.  The authors would like to
   thank VOIPSA for having produced a comprehensive taxonomy as the
   starting point of this draft.  Additionally, the authors would like
   to thank Cullen Jennings, Jon Peterson, David Schwartz, Hadriel
   Kaplan, Peter Koch, Daryl Malas, Jason Livingood, and Robert Sparks
   for useful comments to previous editions of this draft on the mailing
   list as well as during IETF meetings.

   Jan Seedorf and Saverio Niccolini are partially supported by the
   DEMONS project, a research project supported by the European
   Commission under its 7th Framework Program (contract no. 257315).
   The views and conclusions contained herein are those of the authors
   and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the DEMONS project or the European Commission.

































Seedorf, et al.         Expires February 17, 2012              [Page 25]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


9.  Informative References

   [refs.voipsataxonomy]
              Zar, J. and et al, "VOIPSA VoIP Security and Privacy
              Threat Taxonomy, Public Release 1.0",
               http://www.voipsa.org/Activities/taxonomy.php,
              October 2005.

   [refs.speermintarch]
              Malas, D. and J. Livingood, "SPEERMINT Peering
              Architecture", draft-ietf-speermint-architecture-19 (work
              in progress), February 2011.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation Protocol (SIP)", RFC 4474, August 2006.

   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486,
              March 2009.

   [RFC4568]  Andreasen, F., Baugher, M., and D. Wing, "Session
              Description Protocol (SDP) Security Descriptions for Media
              Streams", RFC 4568, July 2006.

   [I-D.ietf-drinks-spprov]
              Mule, J., Cartwright, K., Ali, S., and A. Mayrhofer,
              "Session Peering Provisioning Protocol",
              draft-ietf-drinks-spprov-09 (work in progress), July 2011.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [refs.dbsec]
              Gertz, M. and S. Jajodia, "Handbook of Database Security",
               Springer, 2008.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.



Seedorf, et al.         Expires February 17, 2012              [Page 26]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
              Initiation Protocol (SIP)", RFC 3323, November 2002.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [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.

   [RFC3324]  Watson, M., "Short Term Requirements for Network Asserted
              Identity", RFC 3324, November 2002.

   [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.

   [RFC3893]  Peterson, J., "Session Initiation Protocol (SIP)
              Authenticated Identity Body (AIB) Format", RFC 3893,
              September 2004.

   [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.

   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
              Service Considerations", RFC 4732, December 2006.

   [RFC5351]  Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An
              Overview of Reliable Server Pooling Protocols", RFC 5351,
              September 2008.

   [RFC5352]  Stewart, R., Xie, Q., Stillman, M., and M. Tuexen,
              "Aggregate Server Access Protocol (ASAP)", RFC 5352,



Seedorf, et al.         Expires February 17, 2012              [Page 27]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


              September 2008.

   [RFC5353]  Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A.
              Silverton, "Endpoint Handlespace Redundancy Protocol
              (ENRP)", RFC 5353, September 2008.

   [refs.protos]
              Wieser, C., Laakso, M., and H. Schulzrinne, "SIP
              Robustness Testing for Large-Scale Use",  First
              International Workshop on Software Quality (SOQUA 2004),
              September 2004.

   [RFC4475]  Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
              and H. Schulzrinne, "Session Initiation Protocol (SIP)
              Torture Test Messages", RFC 4475, May 2006.

   [RFC5853]  Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
              A., and M. Bhatia, "Requirements from Session Initiation
              Protocol (SIP) Session Border Control (SBC) Deployments",
              RFC 5853, April 2010.

   [RFC6271]  Mule, J-F., "Requirements for SIP-Based Session Peering",
              RFC 6271, June 2011.




























Seedorf, et al.         Expires February 17, 2012              [Page 28]

Internet-Draft    SPEERMINT Threats and Countermeasures      August 2011


Authors' Addresses

   Jan Seedorf
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 4342 221
   Email: jan.seedorf@nw.neclab.eu
   URI:   http://www.nw.neclab.eu


   Saverio Niccolini
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 4342 118
   Email: saverio.niccolini@nw.neclab.eu
   URI:   http://www.nw.neclab.eu


   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


   Hendrik Scholz
   VOIPFUTURE GmbH
   Wendenstrasse 4
   Hamburg  20097
   Germany

   Phone: +49 (0) 40 688 900 166
   Email: hendrik.scholz@voipfuture.com
   URI:   http://voipfuture.com








Seedorf, et al.         Expires February 17, 2012              [Page 29]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/