< draft-ietf-ipsecme-ikev2-fragmentation-08.txt   draft-ietf-ipsecme-ikev2-fragmentation-09.txt >
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track May 23, 2014 Intended status: Standards Track June 6, 2014
Expires: November 24, 2014 Expires: December 8, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-08 draft-ietf-ipsecme-ikev2-fragmentation-09
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 do not allow IP fragments to pass through. devices that do not 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 November 24, 2014. This Internet-Draft will expire on December 8, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 3, line 13 skipping to change at page 3, line 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. Problem description 1.1. Problem description
The Internet Key Exchange Protocol version 2 (IKEv2), specified in The Internet Key Exchange Protocol version 2 (IKEv2), specified in
[IKEv2], uses UDP as a transport for its messages. Most IKEv2 [IKEv2], uses UDP as a transport for its messages. Most IKEv2
messages are relatively small, usually below several hundred bytes. messages are relatively small, usually below several hundred bytes.
Noticeable exception is IKE_AUTH Exchange, which requires fairly Noticeable exception is IKE_AUTH Exchange, which requires fairly
large messages, up to several kbytes, especially when certificates large messages, up to several kBytes, especially when certificates
are transferred. When IKE message size exceeds path MTU, it gets are transferred. When IKE message size exceeds path MTU, it gets
fragmented by IP level. The problem is that some network devices, fragmented by IP level. The problem is that some network devices,
specifically some NAT boxes, do not allow IP fragments to pass specifically some NAT boxes, do not allow IP fragments to pass
through. This apparently blocks IKE communication and, therefore, through. This apparently blocks IKE communication and, therefore,
prevents peers from establishing IPsec SA. Section 2 of [IKEv2] prevents peers from establishing IPsec SA. Section 2 of [IKEv2]
discusses the impact of IP fragmentation on IKEv2 and acknowledges discusses the impact of IP fragmentation on IKEv2 and acknowledges
this problem. this problem.
Widespread deployment of Carrier-Grade NATs (CGN) introduces new Widespread deployment of Carrier-Grade NATs (CGN) introduces new
challenges. [RFC6888] describes requirements for CGNs. It states, challenges. [RFC6888] describes requirements for CGNs. It states,
skipping to change at page 4, line 6 skipping to change at page 4, line 6
1.2. Proposed solution 1.2. Proposed solution
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 IKEv2 itself, replacing them by fragmentation of large messages by IKEv2 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.
The primary goal of this solution is to allow IKEv2 to operate in The primary goal of this solution is to allow IKEv2 to operate in
environments, that may block IP fragments. This goal does not assume environments, that might block IP fragments. This goal does not
that IP fragmentation should be avoided completely, but only in those assume that IP fragmentation should be avoided completely, but only
cases when it interferes with IKE operations. However this solution in those cases when it interferes with IKE operations. However this
could be used to avoid IP fragmentation in all situations where solution could be used to avoid IP fragmentation in all situations
fragmentation within IKE is applicable, as it is recommended in where fragmentation within IKE is applicable, as it is recommended in
Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be Section 3.2 of [RFC5405]. Avoiding IP fragmentation would be
beneficial for IKEv2 in general. Security Considerations Section of beneficial for IKEv2 in general. Security Considerations Section of
[IKEv2] mentions exhausting of the IP reassembly buffers as one of [IKEv2] mentions exhausting of the IP reassembly buffers as one of
the possible attacks on the protocol. In the paper [DOSUDPPROT] the possible attacks on the protocol. In the paper [DOSUDPPROT]
several aspects of attacks on IKE using IP fragmentation are several aspects of attacks on IKE using IP fragmentation are
discussed, and one of the defenses it proposes is to perform discussed, and one of the defenses it proposes is to perform
fragmentation within IKE similarly to the solution described in this fragmentation within IKE similarly to the solution described in this
document. document.
1.3. Conventions Used in This Document 1.3. Conventions Used in This Document
skipping to change at page 5, line 21 skipping to change at page 5, line 21
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. See Appendix A for design rationale. encryption. See Appendix A for design rationale.
2.2. Limitations 2.2. Limitations
Since IKE Fragment Messages are cryptographically protected, SK_a and Since 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
message can be fragmented if and only if it contains Encrypted message can be fragmented if and only if it contains an Encrypted
Payload. Payload.
This implies that messages of the IKE_SA_INIT Exchange cannot be This implies that messages of the IKE_SA_INIT Exchange cannot be
fragmented. In most cases this is not a problem because IKE_SA_INIT fragmented. In most cases this is not a problem because IKE_SA_INIT
messages are usually small enough to avoid IP fragmentation. But in messages are usually small enough to avoid IP fragmentation. But in
some cases (advertising a badly structured long list of algorithms, some cases (advertising a badly structured long list of algorithms,
using large MODP Groups, etc.) these messages may become fairly large using large MODP Groups, etc.) these messages may become fairly large
and get fragmented by IP level. In this case the described solution and get fragmented by IP level. In this case the described solution
will not help. will not help.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
Another limitation is that the minimal size of IP Datagram bearing Another limitation is that the minimal size of IP Datagram bearing
IKE Fragment Message is about 100 bytes depending on the algorithms IKE Fragment Message is about 100 bytes depending on the algorithms
employed. According to [RFC0791] the minimum IPv4 Datagram size that employed. According to [RFC0791] the minimum IPv4 Datagram size that
is guaranteed not to be further fragmented is 68 bytes. So, even the is guaranteed not to be further fragmented is 68 bytes. So, even the
smallest IKE Fragment Messages could be fragmented by IP level in smallest IKE Fragment Messages could be fragmented by IP level in
some circumstances. But such extremely small PMTU sizes are very some circumstances. But such extremely small PMTU sizes are very
rare in real life. rare in real life.
2.3. Negotiation 2.3. Negotiation
Initiator indicates its support for the IKE Fragmentation and The Initiator indicates its support for the IKE Fragmentation and
willingness to use it by including Notification Payload of type willingness to use it by including Notification Payload of type
IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If
Responder also supports this extension and is willing to use it, it Responder also supports this extension and is willing to use it, it
includes this notification in response message. includes this notification in response message.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
[N(IKEV2_FRAGMENTATION_SUPPORTED)] --> [N(IKEV2_FRAGMENTATION_SUPPORTED)] -->
skipping to change at page 6, line 35 skipping to change at page 6, line 35
o SPI Size (1 octet) MUST be 0, meaning no SPI is present. o SPI Size (1 octet) MUST be 0, meaning no SPI is present.
o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned
for IKEV2_FRAGMENTATION_SUPPORTED notification. for IKEV2_FRAGMENTATION_SUPPORTED notification.
This Notification contains no data. This Notification contains no data.
2.4. Using IKE Fragmentation 2.4. Using IKE Fragmentation
The IKE Fragmentation MUST NOT be used unless both peers have The IKE Fragmentation MUST NOT be used unless both peers have
indicated their support for it. After that it is up to the the indicated their support for it. After that it is up to the Initiator
Initiator of each exchange to decide whether to use it or not. The of each exchange to decide whether or not to use it. The Responder
Responder usually replies in the same form as the request message, usually replies in the same form as the request message, but other
but other considerations might override this. considerations might override this.
The Initiator may employ various policies regarding the use of IKE The Initiator can employ various policies regarding the use of IKE
Fragmentation. It may first try to send an unfragmented message and Fragmentation. It might first try to send an unfragmented message
resend it as fragmented only if no complete response is received even and resend it as fragmented only if no complete response is received
after several retransmissions. Alternatively, it may choose always even after several retransmissions. Alternatively, it might choose
to send fragmented messages (but see Section 3), or it may fragment always to send fragmented messages (but see Section 3), or it might
only large messages and messages that are expected to result in large fragment only large messages and messages that are expected to result
responses. in large responses.
The following general guidelines apply: The following general guidelines apply:
o If either peer has information that a part of the transaction is o If either peer has information that a part of the transaction is
likely to be fragmented at the IP layer, causing interference with likely to be fragmented at the IP layer, causing interference with
the IKE exchange, that peer SHOULD use IKE Fragmentation. This the IKE exchange, that peer SHOULD use IKE Fragmentation. This
information may be passed from a lower layer, provided by information might be passed from a lower layer, provided by
configuration, or derived through heuristics. Examples of configuration, or derived through heuristics. Examples of
heuristics are the lack of a complete response after several heuristics are the lack of a complete response after several
retransmissions for the Initiator, and receiving repeated retransmissions for the Initiator, and receiving repeated
retransmissions of the request for the Responder. retransmissions of the request for the Responder.
o If either peer knows that IKE Fragmentation has been used in a o If either peer knows that IKE Fragmentation has been used in a
previous exchange in the context of the current IKE SA, that peer previous exchange in the context of the current IKE SA, that peer
SHOULD continue the use of IKE Fragmentation for the messages that SHOULD continue the use of IKE Fragmentation for the messages that
are larger than the current fragmentation threshold (see are larger than the current fragmentation threshold (see
Section 2.5.1). Section 2.5.1).
skipping to change at page 7, line 31 skipping to change at page 7, line 31
o If none of the above apply, the Responder SHOULD respond in the o If none of the above apply, the Responder SHOULD respond in the
same form (fragmented or not) as the request message it is same form (fragmented or not) as the request message it is
responding to. Note that the other guidelines might override this responding to. Note that the other guidelines might override this
because of information or heuristics available to the Responder. because of information or heuristics available to the Responder.
In most cases IKE Fragmentation will be used in the IKE_AUTH In most cases IKE Fragmentation will be used in the IKE_AUTH
Exchange, especially if certificates are employed. Exchange, especially if certificates are employed.
2.5. Fragmenting Message 2.5. Fragmenting Message
Message to be fragmented MUST contain Encrypted Payload. For the Only messages that contain an Encrypted Payload are subject for IKE
purpose of IKE Fragment Messages construction original (unencrypted) Fragmentation. For the purpose of IKE Fragment Messages construction
content of Encrypted Payload is split into chunks. The content is original (unencrypted) content of the Encrypted Payload is split into
treated as a binary blob and is split regardless of inner Payloads chunks. The content is treated as a binary blob and is split
boundaries. Each of resulting chunks is treated as an original regardless of inner Payloads boundaries. Each of resulting chunks is
content of Encrypted Fragment Payload and is then encrypted and treated as an original content of the Encrypted Fragment Payload and
authenticated. Thus, the Encrypted Fragment Payload contains a chunk is then encrypted and authenticated. Thus, the Encrypted Fragment
of the original content of Encrypted Payload in encrypted form. The Payload contains a chunk of the original content of the Encrypted
cryptographic processing of Encrypted Fragment Payload is identical Payload in encrypted form. The cryptographic processing of the
to Section 3.14 of [IKEv2], as well as documents updating it for Encrypted Fragment Payload is identical to Section 3.14 of [IKEv2],
particular algorithms or modes, such as [RFC5282]. as well as documents updating it for particular algorithms or modes,
such as [RFC5282].
The Encrypted Fragment Payload, similarly to the Encrypted Payload, The Encrypted Fragment Payload, similarly to the Encrypted Payload,
if present in a message, MUST be the last payload in the message. if present in a message, MUST be the last payload in the message.
The Encrypted Fragment Payload is denoted SKF{...} and its payload The Encrypted Fragment Payload is denoted SKF{...} and its payload
type is XXX (TBA by IANA). This payload is also called the type is XXX (TBA by IANA). This payload is also called the
"Encrypted and Authenticated Fragment" payload. "Encrypted and Authenticated Fragment" payload.
1 2 3 1 2 3
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 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
skipping to change at page 9, line 20 skipping to change at page 9, line 20
HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...}, HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
... ...
HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...} HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}
IKE Fragment Messages IKE Fragment Messages
2.5.1. Selecting Fragment Size 2.5.1. Selecting Fragment Size
When splitting content of Encrypted Payload into chunks sender SHOULD When splitting content of Encrypted Payload into chunks sender SHOULD
choose their size so, that resulting IP Datagrams be smaller than choose their size so, that resulting IP Datagrams be smaller than
some fragmentation threshold. Implementation may calculate some fragmentation threshold. Implementations may calculate
fragmentation threshold using various sources of information. fragmentation threshold using various sources of information.
If sender has information about PMTU size it SHOULD use it. The If the Sender has information about PMTU size it SHOULD use it. The
Responder in the exchange may use maximum size of received IKE Responder in the exchange may use maximum size of received IKE
Fragment Message IP Datagrams as threshold when constructing Fragment Message IP Datagrams as threshold when constructing
fragmented response. Successful completion of previous exchanges fragmented response. Successful completion of previous exchanges
(including those exchanges, that cannot employ IKE Fragmentation, (including those exchanges, that cannot employ IKE Fragmentation,
e.g. IKE_SA_INIT) may be an indication, that fragmentation threshold e.g. IKE_SA_INIT) may be an indication, that fragmentation threshold
can be set to the size of the largest of already sent messages. can be set to the size of the largest of already sent messages.
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. Presence of tunnels on the path bytes as a maximum IP Datagram size. Presence of tunnels on the path
may reduce these values. Implementation may use other values if they may reduce these values. Implementations may use other values if
are appropriate in current environment. they are appropriate in current environment.
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.). (Syslog, DNS, etc.).
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
The amount of traffic that IKE endpoint produces during lifetime of The amount of traffic that IKE endpoint produces during lifetime of
IKE SA is fairly modest - usually it is below one hundred kBytes IKE SA is fairly modest - usually it is below one hundred kBytes
within a period of several hours. Most of this traffic consists of within a period of several hours. Most of this traffic consists of
relatively short messages - usually below several hundred bytes. In relatively short messages - usually below several hundred bytes. In
most cases the only time when IKE endpoints exchange messages of most cases the only time when IKE endpoints exchange messages of
several kBytes in size is IKE SA establishment and often each several kBytes in size is IKE SA establishment and often each
endpoint sends exactly one such message. endpoint sends exactly one such message.
For the reasons atriculated above implementing PMTU discovery in IKE For the reasons articulated above implementing PMTU discovery in IKE
is OPTIONAL. It is believed that using the values recommended in is OPTIONAL. It is believed that using the values recommended in
Section 2.5.1 as fragmentation threshold will be sufficient in most Section 2.5.1 as fragmentation threshold will be sufficient in most
cases. Using these values could lead to suboptimal fragmentation, cases. Using these values could lead to suboptimal fragmentation,
but it is acceptable given the amount of traffic IKE produces. but it is acceptable given the amount of traffic IKE produces.
Implementation may support PMTU discovery if there are good reasons Implementations may support PMTU discovery if there are good reasons
to do it (for example if it is intended to be used in environments to do it (for example if it is intended to be used in environments
where MTU size is possible to be less that values listed in where MTU size is possible to be less that values listed in
Section 2.5.1). Section 2.5.1).
PMTU discovery in IKE follows recommendations given in Section 10.4 PMTU discovery in IKE follows recommendations given in Section 10.4
of [RFC4821] with the difference, induced by the specialties of IKE of [RFC4821] with the difference, induced by the specialties of IKE
listed above. The difference is that the PMTU search is performed listed above. The difference is that the PMTU search is performed
downward, while in [RFC4821] it is performed upward. The reason for downward, while in [RFC4821] it is performed upward. The reason for
this change is that IKE usually sends large messages only when IKE SA this change is that IKE usually sends large messages only when IKE SA
is being established and in many cases there is only one such is being established and in many cases there is only one such
message. If the probing were performed upward this message would be message. If the probing were performed upward this message would be
fragmented using the smallest allowable threshold, and usually all fragmented using the smallest allowable threshold, and usually all
other messages are small enough to avoid IP fragmentation, so there other messages are small enough to avoid IP fragmentation, so there
would be little value to continue probing. would be little value to continue probing.
It is the Initiator of the exchange, who performs PMTU discovery. It It is the Initiator of the exchange, who performs PMTU discovery. It
is done by probing several values of fragmentation threshold. is done by probing several values of fragmentation threshold.
Implementation MUST be prepared to probe in every exchange that Implementations MUST be prepared to probe in every exchange that
utilizes IKE Fragmentation to deal with possible changes of path MTU utilizes IKE Fragmentation to deal with possible changes of path MTU
over time. While doing probes, it MUST start from larger values and over time. While doing probes, it MUST start from larger values and
refragment original message using next smaller value of threshold if refragment original message using next smaller value of threshold if
it did not receive response in a reasonable time after several it did not receive response in a reasonable time after several
retransmissions. The exact number of retransmissions and length of retransmissions. The exact number of retransmissions and length of
timeouts are not covered in this specification because they do not timeouts are not covered in this specification because they do not
affect interoperability. However, the timeout interval is supposed affect interoperability. However, the timeout interval is supposed
to be relatively short, so that unsuccessful probes would not delay to be relatively short, so that unsuccessful probes would not delay
IKE operations too much. Performimg few retries within several IKE operations too much. Performing few retries within several
seconds for each probe seems appropriate, but different environments seconds for each probe seems appropriate, but different environments
may require different rules. When starting new probe node MUST reset may require different rules. When starting new probe node MUST reset
its retransmission timers so, that if it employs exponential back- its retransmission timers so, that if it employs exponential back-
off, the timers will start over. After reaching the smallest allowed off, the timers will start over. After reaching the smallest allowed
value for fragmentation threshold implementation MUST continue value for the fragmentation threshold an implementation MUST continue
retransmitting until either exchange completes or times out using retransmitting until either exchange completes or times out using
timeout interval from Section 2.4 of [IKEv2]. timeout interval from Section 2.4 of [IKEv2].
PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is
expected, that node will try only few fragmentation thresholds, in expected, that node will try only few fragmentation thresholds, in
order to minimize delays caused by unsuccessful probes. If no order to minimize delays caused by unsuccessful probes. If no
information about path MTU is known yet, endpoint may start probing information about path MTU is known yet, endpoint may start probing
from link MTU size. In the following exchanges node should start from link MTU size. In the following exchanges node should start
from the current value of fragmentation threshold. from the current value of fragmentation threshold.
If implementation is capable to receive ICMP error messages it may If an implementation is capable to receive ICMP error messages it can
additionally utilize classic PMTU discovery methods, described in additionally utilize classic PMTU discovery methods, described in
[RFC1191] and [RFC1981]. In particular, if the Initiator receives [RFC1191] and [RFC1981]. In particular, if the Initiator receives
Packet Too Big error in response to the probe, and it contains Packet Too Big error in response to the probe, and it contains
smaller value, than current fragmentation threshold, then the smaller value, than current fragmentation threshold, then the
Initiator SHOULD stop retransmitting the probe and SHOULD select new Initiator SHOULD stop retransmitting the probe and SHOULD select new
value for fragmentation threshold that is less than or equal to the value for fragmentation threshold that is less than or equal to the
value from the ICMP message and meets the requirements listed below. value from the ICMP message and meets the requirements listed below.
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
skipping to change at page 12, line 27 skipping to change at page 12, line 27
should not exceed fragmentation threshold, including the first one, should not exceed fragmentation threshold, including the first one,
that contains unprotected Payloads. This will reduce the size of that contains unprotected Payloads. This will reduce the size of
Encrypted Fragment Payload content in the first IKE Fragment Message Encrypted Fragment Payload content in the first IKE Fragment Message
to accommodate all unprotected Payloads. In extreme case Encrypted to accommodate all unprotected Payloads. In extreme case Encrypted
Fragment Payload will contain no data, but it still must be present Fragment Payload will contain no data, but it still must be present
in the message, because only its presence allows receiver to in the message, because only its presence allows receiver to
determine that sender have used IKE Fragmentation. determine that sender have used IKE Fragmentation.
2.6. Receiving IKE Fragment Message 2.6. Receiving IKE Fragment Message
Receiver identifies IKE Fragment Message by the presence of Encrypted The Receiver identifies the IKE Fragment Message by the presence of
Fragment Payload in it. In most cases it will be the first and the an Encrypted Fragment Payload in it. In most cases it will be the
only payload in the message, however this may not be true for some first and the only payload in the message, however this may not be
hypothetical IKE exchanges (see Section 2.5.3) true for some hypothetical IKE exchanges (see Section 2.5.3)
Upon receiving IKE Fragment Message the following actions are Upon receiving the IKE Fragment Message the following actions are
performed: performed:
o Check message validity - in particular, check whether values of o Check message validity - in particular, check whether the values
Fragment Number and Total Fragments in Encrypted Fragment Payload in the Fragment Number and the Total Fragments fields in the
are valid. The following tests need to be performed. Encrypted Fragment Payload are valid. The following tests need to
be performed.
* check that Fragment Number and Total Fragments fields are non- * check that the Fragment Number and the Total Fragments fields
zero contain non-zero values
* check that Fragment Number field is less than or equal to Total * check that the value in the Fragment Number field is less than
Fragments field or equal to the value in the Total Fragments field
* if reassembling has already started, check that Total Fragments * if reassembling has already started, check that the value in
field is equal to or greater than Total Fragments field in the Total Fragments field is equal to or greater than Total
fragments that have already been stored in the reassembling Fragments field in the fragments that have already been stored
queue in the reassembling queue
If any of this tests fails message MUST be silently discarded. If any of this tests fails the 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 is already same Fragment Number and same Total Fragments fields is already
present in the reassembling queue, this message is considered a present in the reassembling queue, 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 13, line 25 skipping to change at page 13, line 25
o If reassembling is not finished yet and Total Fragments field in o If reassembling is not finished yet and Total Fragments field in
received fragment is greater than this field in those fragments, received fragment is greater than this field in those fragments,
that are in the reassembling queue, receiver MUST discard all that are in the reassembling queue, receiver MUST discard all
received fragments and start reassembling over with just received received fragments and start reassembling over with just received
IKE Fragment Message. IKE Fragment Message.
o Store message in the reassembling queue waiting for the rest of o Store message in the reassembling queue waiting for the rest of
fragments to arrive. fragments to 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, decrypted content of all Encrypted Fragment field) are received, the decrypted content of all Encrypted Fragment
Payloads is merged together to form content of original Encrypted Payloads is merged together to form content of original Encrypted
Payload, and, therefore, along with IKE Header and unprotected Payload, and, therefore, along with IKE Header and unprotected
Payloads (if any), original message. Then it is processed as if it Payloads (if any), original message. Then it is processed as if it
was received, verified and decrypted as regular IKE message. was received, verified and decrypted as regular IKE message.
If receiver does not get all IKE fragments needed to reassemble If receiver does not get all IKE fragments needed to reassemble the
original Message within a timeout interval, it MUST discard all original Message within a timeout interval, it MUST discard all IKE
received so far IKE Fragment Messages for the exchange. Next actions Fragment Messages received so far for the exchange. The next actions
depend on the role of receiver in the exchange. depend on the role of receiver in the exchange.
o The Initiator acts as described in Section 2.1 of [IKEv2]. It o The Initiator acts as described in Section 2.1 of [IKEv2]. It
either retransmits the fragmented request Message or deems IKE SA either retransmits the fragmented request Message or deems IKE SA
to have failed and deletes it. The number of retransmits and to have failed and deletes it. The number of retransmits and
length of timeouts for the Initiator are not covered in this length of timeouts for the Initiator are not covered in this
specification since they are assumed to be the same as in regular specification since they are assumed to be the same as in regular
IKEv2 exchange and are discussed in Section 2.4 of [IKEv2]. IKEv2 exchange and are discussed in Section 2.4 of [IKEv2].
o The Responder in this case acts as if no request message was o The Responder in this case acts as if no request message was
received. The reassembling timeout for Responder is RECOMMENDED received. It would delete any memory of the incomplete request
to be equal to the time interval that implementation waits before message, and not treat it as an IKE SA failure. The reassembling
completely giving up when acting as Initiator of exchange. timeout for the Responder is RECOMMENDED to be equal to the time
Section 2.4 of [IKEv2] gives recommendations for selecting this interval that the implementation waits before completely giving up
interval. Implementation MAY use shorter timeout to conserve when acting as Initiator of exchange. Section 2.4 of [IKEv2]
memory. gives recommendations for selecting this interval.
Implementations can use a shorter timeout to conserve memory.
2.6.1. Replay Detection and Retransmissions 2.6.1. Replay Detection and Retransmissions
According to [IKEv2] implementation must reject message with the same According to [IKEv2] implementations must reject message with the
Message ID as it has seen before (taking into consideration Response same Message ID as it has seen before (taking into consideration
bit). This logic has already been updated by [RFC6311], which Response bit). This logic has already been updated by [RFC6311],
deliberately allows any number of messages with zero Message ID. which deliberately allows any number of messages with zero Message
This document also updates this logic for the situations, when IKE ID. This document also updates this logic for the situations, when
Fragmentation is in use. IKE Fragmentation is in use.
If incomimg message contains Encrypted Fragment Payload, the values If incoming message contains Encrypted Fragment Payload, the values
of Fragment Number and Total Fragments fields MUST be used along with of Fragment Number and Total Fragments fields MUST be used along with
Message ID to detect retransmissions and replays. Message ID to detect retransmissions and replays.
If Responder receives retransmitted fragment of request when it has If Responder receives retransmitted fragment of request when it has
already processed that request and has sent back a response, that already processed that request and has sent back a response, that
event MUST only trigger retransmission of the response message event MUST only trigger retransmission of the response message
(fragmented or not) if Fragment Number field in received fragment is (fragmented or not) if Fragment Number field in received fragment is
set to 1 and MUST be ignored otherwise. set to 1 and MUST be ignored otherwise.
3. Interaction with other IKE extensions 3. Interaction with other IKE extensions
skipping to change at page 17, line 31 skipping to change at page 17, line 31
fragments. These fragments will pass the ICV check and will be fragments. These fragments will pass the ICV check and will be
stored in reassembly buffers, but since the set is incomplete, the stored in reassembly buffers, but since the set is incomplete, the
reassembling will never succeed and eventually will time out. If the reassembling will never succeed and eventually will time out. If the
set is large, this attack could potentially exhaust the receiver's set is large, this attack could potentially exhaust the receiver's
memory resources. memory resources.
To mitigate the impact of this attack, it is RECOMMENDED that To mitigate the impact of this attack, it is RECOMMENDED that
receiver limits the number of fragments it stores in reassembling receiver limits the number of fragments it stores in reassembling
queue so that the sum of the sizes of Encrypted Fragment Payload queue so that the sum of the sizes of Encrypted Fragment Payload
contents (after decryption) for fragments that are already placed contents (after decryption) for fragments that are already placed
into the reassembling queue be less than some value that is into the reassembling queue is less than some value that is
reasonable for the implementation. If the peer sends so many reasonable for the implementation. If the peer sends so many
fragments, that the above condition is not met, the receiver can fragments that the above condition is not met, the receiver can
consider this situation to be either attack or as broken sender consider this situation to be either attack or as broken sender
implementation. In either case, the receiver SHOULD drop the implementation. In either case, the receiver SHOULD drop the
connection and discard all the received fragments. connection and discard all the received fragments.
This value can be predefined, can be a configurable option, or can be This value can be predefined, can be a configurable option, or can be
calculated dynamically depending on receiver's memory load. In any calculated dynamically depending on the receiver's memory load. Some
case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP care should be taken when selecting this value because, if it is too
datagram) because any IKE message before fragmentation must be small, it might prevent legitimate peer to establish IKE SA if the
shorter than that. size of messages it sends exceeds this value. It is NOT RECOMMENDED
for this value to exceed 64 Kbytes because any IKE message before
fragmentation would likely be shorter than that.
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 and Authenticated Fragment SKF <TBA> Encrypted and Authenticated Fragment SKF
This document also defines new Notify Message Types in the "Notify This document also defines new Notify Message Types in the "Notify
Message Types - Status Types" registry: Message Types - Status Types" registry:
 End of changes. 37 change blocks. 
87 lines changed or deleted 92 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/