Squashed 'third_party/lksctp-tools/' content from commit 200eca7f1
Change-Id: I8f7575513f114b205178cac5c6b3706f3d725cb5
git-subtree-dir: third_party/lksctp-tools
git-subtree-split: 200eca7f1419b1ae53958b51e8551f7e7f6cd467
diff --git a/doc/rfc3554.txt b/doc/rfc3554.txt
new file mode 100644
index 0000000..23ae9cd
--- /dev/null
+++ b/doc/rfc3554.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group S. Bellovin
+Request for Comments: 3554 J. Ioannidis
+Category: Standards Track AT&T Labs - Research
+ A. Keromytis
+ Columbia University
+ R. Stewart
+ Cisco
+ July 2003
+
+
+ On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document describes functional requirements for IPsec (RFC 2401)
+ and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in
+ securing SCTP (RFC 2960) traffic.
+
+1. Introduction
+
+ The Stream Control Transmission Protocol (SCTP) is a reliable
+ transport protocol operating on top of a connection-less packet
+ network such as IP. SCTP is designed to transport PSTN signaling
+ messages over IP networks, but is capable of broader applications.
+
+ When SCTP is used over IP networks, it may utilize the IP security
+ protocol suite [RFC2402][RFC2406] for integrity and confidentiality.
+ To dynamically establish IPsec Security Associations (SAs), a key
+ negotiation protocol such as IKE [RFC2409] may be used.
+
+ This document describes functional requirements for IPsec and IKE to
+ facilitate their use in securing SCTP traffic. In particular, we
+ discuss additional support in the form of a new ID type in IKE
+ [RFC2409] and implementation choices in the IPsec processing to
+ accommodate for the multiplicity of source and destination addresses
+ associated with a single SCTP association.
+
+
+
+Bellovin, et. al. Standards Track [Page 1]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+1.1. Terminology
+
+ In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
+ "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
+ described in [RFC-2119].
+
+2. SCTP over IPsec
+
+ When utilizing the Authentication Header [RFC2402] or Encapsulating
+ Security Payload [RFC2406] protocols to provide security services for
+ SCTP frames, the SCTP frame is treated as just another transport
+ layer protocol on top of IP (same as TCP, UDP, etc.)
+
+ IPsec implementations should already be able to use the SCTP
+ transport protocol number as assigned by IANA as a selector in their
+ Security Policy Database (SPD). It should be straightforward to
+ extend existing implementations to use the SCTP source and
+ destination port numbers as selectors in the SPD. Since the concept
+ of a port, and its location in the transport header is
+ protocol-specific, the IPsec code responsible for identifying the
+ transport protocol ports has to be suitably modified. This, however
+ is not enough to fully support the use of SCTP in conjunction with
+ IPsec.
+
+ Since SCTP can negotiate sets of source and destination addresses
+ (not necessarily in the same subnet or address range) that may be
+ used in the context of a single association, the SPD should be able
+ to accommodate this. The straightforward, and expensive, way is to
+ create one SPD entry for each pair of source/destination addresses
+ negotiated. A better approach is to associate sets of addresses with
+ the source and destination selectors in each SPD entry (in the case
+ of non-SCTP traffic, these sets would contain only one element).
+ While this is an implementation decision, implementors are encouraged
+ to follow this or a similar approach when designing or modifying the
+ SPD to accommodate SCTP-specific selectors.
+
+ Similarly, SAs may have multiple associated source and destination
+ addresses. Thus an SA is identified by the extended triplet ({set of
+ destination addresses}, SPI, Security Protocol). A lookup in the
+ Security Association Database (SADB) using the triplet (Destination
+ Address, SPI, Security Protocol), where Destination Address is any of
+ the negotiated peer addresses, MUST return the same SA.
+
+
+
+
+
+
+
+
+
+Bellovin, et. al. Standards Track [Page 2]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+3. SCTP and IKE
+
+ There are two issues relevant to the use of IKE when negotiating
+ protection for SCTP traffic:
+
+ a) Since SCTP allows for multiple source and destination network
+ addresses associated with an SCTP association, it MUST be possible
+ for IKE to efficiently negotiate these in the Phase 2 (Quick Mode)
+ exchange. The straightforward approach is to negotiate one pair of
+ IPsec SAs for each combination of source and destination addresses.
+ This can result in an unnecessarily large number of SAs, thus wasting
+ time (in negotiating these) and memory. All current implementations
+ of IKE support this functionality. However, a method for specifying
+ multiple selectors in Phase 2 is desirable for efficiency purposes.
+ Conformance with this document requires that implementations adhere
+ to the guidelines in the rest of this section.
+
+ Define a new type of ID, ID_LIST, that allows for recursive inclusion
+ of IDs. Thus, the IKE Phase 2 Initiator ID for an SCTP association
+ MAY be of type ID_LIST, which would in turn contain as many
+ ID_IPV4_ADDR IDs as necessary to describe Initiator addresses;
+ likewise for Responder IDs. Note that other selector types MAY be
+ used when establishing SAs for use with SCTP, if there is no need to
+ use negotiate multiple addresses for each SCTP endpoint (i.e., if
+ only one address is used by each peer of an SCTP flow).
+ Implementations MUST support this new ID type.
+
+ ID_LIST IDs cannot appear inside ID_LIST ID payloads. Any of the ID
+ types defined in [RFC2407] can be included inside an ID_LIST ID.
+ Each of the IDs contained in the ID_LIST ID must include a complete
+ Identification Payload header.
+
+ The following diagram illustrates the content of an ID_LIST ID
+ payload that contains two ID_FQDN payloads.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin, et. al. Standards Track [Page 3]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! ID Type ! Protocol ID ! Port !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! ID Type ! Protocol ID ! Port !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ FQDN 1 Identification Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! ID Type ! Protocol ID ! Port !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ FQDN 2 Identification Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Next Payload field in any of the included IDs (for FQDN 1 and
+ FQDN 2) MUST be ignored by the Responder. The Payload Length, ID
+ Type, Protocol ID, and Port fields of the included Payloads should be
+ set to the appropriate values. The Protocol ID and Port fields of
+ the ID_LIST Payload should be set to zero by the Initiator and MUST
+ be ignored by the Responder.
+
+ Different types of IDs (e.g., an ID_FQDN and an ID_IPV4_ADDR) can be
+ included inside the same ID_LIST ID. If an ID type included in an
+ ID_LIST ID payload is invalid in the context the ID_LIST ID is used,
+ the whole ID_LIST should be considered to be at fault, e.g., if an
+ ID_LIST ID payload that contains an ID_FQDN and an ID_IPV4_ADDR is
+ received during an IKE Quick Mode exchange, the Responder should
+ signal a fault to the Initiator and stop processing of the message
+ (the same behavior it would exhibit if simply an ID_FQDN was received
+ instead).
+
+ The IANA-assigned number for the ID_LIST ID is 12.
+
+ b) For IKE to be able to validate the Phase 2 selectors, it must be
+ possible to exchange sufficient information during Phase 1.
+ Currently, IKE can directly accommodate the simple case of two peers
+ talking to each other, by using Phase 1 IDs corresponding to their IP
+ addresses, and encoding those same addresses in the SubjAltName of
+ the certificates used to authenticate the Phase 1 exchange. For more
+ complicated scenarios, external policy (or some other mechanism)
+ needs to be consulted, to validate the Phase 2 selectors and SA
+ parameters. All addresses presented in Phase 2 selectors MUST be
+ validated. That is, enough evidence must be presented to the
+
+
+
+Bellovin, et. al. Standards Track [Page 4]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+ Responder that the Initiator is authorized to receive traffic for all
+ addresses that appear in the Phase 2 selectors. This evidence can be
+ derived from the certificates exchanged during Phase 1 (if possible);
+ otherwise it must be acquired through out-of-band means (e.g., policy
+ mechanism, configured by the administrator, etc.).
+
+ In order to accommodate the same simple scenario in the context of
+ multiple source/destination addresses in an SCTP association, it MUST
+ be possible to:
+
+ 1) Specify multiple Phase 1 IDs, which are used to validate Phase
+ 2 parameters (in particular, the Phase 2 selectors). Following
+ the discussion on an ID_LIST ID type, it is possible to use the
+ same method for specifying multiple Phase 1 IDs.
+
+ 2) Authenticate the various Phase 1 IDs. Using pre-shared key
+ authentication, this is possible by associating the same shared
+ key with all acceptable peer Phase 1 IDs. In the case of
+ certificates, we have two alternatives:
+
+ a) The same certificate can contain multiple IDs encoded in
+ the SubjAltName field, as an ASN.1 sequence. Since this is
+ already possible, it is the preferred solution and any
+ conformant implementations MUST support this.
+
+ b) Multiple certificates MAY be passed during the Phase 1
+ exchange, in multiple CERT payloads. This feature is also
+ supported by the current specification. Since only one
+ signature may be issued per IKE Phase 1 exchange, it is
+ necessary for all certificates to contain the same key as
+ their Subject. However, this approach does not offer any
+ significant advantage over (a), thus implementations MAY
+ support it.
+
+ In either case, an IKE implementation needs to verify the
+ validity of a peer's claimed Phase 1 ID, for all such IDs
+ received over an exchange.
+
+ Although SCTP does not currently support modification of the
+ addresses associated with an SCTP association (while the latter is in
+ use), it is a feature that may be supported in the future. Unless
+ the set of addresses changes extremely often, it is sufficient to do
+ a full Phase 1 and Phase 2 exchange to establish the appropriate
+ selectors and SAs.
+
+
+
+
+
+
+
+Bellovin, et. al. Standards Track [Page 5]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+ The last issue with respect to SCTP and IKE pertains to the initial
+ offer of Phase 2 selectors (IDs) by the Initiator. Per the current
+ IKE specification, the Responder must send in the second message of
+ the Quick Mode the IDs received in the first message. Thus, it is
+ assumed that the Initiator already knows all the Selectors relevant
+ to this SCTP association. In most cases however, the Responder has
+ more accurate knowledge of its various addresses. Thus, the IPsec
+ Selectors established can be potentially insufficient or inaccurate.
+
+ If the proposed set of Selectors is not accurate from the Responder's
+ point of view, the latter can start a new Quick Mode exchange. In
+ this new Quick Mode exchange, the roles of Initiator and Responder
+ have been reversed; the new Initiator MUST copy the SA and Selectors
+ from the old Quick Mode message, and modify its set of Selectors to
+ match reality. All SCTP-supporting IKE implementations MUST be able
+ to do this.
+
+4. Security Considerations
+
+ This documents discusses the use of a security protocol (IPsec) in
+ the context of a new transport protocol (SCTP). SCTP, with its
+ provision for mobility, opens up the possibility for
+ traffic-redirection attacks whereby an attacker X claims that his
+ address should be added to an SCTP session between peers A and B, and
+ be used for further communications. In this manner, traffic between
+ A and B can be seen by X. If X is not in the communication path
+ between A and B, SCTP offers him new attack capabilities. Thus, all
+ such address updates of SCTP sessions should be authenticated. Since
+ IKE negotiates IPsec SAs for use by these sessions, IKE MUST validate
+ all addresses attached to an SCTP endpoint either through validating
+ the certificates presented to it during the Phase 1 exchange, or
+ through some out-of-band method.
+
+ The Responder in a Phase 2 exchange MUST verify the Initiator's
+ authority to receive traffic for all addresses that appear in the
+ Initiator's Phase 2 selectors. Not doing so would allow for any
+ valid peer of the Responder (i.e., anyone who can successfully
+ establish a Phase 1 SA with the Responder) to see any other valid
+ peer's traffic by claiming their address.
+
+5. IANA Considerations
+
+ IANA has assigned number 12 for ID_LIST (defined in Section 3) in the
+ "IPSEC Identification Type" registry from the Internet Security
+ Association and Key Management Protocol (ISAKMP) Identifiers table.
+
+
+
+
+
+
+Bellovin, et. al. Standards Track [Page 6]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+6. Intellectual Property Rights Notice
+
+ 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
+ Director.
+
+Normative References
+
+ [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+ [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+ 2402, November 1998.
+
+ [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [RFC2407] Piper, D., "The Internet IP Security Domain of
+ Interpretation for ISAKMPD", RFC 2407, November 1998.
+
+ [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner,
+ "Internet Security Association and Key Management
+ Protocol", RFC 2408, November 1998.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [RFC2960] 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.
+
+
+
+
+Bellovin, et. al. Standards Track [Page 7]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+Authors' Addresses
+
+ Steven M. Bellovin
+ AT&T Labs - Research
+ 180 Park Avenue
+ Florham Park, New Jersey 07932-0971
+
+ Phone: +1 973 360 8656
+ EMail: smb@research.att.com
+
+
+ John Ioannidis
+ AT&T Labs - Research
+ 180 Park Avenue
+ Florham Park, New Jersey 07932-0971
+
+ EMail: ji@research.att.com
+
+
+ Angelos D. Keromytis
+ Columbia University, CS Department
+ 515 CS Building
+ 1214 Amsterdam Avenue, Mailstop 0401
+ New York, New York 10027-7003
+
+ Phone: +1 212 939 7095
+ EMail: angelos@cs.columbia.edu
+
+
+ Randall R. Stewart
+ 24 Burning Bush Trail.
+ Crystal Lake, IL 60012
+
+ Phone: +1-815-477-2127
+ EMail: rrs@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin, et. al. Standards Track [Page 8]
+
+RFC 3554 SCTP with IPsec July 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (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
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assignees.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellovin, et. al. Standards Track [Page 9]
+