Network Working Group                                        J. Loughney
Internet-Draft                                     Nokia Research Center
Expires: April 28, August 1, 2003                                        M. Tuexen
                                                              Siemens AG
                                                        J. Pastor-Balbas
                                                        October 28, 2002
                                                        January 31, 2003

             Security Considerations for SIGTRAN Protocols

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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-

   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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 28, August 1, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.


   This documents discusses how TLS and IPSec can be used to secure the
   communication which is based on for SIGTRAN protocols.

Table  The support of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.3 Abbreviations  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Security in telephony networks . . . . . . . . . . . . . . . .  5
   3.  Threats  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Protecting Confidentiality . . . . . . . . . . . . . . . . . .  7
   5. IPSec Usage  . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6. is
   mandatory for all nodes running SIGTRAN protocols and the support of
   TLS Usage  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Peer-to-Peer Considerations  . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18 is optional.

1. Introduction

1.1 Overview

   The SIGTRAN protocols are designed to carry signaling messages for
   telephony services.  These protocols will be used between

   o  customer premise and service provider equipment in case of IUA

   o  service provider equipment only.  This is the case for M2UA, M2PA,
      M3UA and SUA.  The carriers may be different and may use other
      transport network providers.

   The security requirements for these situations may be different.

   SIGTRAN protocols involve the security needs of several parties: the
   end-users of the services; the service providers and the applications
   involved.  Additional security requirements may come from local
   regulation.  While having some overlapping security needs, any
   security solution should fulfill all of the different parties' needs.

   The SIGTRAN protocols assume that messages are secured by using
   either IPSec or TLS.

1.2 Terminology

   This document uses the following terms:

   TBD: TDB.

1.3 Abbreviations

   This document uses the following abbreviations:

   CA: Certificate Authority.

   DOI: Domain Of Interpretation.

   ESP: Encapsulating Security Payload.

   FQDN: Full-Qualified Domain Names.

   IPSec: IP Security Protocol.

   IKE: Internet Key Exchange Protocol.

   ISDN: Integrated Services Digital Network.

   IUA: ISDN Q.921 User Adaptation Layer.

   M2PA: SS7 MTP2 Peer-to-Peer User Adaptation Layer.

   M2UA: SS7 MTP2 User Adaptation Layer.

   M3UA: SS7 MTP3 User Adaptation Layer.

   PKI: Public Key Infrastructure.

   SA: Security Association.

   SCTP: Stream Control Transmission Protocol.

   SS7: Signaling System No.  7.

   SUA: SS7 SCCP User Adaptation Layer.

   TLS: Transport Layer Security.

2. Convention

   they appear in this document, are to be interpreted as described in

3. Security in telephony networks

   The security in telephony networks is mainly based on the trusted
   network principle.  There are two totally different protocol main protocols used:
   The ISDN access protocol is Access
   protocols (ISDN and others) are used for signaling in the access
   network and the SS7 protocol stack in the core network.

   As SS7 networks are often physically remoter remote and/or inacessable, inaccessible to
   the user, it is assumed that they are protected from malicious users.
   Often, equipment is under lock and key.  At network boundaries
   between SS7 networks, packet filtering is sometimes used.  End-users
   are not directly connected to SS7 networks.

   The ISDN access protocol is the separate protocol stack protocols are used for end-user signaling.  End-user
   signaling protocols are translated to SS7 based protocols by
   telephone switches run by network operators.

   Often Regulatory Authorities require SS7 switches with connections to
   different SS7 to be conformant to national and/or international test

   There are no standardized ways of using encryption technologies for
   providing confidentiality or using technologies for authentication.

   This description applies to telephony networks operated by a single
   operator but also to multiple telephony networks being connected and
   operated by different operators.


