< draft-smyslov-ipsecme-tcp-guidelines-01.txt   draft-smyslov-ipsecme-tcp-guidelines-02.txt >
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Informational December 18, 2018 Intended status: Informational June 18, 2019
Expires: June 21, 2019 Expires: December 20, 2019
Clarifications and Implementation Guidelines for using TCP Encapsulation Clarifications and Implementation Guidelines for using TCP Encapsulation
in IKEv2 in IKEv2
draft-smyslov-ipsecme-tcp-guidelines-01 draft-smyslov-ipsecme-tcp-guidelines-02
Abstract Abstract
The Internet Key Exchange Protocol version 2 (IKEv2) defined in The Internet Key Exchange Protocol version 2 (IKEv2) defined in
[RFC7296] uses UDP transport for its messages. [RFC8229] specifies a [RFC7296] uses UDP transport for its messages. [RFC8229] specifies a
way to encapsulate IKEv2 and ESP (Encapsulating Security Payload) way to encapsulate IKEv2 and ESP (Encapsulating Security Payload)
messages in TCP, thus making possible to use them in network messages in TCP, thus making possible to use them in network
environments that block UDP traffic. However, some nuances of using environments that block UDP traffic. However, some nuances of using
TCP in IKEv2 are not covered by that specification. This document TCP in IKEv2 are not covered by that specification. This document
provides clarifications and implementation guidelines for [RFC8229]. provides clarifications and implementation guidelines for [RFC8229].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 21, 2019. This Internet-Draft will expire on December 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
3. TCP Encapsulation Format . . . . . . . . . . . . . . . . . . 3 3. TCP Encapsulation Format . . . . . . . . . . . . . . . . . . 3
4. Falling back from UDP to TCP . . . . . . . . . . . . . . . . 3 4. Falling back from UDP to TCP . . . . . . . . . . . . . . . . 4
5. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 4 5. Retransmissions . . . . . . . . . . . . . . . . . . . . . . . 4
6. Using Cookies and Puzzles . . . . . . . . . . . . . . . . . . 4 6. Using Cookies and Puzzles . . . . . . . . . . . . . . . . . . 4
7. Error Handling in the IKE_SA_INIT . . . . . . . . . . . . . . 5 7. Error Handling in the IKE_SA_INIT . . . . . . . . . . . . . . 5
8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 6 8. Interaction with IKEv2 Extensions . . . . . . . . . . . . . . 6
8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 6 8.1. MOBIKE Protocol . . . . . . . . . . . . . . . . . . . . . 6
8.2. IKEv2 Redirect . . . . . . . . . . . . . . . . . . . . . 7 8.2. IKEv2 Redirect . . . . . . . . . . . . . . . . . . . . . 7
8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 7 8.3. IKEv2 Session Resumption . . . . . . . . . . . . . . . . 7
8.4. IKEv2 Protocol Support for High Availability . . . . . . 7 8.4. IKEv2 Protocol Support for High Availability . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The Internet Key Exchange version 2 (IKEv2) as it is defined in The Internet Key Exchange version 2 (IKEv2) as it is defined in
[RFC7296] uses UDP as a transport protocol. As time passed the [RFC7296] uses UDP as a transport protocol. As time passed the
network environment has been evolved and sometimes this evolution has network environment has been evolved and sometimes this evolution has
resulted in situations when UDP messages are dropped by network resulted in situations when UDP messages are dropped by network
infrastructure. This may happen either by incapability of network infrastructure. This may happen either by incapability of network
devices to properly handle them (e.g. non-initial fragments of UDP devices to properly handle them (e.g. non-initial fragments of UDP
skipping to change at page 3, line 42 skipping to change at page 3, line 42
is prepended with 16-bit Length field. However, the text in the is prepended with 16-bit Length field. However, the text in the
first para of the section is not very explicit on what the Length first para of the section is not very explicit on what the Length
field means - whether it indicates only the length of the following field means - whether it indicates only the length of the following
IKE or ESP message or the length of field itself is also counted. IKE or ESP message or the length of field itself is also counted.
The following text in the same section clarifies it - the value of The following text in the same section clarifies it - the value of
the Length field includes the length of the field itself (2 octets). the Length field includes the length of the field itself (2 octets).
It means that values 0 and 1 must never appear there. The receiver It means that values 0 and 1 must never appear there. The receiver
MUST treat these values in the Length field as fatal error and MUST MUST treat these values in the Length field as fatal error and MUST
close TCP session in this case. close TCP session in this case.
Note, that since TCP header is longer than UDP header, and TCP
encapsulation also requires prepending of 16-bit Length field, some
very long ESP and IKE messages that could be sent over UDP cannot be
encapsulated in TCP, because their total length after encapsulation
would exceed 65535 and thus could not be represented in Length field.
4. Falling back from UDP to TCP 4. Falling back from UDP to TCP
Section 5.1 of [RFC8229] describes how the fallback from UDP to TCP Section 5.1 of [RFC8229] describes how the fallback from UDP to TCP
must be handled. It is recommended, that in the absence of prior must be handled. It is recommended, that in the absence of prior
knowledge, implementations first try to use UDP and then fall back knowledge, implementations first try to use UDP and then fall back
TCP if no reply is received within some period of time after several TCP if no reply is received within some period of time after several
retransmissions. In this case a new IKE_SA_INIT exchange MUST be retransmissions. In this case a new IKE_SA_INIT exchange MUST be
initiated with new initiator's SPI and with recalculated content of initiated with new initiator's SPI and with recalculated content of
NAT_DETECTION_SOURCE_IP notification. NAT_DETECTION_SOURCE_IP notification.
skipping to change at page 8, line 38 skipping to change at page 9, line 4
Security considerations concerning using TCP encapsulation in IKEv2 Security considerations concerning using TCP encapsulation in IKEv2
and ESP are given in [RFC8229]. This memo doesn't provide additional and ESP are given in [RFC8229]. This memo doesn't provide additional
security considerations. security considerations.
10. Acknowledgements 10. Acknowledgements
Author would like to thank Tommy Pauly and Tero Kivinen for their Author would like to thank Tommy Pauly and Tero Kivinen for their
valuable comments. valuable comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>. <https://www.rfc-editor.org/info/rfc4555>.
[RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for [RFC5685] Devarapalli, V. and K. Weniger, "Redirect Mechanism for
the Internet Key Exchange Protocol Version 2 (IKEv2)", the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5685, DOI 10.17487/RFC5685, November 2009, RFC 5685, DOI 10.17487/RFC5685, November 2009,
<https://www.rfc-editor.org/info/rfc5685>. <https://www.rfc-editor.org/info/rfc5685>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
DOI 10.17487/RFC5723, January 2010, <https://www.rfc- DOI 10.17487/RFC5723, January 2010,
editor.org/info/rfc5723>. <https://www.rfc-editor.org/info/rfc5723>.
[RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D. [RFC6311] Singh, R., Ed., Kalyani, G., Nir, Y., Sheffer, Y., and D.
Zhang, "Protocol Support for High Availability of IKEv2/ Zhang, "Protocol Support for High Availability of IKEv2/
IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011, IPsec", RFC 6311, DOI 10.17487/RFC6311, July 2011,
<https://www.rfc-editor.org/info/rfc6311>. <https://www.rfc-editor.org/info/rfc6311>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019, Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016, <https://www.rfc- DOI 10.17487/RFC8019, November 2016,
editor.org/info/rfc8019>. <https://www.rfc-editor.org/info/rfc8019>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
11.2. Informative References 11.2. Informative References
[RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2
Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
DOI 10.17487/RFC4621, August 2006, <https://www.rfc- DOI 10.17487/RFC4621, August 2006,
editor.org/info/rfc4621>. <https://www.rfc-editor.org/info/rfc4621>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>. 2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, (IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014, <https://www.rfc- DOI 10.17487/RFC7383, November 2014,
editor.org/info/rfc7383>. <https://www.rfc-editor.org/info/rfc7383>.
Author's Address Author's Address
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd) 124460
RU RU
Phone: +7 495 276 0211 Phone: +7 495 276 0211
 End of changes. 15 change blocks. 
21 lines changed or deleted 26 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/