< draft-ietf-ipsecme-ikev2-fragmentation-04.txt   draft-ietf-ipsecme-ikev2-fragmentation-05.txt >
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track October 18, 2013 Intended status: Standards Track November 3, 2013
Expires: April 21, 2014 Expires: May 7, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-04 draft-ietf-ipsecme-ikev2-fragmentation-05
Abstract Abstract
This document describes the way to avoid IP fragmentation of large This document describes the way to avoid IP fragmentation of large
IKEv2 messages. This allows IKEv2 messages to traverse network IKEv2 messages. This allows IKEv2 messages to traverse network
devices that don't allow IP fragments to pass through. devices that don't allow IP fragments to pass through.
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
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 http://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 April 21, 2014. This Internet-Draft will expire on May 5, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 (http://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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4 2. Protocol details . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5
2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6
2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8
2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8
2.5.3. Fragmenting Messages containing unencrypted 2.5.3. Fragmenting Messages containing unencrypted
Payloads . . . . . . . . . . . . . . . . . . . . . . . 9 Payloads . . . . . . . . . . . . . . . . . . . . . . . 10
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10
2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 11 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 12
3. Interaction with other IKE extensions . . . . . . . . . . . . 13 3. Interaction with other IKE extensions . . . . . . . . . . . . 13
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 19 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20
Appendix B. Correlation between IP Datagram size and Appendix B. Correlation between IP Datagram size and
Encrypted Payload content size . . . . . . . . . . . 20 Encrypted Payload content size . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The Internet Key Exchange Protocol version 2 (IKEv2), specified in The Internet Key Exchange Protocol version 2 (IKEv2), specified in
[RFC5996], uses UDP as a transport for its messages. When IKE [RFC5996], uses UDP as a transport for its messages. Most IKEv2
message size exceeds path MTU, it gets fragmented by IP level. The messages are relatively small, usually below several hundred bytes.
problem is that some network devices, specifically some NAT boxes, Noticeable exception is IKE_AUTH exchange, which requires fairly
don't allow IP fragments to pass through. This apparently blocks IKE large messages, up to several kbytes, especially when certificates
communication and, therefore, prevents peers from establishing IPsec are transferred. When IKE message size exceeds path MTU, it gets
SA. fragmented by IP level. The problem is that some network devices,
specifically some NAT boxes, don't allow IP fragments to pass
through. This apparently blocks IKE communication and, therefore,
prevents peers from establishing IPsec SA.
Widespread deployment of Carrier-Grade NATs (CGN) introduces new
challenges. RFC6888 [RFC6888] describes requirements for CGNs. It
states, that CGNs must comply with Section 11 of RFC4787 [RFC4787],
which requires NAT to support receiving IP fragments (REQ-14). In
real life fulfillment of this requirement creates an additional
burden in terms of memory, especially for high-capacity devices, used
in CGNs. It was found by people deploying IKE, that some ISPs have
begun to drop IP fragments, violating that requirement.
The solution to the problem described in this document is to perform The solution to the problem described in this document is to perform
fragmentation of large messages by IKE itself, replacing them by fragmentation of large messages by IKE itself, replacing them by
series of smaller messages. In this case the resulting IP Datagrams series of smaller messages. In this case the resulting IP Datagrams
will be small enough so that no fragmentation on IP level will take will be small enough so that no fragmentation on IP level will take
place. place.
Avoiding IP fragmentation is beneficial for IKEv2 in general.
Security Considerations Section of [RFC5996] mentions exhausting of
the IP reassembly buffers as one of possible attacks on the protocol.
In the paper [DOSUDPPROT] several aspects of attacks on IKE using IP
fragmentation are discussed, and one of defenses it proposes is to
perform IKE-level fragmentation, similar to the solution, described
in this document.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Protocol details 2. Protocol details
2.1. Overview 2.1. Overview
The idea of the protocol is to split large IKE message into the set The idea of the protocol is to split large IKE message into a set of
of smaller ones, calling IKE Fragment Messages. Fragmentation takes smaller ones, called IKE Fragment Messages. Fragmentation takes
place before the original message is encrypted and authenticated, so place before the original message is encrypted and authenticated, so
that each IKE Fragment Message receives individual protection. On that each IKE Fragment Message receives individual protection. On
the receiving side IKE Fragment Messages are collected, verified, the receiving side IKE Fragment Messages are collected, verified,
decrypted and merged together to get the original message before decrypted and merged together to get the original message before
encryption. For design rationale see Appendix A. encryption. For design rationale see Appendix A.
2.2. Limitations 2.2. Limitations
As IKE Fragment Messages are cryptographically protected, SK_a and As IKE Fragment Messages are cryptographically protected, SK_a and
SK_e must already be calculated. In general, it means that original SK_e must already be calculated. In general, it means that original
skipping to change at page 8, line 28 skipping to change at page 8, line 28
fragmentation. fragmentation.
If sender has some knowledge about PMTU size it MAY use it. If If sender has some knowledge about PMTU size it MAY use it. If
sender is a Responder in the Exchange and it has received fragmented sender is a Responder in the Exchange and it has received fragmented
request, it MAY use maximum size of received IKE Fragment Message IP request, it MAY use maximum size of received IKE Fragment Message IP
Datagrams as threshold when constructing fragmented response. Datagrams as threshold when constructing fragmented response.
Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use Otherwise for messages to be sent over IPv6 it is RECOMMENDED to use
value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For value 1280 bytes as a maximum IP Datagram size ([RFC2460]). For
messages to be sent over IPv4 it is RECOMMENDED to use value 576 messages to be sent over IPv4 it is RECOMMENDED to use value 576
bytes as a maximum IP Datagram size. bytes as a maximum IP Datagram size. Presence of tunnels on the path
may reduce these values.
According to [RFC0791] the minimum IPv4 datagram size that is According to [RFC0791] the minimum IPv4 datagram size that is
guaranteed not to be further fragmented is 68 bytes, but it is guaranteed not to be further fragmented is 68 bytes, but it is
generally impossible to use such small value for solution, described generally impossible to use such small value for solution, described
in this document. Using 576 bytes is a compromise - the value is in this document. Using 576 bytes is a compromise - the value is
large enough for the presented solution and small enough to avoid IP large enough for the presented solution and small enough to avoid IP
fragmentation in most situations. Several other UDP-based protocol fragmentation in most situations. Several other UDP-based protocol
assume the value 576 bytes as a safe low limit for IP datagrams size assume the value 576 bytes as a safe low limit for IP datagrams size
(Syslog, DNS, etc.). Sender MAY use other values if they are (Syslog, DNS, etc.). Sender MAY use other values if they are
appropriate. appropriate.
See Appendix B for correlation between IP Datagram size and Encrypted See Appendix B for correlation between IP Datagram size and Encrypted
Payload content size. Payload content size.
2.5.2. PMTU Discovery 2.5.2. PMTU Discovery
Initiator MAY try to discover path MTU by using several values of Initiator MAY try to discover path MTU by probing several values of
fragmentation threshold, provided that it starts with larger values fragmentation threshold. While doing probes, node MUST start from
and fragments message again with next smaller value if it doesn't larger values and refragment message with next smaller value if it
receive response in a reasonable time after several retransmissions. doesn't receive response in a reasonable time after several
retransmissions. This time is supposed to be relatively short, so
that node could make all desired probes before exchange times out.
When starting new probe (with smaller threshold) node MUST reset its
retransmission timers so, that if it employs exponential back-off,
the timers start over. After reaching the smallest allowed value for
fragmentation threshold implementation MUST continue probing using it
untill either exchange completes ot times out.
PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is
expected, that node will try only few fragmentation thresholds, in
order to minimize possible IKE SA establishment delay. In a corner
case, when host will use only one value, PMTU discovery will
effectively be disabled. In most cases PMTU discovery will not be
needed, as using values, recommended in section Section 2.5.1, should
suffice. It is expected, that PMTU discovery may be useful in
environments where PMTU size are smaller, than those listed in
Section 2.5.1, for example due to the presence of intermediate
tunnels.
PMTU discovery in IKE follows recommendations, given in Section 10.4
of RFC4821 [RFC4821] with some differences, induced by the
specialities of IKE. In particular:
o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of
Path MTU discovery in IKE is not to find the largest size of IP
packet, that will not be fragmented en route, but to find any
reasonal size, probably far from optimal.
o There is no goal to completely disallow IP fragmentation until its
presence leads to inability IKE to communicate (e.g. when IP
fragments are dropped)
o IKE usually sends large messages only in IKE_AUTH exchange, i.e.
once per IKE SA. Most of other messages will have size below
several hundred bytes. Performing full PMTUD for sending exactly
one large message is inefficient.
In case of PMTU discovery Total Fragments field is used to In case of PMTU discovery Total Fragments field is used to
distinguish between different sets of fragments, i.e. the sets that distinguish between different sets of fragments, i.e. the sets that
were obtained by fragmenting original message using different were obtained by fragmenting original message using different
fragmentation thresholds. As sender will start from larger fragments fragmentation thresholds. As sender will start from larger fragments
and then make them smaller, the value in Total Fragments field will and then make them smaller, the value in Total Fragments field will
increase with each new try. When selecting next smaller value of increase with each new try. When selecting next smaller value of
fragmentation threshold, sender MUST ensure that the value in Total fragmentation threshold, sender MUST ensure that the value in Total
Fragments field is really increased. This requirement should not Fragments field is really increased. This requirement should not
become a problem for the sender, as PMTU discovery in IKE is supposed become a problem for the sender, as PMTU discovery in IKE is supposed
skipping to change at page 10, line 30 skipping to change at page 11, line 19
* check that Fragment Number and Total Fragments fields are non- * check that Fragment Number and Total Fragments fields are non-
zero zero
* check that Fragment Number field is less than or equal to Total * check that Fragment Number field is less than or equal to Total
Fragments field Fragments field
* if reassembling has already started, check that Total Fragments * if reassembling has already started, check that Total Fragments
field is equal to or greater than Total Fragments field in field is equal to or greater than Total Fragments field in
fragments, that have already received fragments, that have already received
If either of this tests fails message MUST be silently discarded. If any of this tests fails message MUST be silently discarded.
o Check, that this IKE Fragment Message is new for the receiver and o Check, that this IKE Fragment Message is new for the receiver and
not a replay. If IKE Fragment message with the same Message ID, not a replay. If IKE Fragment message with the same Message ID,
same Fragment Number and same Total Fragments fields was already same Fragment Number and same Total Fragments fields was already
received and successfully processed, this message is considered a received and successfully processed, this message is considered a
replay and MUST be silently discarded. replay and MUST be silently discarded.
o Verify IKE Fragment Message authenticity by checking ICV in o Verify IKE Fragment Message authenticity by checking ICV in
Encrypted Fragment Payload. If ICV check fails message MUST be Encrypted Fragment Payload. If ICV check fails message MUST be
silently discarded. silently discarded.
skipping to change at page 10, line 52 skipping to change at page 11, line 41
o If reassembling isn't finished yet and Total Fragments field in o If reassembling isn't finished yet and Total Fragments field in
received IKE Fragment Message is greater than this field in received IKE Fragment Message is greater than this field in
previously received fragments, receiver MUST discard all received previously received fragments, receiver MUST discard all received
fragments and start reassembling over with just received IKE fragments and start reassembling over with just received IKE
Fragment Message. Fragment Message.
o Store message in the list waiting for the rest of fragments to o Store message in the list waiting for the rest of fragments to
arrive. arrive.
When all IKE Fragment Messages (as indicated in the Total Fragments When all IKE Fragment Messages (as indicated in the Total Fragments
field) are received, content of their Encrypted Fragment Payloads is field) are received, content of their already decrypted Encrypted
decrypted and merged together to form content of original Encrypted Fragment Payloads is merged together to form content of original
Payload, and, therefore, along with IKE Header and unencrypted Encrypted Payload, and, therefore, along with IKE Header and
Payloads (if any), original message. Then it is processed as if it unencrypted Payloads (if any), original message. Then it is
was received, verified and decrypted as regular unfragmented message. processed as if it was received, verified and decrypted as regular
unfragmented message.
If receiver does't get all IKE Fragment Messages needed to reassemble If receiver does't get all IKE Fragment Messages needed to reassemble
original Message for some Exchange within a timeout interval, it acts original Message for some Exchange within a timeout interval, it acts
according with Section 2.1 of [RFC5996], i.e. retransmits the according with Section 2.1 of [RFC5996], i.e. retransmits the
fragmented request Message (in case of Initiator) or deems Exchange fragmented request Message (in case of Initiator) or deems Exchange
to have failed. If Exchange is abandoned, all received so far IKE to have failed. If Exchange is abandoned, all received so far IKE
Fragment Messages for that Exchange MUST be discarded. Fragment Messages for that Exchange MUST be discarded.
2.6.1. Changes in Replay Protection Logic 2.6.1. Changes in Replay Protection Logic
skipping to change at page 15, line 11 skipping to change at page 15, line 11
response Fragment Messages are sent back all together only when all response Fragment Messages are sent back all together only when all
fragments of request are received, the original request Message is fragments of request are received, the original request Message is
reassembled and successfully processed. reassembled and successfully processed.
5. Security Considerations 5. Security Considerations
Most of the security considerations for IKE Fragmentation are the Most of the security considerations for IKE Fragmentation are the
same as those for base IKEv2 protocol described in [RFC5996]. This same as those for base IKEv2 protocol described in [RFC5996]. This
extension introduces Encrypted Fragment Payload to protect content of extension introduces Encrypted Fragment Payload to protect content of
IKE Message Fragment. This allows receiver to individually check IKE Message Fragment. This allows receiver to individually check
authenticity of fragments, thus protecting peers from Denial of authenticity of fragments, thus protecting peers from DoS attack.
Service attack.
Security Considerations Section of [RFC5996] mentions possible attack
on IKE by exhausting of the IP reassembly buffers. The mechanism,
described in this document, allows IKE to avoid IP-fragmentation and
therefore increases its robustness to DoS attacks.
6. IANA Considerations 6. IANA Considerations
This document defines new Payload in the "IKEv2 Payload Types" This document defines new Payload in the "IKEv2 Payload Types"
registry: registry:
<TBA> Encrypted Fragment Payload SKF <TBA> Encrypted Fragment Payload SKF
This document also defines new Notify Message Types in the "Notify This document also defines new Notify Message Types in the "Notify
Messages Types - Status Types" registry: Messages Types - Status Types" registry:
skipping to change at page 18, line 25 skipping to change at page 18, line 25
[RFC6311] Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D. [RFC6311] Singh, R., 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, July 2011. IPsec", RFC 6311, July 2011.
8.2. Informative References 8.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007.
[RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Algorithms with the Encrypted Payload of the Internet Key
Exchange version 2 (IKEv2) Protocol", RFC 5282, Exchange version 2 (IKEv2) Protocol", RFC 5282,
August 2008. August 2008.
[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,
January 2010. January 2010.
[RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A [RFC6290] Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
Quick Crash Detection Method for the Internet Key Exchange Quick Crash Detection Method for the Internet Key Exchange
Protocol (IKE)", RFC 6290, June 2011. Protocol (IKE)", RFC 6290, June 2011.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", BCP 127, RFC 6888, April 2013.
[DOSUDPPROT]
Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
protection for UDP-based protocols", ACM Conference on
Computer and Communications Security, October 2003.
Appendix A. Design rationale Appendix A. Design rationale
The simplest approach to the IKE fragmentation would have been to The simplest approach to the IKE fragmentation would have been to
fragment message that is fully formed and ready to be sent. But if fragment message that is fully formed and ready to be sent. But if
message got fragmented after being encrypted and authenticated, this message got fragmented after being encrypted and authenticated, this
could open a possibility for a simple Denial of Service attack. The could open a possibility for a simple Denial of Service attack. The
attacker could infrequently emit forged but looking valid fragments attacker could infrequently emit forged but looking valid fragments
into the network, and some of these fragments would be fetched by into the network, and some of these fragments would be fetched by
receiver into the reassempling queue. Receiver could not distinguish receiver into the reassempling queue. Receiver could not distinguish
forged fragments from valid ones and could only determine that some forged fragments from valid ones and could only determine that some
 End of changes. 18 change blocks. 
30 lines changed or deleted 111 lines changed or added

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