4. Threats

   There and Goals

   The Internet threats can be divided into one of two main types.  The
   first one is no quick fix, one-size-fits-all solution called "passive attacks".  It happens whenever the
   attacker reads packets off the network but does not write them.
   Examples of such attacks include confidentiality violations, password
   sniffing and offline cryptographic attacks amongst others.

   The second kind of threads is called "active attacks".  In this case
   the attacker also writes data to the network.  Examples for security.  All
   SIGTRAN this
   attack include replay attacks, message insertion, message deletion,
   message modification or man in the middle attacks amongst others.

   In general, Internet protocols have the following security

   o  Availability of reliable and timely user data transport.

   o  Communication Security:

      *  Authentication of peers.


      *  Integrity of user data transport.


      *  Confidentiality of user data.

   o  Non-repudation.

   o  System Security, avoidance of:

      *  Unauthorized use.

      *  Unappropiate use.

      *  Denial of Service.

   Communication security is mandatory in some network scenarios to
   prevent malicious attacks.  The main goal of this document is to
   recommend the minimum security means that a SIGTRAN node must
   implement in order to achieve a secured communication.  To get this
   goal, we will explore the different security options that regarding
   communication exist.

   All SIGTRAN protocols use the Stream Control Transmission Protocol
   (SCTP) being defined in [7] [8] and [9] [10] as its transport protocol.  SCTP
   provides certain transport related security features, such as: as
   resistance against:

   o  Blind Denial of Service Attacks

   o such as:

      *  Flooding


      *  Masquerade


      *  Improper Monopolization of Services

   When SIGTRAN protocols are running in professionally managed
   corporate or service provider network, it

   There is reasonable to expect
   that this network include an appropriate security policy framework.
   The "Site Security Handbook" [1] should be consulted no quick fix, one-size-fits-all solution for guidance. security.

   When the network in which SIGTRAN protocols are used involves more
   than one party, it may not be reasonable to expect that all parties
   have implemented security in a sufficient manner.  End-to-end
   security should be the goal; therefore, it is recommended that IPSec
   or TLS is used to ensure confidentiality of user payload.  Consult
   [3] for more information on configuring IPSec services.

4. Protecting Confidentiality

   If SIGTRAN information has to be protected either IPSec ESP in
   transport mode or TLS can should be used.  In both cases the IP header
   information goal; therefore, it is neither encrypted nor protected.  If recommended that IPSec ESP is
   chosen the SCTP control information is encrypted and protected
   whereas if the
   or TLS based solution the SCTP control information is not
   encrypted and only protected by SCTP procedures. used to ensure confidentiality of user payload.  Consult
   [4] for more information on configuring IPSec services.

5. IPSec Usage

   This section is relevant only for SIGTRAN nodes using IPSec to secure
   communication between SIGTRAN node. nodes.

   All SIGTRAN nodes using IPSec MUST support IPsec IPSec ESP [4] [5] in transport
   mode with non-null encryption and authentication algorithms to
   provide per-packet authentication, integrity protection and
   confidentiality, and MUST support the replay protection mechanisms of
   IPSec.  In those scenarios where IP layer protection is needed, ESP
   in tunnel mode SHOULD be used.

   These nodes MUST support IKE for peer authentication, negotiation of
   security associations, and key management, using the IPsec IPSec DOI [5]. [6].
   The IPSec implementations MUST support peer authentication using a
   pre-shared key, and MAY support certificate-based peer authentication
   using digital signatures.  Peer authentication using the public key
   encryption methods outlined in IKE's sections 5.2 and 5.3 [6] [7] SHOULD
   NOT be used.

   Conformant implementations MUST support both IKE Main Mode and
   Aggressive Mode.  When  For transport mode, when pre-shared keys are used
   for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main
   Mode SHOULD NOT be used.  When digital signatures are used for
   authentication, either IKE Main Mode or IKE Aggressive Mode MAY be
   used.  When using ESP tunnel mode, IKE Main Mode MAY be used to
   create ISAKMP association with identity protection during Phase 1.

   When digital signatures are used to achieve authentication, an IKE
   negotiator SHOULD use IKE Certificate Request Payload(s) to specify
   the certificate authority (or authorities) that are trusted in
   accordance with its local policy.  IKE negotiators SHOULD use
   pertinent certificate revocation checks before accepting a PKI
   certificate for use in IKE's authentication procedures.

   The Phase 2 Quick Mode exchanges used to negotiate protection for
   SIGTRAN sessions MUST explicitly carry the Identity Payload fields
   (IDci and IDcr).  The DOI provides for several types of
   identification data.  However, when used in conformant
   implementations, each ID Payload MUST carry a single IP address and a
   single non-zero port number, and MUST NOT use the IP Subnet or IP
   Address Range formats.  This allows the Phase 2 security association
   to correspond to specific TCP and SCTP connections.

   Since IPsec IPSec acceleration hardware may only be able to handle a
   limited number of active IKE Phase 2 SAs, Phase 2 delete messages may
   be sent for idle SAs, as a means of keeping the number of active
   Phase 2 SAs to a minimum.  The receipt of an IKE Phase 2 delete
   message SHOULD NOT be interpreted as a reason for tearing down a
   SIGTRAN session.  Rather, it is preferable to leave the connection
   up, and if additional traffic is sent on it, to bring up another IKE
   Phase 2 SA to protect it.  This avoids the potential for continually
   bringing connections up and down.

   It should be noted that SCTP supports multi-homed hosts and this
   results in the need for having multiple security associations for one
   SCTP association.  This disadvantage of IPSec has been addressed by
   [15].  So IPSec implementations used by SIGTRAN nodes SHOULD support
   the IPSec feature described in [14]. [15].

6. TLS Usage

   This section is relevant only for SIGTRAN nodes using TLS to secure
   the communication between SIGTRAN nodes.

   A SIGTRAN node that initiates a SCTP association to another SIGTRAN
   node acts as a TLS client according to [2], [3], and a SIGTRAN node that
   accepts a connection acts as a TLS server.  SIGTRAN peers
   implementing TLS for security MUST mutually authenticate as part of
   TLS session establishment.  In order to ensure mutual authentication,
   the SIGTRAN node acting as TLS server must request a certificate from
   the SIGTRAN node acting as TLS client, and the SIGTRAN node acting as
   TLS client MUST be prepared to supply a certificate on request.

   [13] requires the support of the cipher suite
   TLS_RSA_WITH_AES_128_CBC_SHA.  SIGTRAN nodes MAY negotiate other TLS
   cipher suites.

   TLS MUST be used on all bi-directional streams and the other uni-
   uni-directional streams MUST NOT be used.

   It should also be noted that a SCTP implementation used for TLS over
   SCTP MUST support fragmentation of user data and might also need to
   support the partial delivery API.  This holds even if all SIGTRAN
   messages are small.  See [13] for more details.

   The SIGTRAN protocols use separate the same SCTP port numbers number and payload
   protocol identifiers identifier when run over TLS.  These numbers are given in
   Section 9.  A SIGTRAN session MUST be aborted if upgrade procedure
   has to used to initiate the TLS based communication.

   Because TLS only protects the port number or payload protocol identifier indicates the use SCTP header and all control
   chunks are not protected.  This can be used for DoS attacks.  This is
   a general problem with security provided at the transport layer.

7. Support of TLS IPSec and it TLS

   If content of SIGTRAN protocol messages is not

   As an alternative to a separate port number, a session upgrade
   procedure be protected, either
   IPSec ESP in transport mode or TLS can be used.  This needs an extension  for all adaptation
   layers allowing  In both cases the IP
   header information is neither encrypted nor protected.  If IPSec ESP
   is chosen the SCTP control information is encrypted and protected
   whereas if the TLS based solution the SCTP control information is not
   encrypted and only protected by SCTP procedures.

   In general, both IPSec and TLS have enough mechanisms to secure the
   SIGTRAN protocols communications.  Nevertheless, due to use the same port number wider deployment of
   IPSec, it is foreseen a faster development and market support for
   this protocol.

   Therefore, in order to have a secured model working as soon as
   possible, the case where TLS following recommendation is used or not.  This needs further discussions.

7. made: A SIGTRAN node MUST
   support IPSec and MAY support TLS.

8. Peer-to-Peer Considerations

   M2PA, M3UA and SUA support the peer-to-peer model as a generalization
   to the client-server model which is supported by IUA and M2UA.  A
   SIGTRAN node running M2PA, M3UA or SUA and operating in the peer-to-
   peer-to-peer mode is called a SIGTRAN peer.

   As with any peer-to-peer protocol, proper configuration of the trust
   model within a peer is essential to security.  When certificates are
   used, it is necessary to configure the root certificate authorities
   trusted by the peer.  These root CAs are likely to be unique to
   SIGTRAN usage and distinct from the root CAs that might be trusted
   for other purposes such as Web browsing.  In general, it is expected
   that those root CAs will be configured so as to reflect the business
   relationships between the organization hosting the peer and other
   organizations.  As a result, a peer will typically not be configured
   to allow connectivity with any arbitrary peer.  When certificate
   authentication peers may not be known beforehand, and therefore peer
   discovery may be required.

   Note that IPsec IPSec is considerably less flexible than TLS when it comes
   to configuring root CAs.  Since use of Port identifiers is prohibited
   within IKE Phase 1, within IPsec IPSec it is not possible to uniquely
   configure trusted root CAs for each application individually; the
   same policy must be used for all applications.  This implies, for
   example, that a root CA trusted for use with a SIGTRAN protocol must
   also be trusted to protect SNMP.  These restrictions can be awkward
   at best.  Since TLS supports application-level granularity in
   certificate policy, TLS SHOULD be used to protect SIGTRAN sessions
   between administrative domains.  IPsec  IPSec is most appropriate for intra-
   intra-domain usage when pre-shared keys are used as a security

   When pre-shared key authentication is used with IPSec to protect
   SIGTRAN based communication, unique pre-shared keys are configured
   with peers, who are identified by their IP address (Main Mode), or
   possibly their FQDN (AggressivenMode).  As a result, it is necessary
   for the set of peers to be known beforehand.  Therefore, peer
   discovery is typically not necessary.

   The following is intended to provide some guidance on the issue.

   It is recommended that SIGTRAN peers use the same security mechanism
   (IPSec or TLS) across all its sessions with other SIGTRAN peers.
   Inconsistent use of security mechanisms can result in redundant
   security mechanisms being used (e.g.  TLS over IPsec) IPSec) or worse,
   potential security vulnerabilities.  When IPsec IPSec is used with a
   SIGTRAN protocol, a typical security policy for outbound traffic is
   "Initiate IPsec, IPSec, from me to any, destination port P"; for inbound
   traffic, the policy would be "Require IPsec, IPSec, from any to me,
   destination port P".  Here P denotes one of the registered port
   numbers for a SIGTRAN protocol.

   This policy causes IPSec to be used whenever a SIGTRAN peer initiates
   a session to another SIGTRAN peer, and to be required whenever an
   inbound SIGTRAN session occurs.  This policy is attractive, since it
   does not require policy to be set for each peer or dynamically
   modified each time a new SIGTRAN session is created; an IPSec SA is
   automatically created based on a simple static policy.  Since IPSec
   extensions are typically not available to the sockets API on most
   platforms, and IPsec IPSec policy functionality is implementation
   dependent, use of a simple static policy is the often the simplest
   route to IPSec-enabling a SIGTRAN peer.

   If IPSec is used to secure SIGTRAN peer-to-peer session, IPSec policy
   SHOULD be set so as to require IPsec IPSec protection for inbound
   connections, and to initiate IPsec IPSec protection for outbound
   connections.  This can be accomplished via use of inbound and
   outbound filter policy.


9. Security Considerations

   This documents discusses the usage of IPSec and TLS for securing
   SIGTRAN traffic.


10. IANA Considerations

   SCTP port numbers and SCTP payload protocol identifiers

   No actions have to be
   registered for:

   o  IUA over TLS

   o  M2UA over TLS

   o  M2PA over TLS

   o  M3UA over TLS

   o  SUA over TLS

10. taken by IANA.

11. Acknowledgements

   The authors would like to thank B.  Aboba, K.  Morneau  Morneault and many
   others for their invaluable comments and suggestions.

Normative References

   [1]   Fraser, B., "Site Security Handbook",  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2196, September 2119, March 1997.

   [2]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
        9, RFC 2026, October 1996.

Informative References

   [3]   Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
         P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January


   [4]   Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.


   [5]   Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
         (ESP)", RFC 2406, November 1998.


   [6]   Piper, D., "The Internet IP Security Domain of Interpretation
         for ISAKMP", RFC 2407, November 1998.


   [7]   Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
         RFC 2409, November 1998.


   [8]   Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
         H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
         "Stream Control Transmission Protocol", RFC 2960, October 2000.


   [9]   Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom,
         "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.


   [10]  Stone, J., Stewart, R. and D. Otis, "Stream Control
         Transmission Protocol (SCTP) Checksum Change", RFC 3309,
         September 2002.


   [11]  Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B. and J.
         Heitz, "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2)
         - User Adaptation Layer", RFC 3331, September 2002.


   [12]  Sidebottom, G., Morneault, K. and J. Pastor-Balbas, "Signaling
         System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation
         Layer (M3UA)", RFC 3332, September 2002.


   [13]  Tuexen, M., Jungmaier, A. and E. Rescorla, "Transport Layer
         Security over Stream Control Transmission Protocol", RFC 3436,
         December 2002.

   [14]  George, T., "SS7 MTP2-User Peer-to-Peer Adaptation Layer",
         draft-ietf-sigtran-m2pa-07 (work in progress), August 2002.

   [13]  Rescorla, E., Tuexen, M. and A. Jungmaier, "TLS over SCTP",
         draft-ietf-tsvwg-tls-over-sctp-00 (work in progress), November

   [14] January 2003.

   [15]  Bellovin, S., "On the Use of SCTP with IPsec", draft-ietf-
         draft-ietf-ipsec-sctp-04 (work in progress), October 2002.

Authors' Addresses

   John Loughney
   Nokia Research Center
   PO Box 407
   FIN-00045 Nokia Group


   Michael Tuexen
   Siemens AG
   Hofmannstr. 51
   81359 Munich

   Javier Pastor-Balbas
   Avenida de los Poblados, 13
   28033 Madrid


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive

Full Copyright Statement

   Copyright (C) The Internet Society (2002). (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. assignees.

   This document and the information contained herein is provided on an


   Funding for the RFC Editor function is currently provided by the
   Internet Society.