draft-ietf-ipsecme-ikev2-fragmentation-03.txt   draft-ietf-ipsecme-ikev2-fragmentation-04.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track October 4, 2013 Intended status: Standards Track October 18, 2013
Expires: April 7, 2014 Expires: April 21, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-03 draft-ietf-ipsecme-ikev2-fragmentation-04
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 7, 2014. This Internet-Draft will expire on April 21, 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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . 7 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 8
2.5.2. Fragmenting Messages containing unencrypted 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 8
Payloads . . . . . . . . . . . . . . . . . . . . . . . 8 2.5.3. Fragmenting Messages containing unencrypted
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9 Payloads . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 10
3. Interaction with other IKE extensions . . . . . . . . . . . . 12 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 11
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 13 3. Interaction with other IKE extensions . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 19
Appendix B. Correlation between IP Datagram size and Appendix B. Correlation between IP Datagram size and
Encrypted Payload content size . . . . . . . . . . . 19 Encrypted Payload content size . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
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. When IKE
message size exceeds path MTU, it gets fragmented by IP level. The message size exceeds path MTU, it gets fragmented by IP level. The
problem is that some network devices, specifically some NAT boxes, problem is that some network devices, specifically some NAT boxes,
don't allow IP fragments to pass through. This apparently blocks IKE don't allow IP fragments to pass through. This apparently blocks IKE
communication and, therefore, prevents peers from establishing IPsec communication and, therefore, prevents peers from establishing IPsec
SA. SA.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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 IKE_FRAGMENTATION_SUPPORTED by IANA. for IKE_FRAGMENTATION_SUPPORTED by IANA.
This Notification contains no data. This Notification contains no data.
2.4. Using IKE Fragmentation 2.4. Using IKE Fragmentation
After IKE Fragmentation is negotiated, it is up to Initiator of each IKE Fragmentation MUST NOT be used unless both peers indicated their
Exchange, whether to use it or not. In most cases IKE Fragmentation support for it. After IKE Fragmentation is negotiated, it is up to
will be used in IKE_AUTH Exchange, especially if certificates are Initiator of each Exchange, whether to use it or not. In most cases
employed. Initiator may first try to send unfragmented message and IKE Fragmentation will be used in IKE_AUTH Exchange, especially if
resend it fragmented only if it didn't receive response after several certificates are employed. Initiator may first try to send
retransmissions, or it may always send messages fragmented (but see unfragmented message and resend it fragmented only if it didn't
Section 3), or it may fragment only large messages and messages receive response after several retransmissions, or it may always send
causing large responses. messages fragmented (but see Section 3), or it may fragment only
large messages and messages causing large responses.
In general the following guidelines are applicable: In general the following guidelines are applicable for initiator:
o Initiator MAY fragment outgoing message if it suspects that either o Initiator MAY fragment outgoing message if it has some knowledge
request or response message may be fragmented by IP level. (possibly from lower layer or from configuration) or suspicions
that either request or response message will be fragmented by IP
level.
o Initiator SHOULD fragment outgoing message if it suspects that o Initiator SHOULD fragment outgoing message if it has some
either request or response message may be fragmented by IP level knowledge (possibly from lower layer or from configuration) or
and IKE Fragmentation was already used in one of previous suspicions that either request or response message will be
Exchanges in the context of the current IKE SA. fragmented by IP level and IKE Fragmentation was already used in
one of previous Exchanges in the context of the current IKE SA.
o Initiator SHOULD NOT fragment outgoing message if both request and o Initiator SHOULD NOT fragment outgoing message if both request and
response messages of the Exchange are small enough not to cause response messages of the Exchange are small enough not to cause
fragmentation on IP level (for example, there is no point in fragmentation on IP level (for example, there is no point in
fragmenting Liveness Check messages). fragmenting Liveness Check messages).
Responder MUST send response message in the same form (fragmented or In general the following guidelines are applicable for responder:
not) as corresponded request message. If it received unfragmented
request message, responded with unfragmented response message and o Responder SHOULD send response message in the same form
then received fragmented retransmission of the same request, it MUST (fragmented or not) as corresponded request message. If it
resend its response back to Initiator fragmented. received unfragmented request message, responded with unfragmented
response message and then receives fragmented retransmission of
the same request, it SHOULD resend its response back to Initiator
fragmented.
o Responder MAY respond to unfragmented message with fragmented
response if it has some knowledge (possibly from lower layer or
from configuration) or suspicions that response message will be
fragmented by IP level.
o Responder MAY respond to fragmented message with unfragmented
response if the size of the response message is less than the
smallest fragmentation threshold, supported by Responder (for
example, there is no point in fragmenting Liveness Check
messages).
2.5. Fragmenting Message 2.5. Fragmenting Message
Message to be fragmented MUST contain Encrypted Payload. For the Message to be fragmented MUST contain Encrypted Payload. For the
purpose of IKE Fragment Messages construction original (unencrypted) purpose of IKE Fragment Messages construction original (unencrypted)
content of Encrypted Payload is split into chunks. The content is content of Encrypted Payload is split into chunks. The content is
treated as a binary blob and is split regardless of inner Payloads treated as a binary blob and is split regardless of inner Payloads
boundaries. Each of resulting chunks is treated as an original boundaries. Each of resulting chunks is treated as an original
content of Encrypted Fragment Payload and is then encrypted and content of Encrypted Fragment Payload and is then encrypted and
authenticated. Thus, the Encrypted Fragment Payload contains a chunk authenticated. Thus, the Encrypted Fragment Payload contains a chunk
skipping to change at page 7, line 15 skipping to change at page 7, line 34
o Next Payload (1 octet) - in the very first fragment MUST be set to o Next Payload (1 octet) - in the very first fragment MUST be set to
Payload Type of the first inner Payload (similarly to the Payload Type of the first inner Payload (similarly to the
Encrypted Payload). In the rest fragments MUST be set to zero. Encrypted Payload). In the rest fragments MUST be set to zero.
o Fragment Number (2 octets) - current fragment number starting from o Fragment Number (2 octets) - current fragment number starting from
1. This field MUST be less than or equal to the next field, Total 1. This field MUST be less than or equal to the next field, Total
Fragments. This field MUST NOT be zero. Fragments. This field MUST NOT be zero.
o Total Fragments (2 octets) - number of fragments original message o Total Fragments (2 octets) - number of fragments original message
was divided into. This field MUST NOT be zero. was divided into. With PMTU discovery this field plays additional
role. See Section 2.5.2 for details. This field MUST NOT be
zero.
The other fields are identical to those specified in Section 3.14 of The other fields are identical to those specified in Section 3.14 of
[RFC5996]. [RFC5996].
When prepending IKE Header, Length field MUST be adjusted to reflect When prepending IKE Header, Length field MUST be adjusted to reflect
the length of constructed message and Next Payload field MUST reflect the length of constructed message and Next Payload field MUST reflect
payload type of the first Payload in the constructed message (that in payload type of the first Payload in the constructed message (that in
most cases will be Encrypted Fragment Payload). All newly most cases will be Encrypted Fragment Payload). All newly
constructed messages MUST retain the same Message ID as original constructed messages MUST retain the same Message ID as original
message. After prepending IKE Header and possibly any of Payloads message. After prepending IKE Header and possibly any of Payloads
that precedes Encrypted Payload in original message (see that precedes Encrypted Payload in original message (see
Section 2.5.2), the resulting messages are sent to the peer. Section 2.5.3), the resulting messages are sent to the peer.
Below is an example of fragmenting a message. Below is an example of fragmenting a message.
HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN} HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}
Original Message Original Message
HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...}, HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
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
skipping to change at page 8, line 22 skipping to change at page 8, line 40
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
Payload content size.
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 using several values of
fragmentation threshold, provided that it starts with larger values fragmentation threshold, provided that it starts with larger values
and fragments message again with next smaller value if it doesn't and fragments message again with next smaller value if it doesn't
receive response in a reasonable time after several retransmissions. receive response in a reasonable time after several retransmissions.
In this case using next smaller value MUST result in increasing Total
Fragments field.
See Appendix B for correlation between IP Datagram size and Encrypted In case of PMTU discovery Total Fragments field is used to
Payload content size. distinguish between different sets of fragments, i.e. the sets that
were obtained by fragmenting original message using different
fragmentation thresholds. As sender will start from larger fragments
and then make them smaller, the value in Total Fragments field will
increase with each new try. When selecting next smaller value of
fragmentation threshold, sender MUST ensure that the value in Total
Fragments field is really increased. This requirement should not
become a problem for the sender, as PMTU discovery in IKE is supposed
to be coarse-grained, so difference between previous and next
fragmentation thresholds will be significant anyway. The necessity
to distinguish between the sets is vital for receiver as receiving
any valid fragment from newer set will mean that it have to start
reassembling over and not to mix fragments from different sets.
2.5.2. Fragmenting Messages containing unencrypted Payloads 2.5.3. Fragmenting Messages containing unencrypted Payloads
Currently no one of IKEv2 Exchanges defines messages, containing both Currently no one of IKEv2 Exchanges defines messages, containing both
unencrypted payloads and payloads, protected by Encrypted Payload. unencrypted payloads and payloads, protected by Encrypted Payload.
But IKEv2 doesn't forbid such messages. If some future IKEv2 But IKEv2 doesn't forbid such messages. If some future IKEv2
extension defines such a message and it needs to be fragmented, all extension defines such a message and it needs to be fragmented, all
unprotected payloads MUST be in the first fragment, along with unprotected payloads MUST be in the first fragment, along with
Encrypted Fragment Payload, which MUST be present in any IKE Fragment Encrypted Fragment Payload, which MUST be present in any IKE Fragment
Message. Message.
Below is an example of fragmenting message, containing both encrypted Below is an example of fragmenting message, containing both encrypted
skipping to change at page 9, line 26 skipping to change at page 10, line 10
to accommodate unprotected Payloads. In extreme cases Encrypted to accommodate unprotected Payloads. In extreme cases Encrypted
Fragment Payload will contain no data, but it is still MUST be Fragment Payload will contain no data, but it is still MUST be
present in the message, because only its presence allows receiver to present in the message, because only its presence allows receiver to
distinguish IKE Fragment Message from regular IKE message. distinguish IKE Fragment Message from regular IKE message.
2.6. Receiving IKE Fragment Message 2.6. Receiving IKE Fragment Message
Receiver identifies IKE Fragment Message by the presence of Encrypted Receiver identifies IKE Fragment Message by the presence of Encrypted
Fragment Payload in it. Note, that it is possible for this payload Fragment Payload in it. Note, that it is possible for this payload
to be not the first (and the only) payload in the message (see to be not the first (and the only) payload in the message (see
Section 2.5.2). But for all currently defined IKEv2 exchanges this Section 2.5.3). But for all currently defined IKEv2 exchanges this
payload will be the first and the only payload in the message. payload will be the first and the only payload in the message.
Upon receiving IKE Fragment Message the following actions are Upon receiving 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 values of
Fragment Number and Total Fragments in Encrypted Fragment Payload Fragment Number and Total Fragments in Encrypted Fragment Payload
are valid. If not - message MUST be silently discarded. are valid. The following tests need to be performed.
* check that Fragment Number and Total Fragments fields are non-
zero
* check that Fragment Number field is less than or equal to Total
Fragments field
* if reassembling has already started, check that Total Fragments
field is equal to or greater than Total Fragments field in
fragments, that have already received
If either 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 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.
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.
 End of changes. 20 change blocks. 
51 lines changed or deleted 98 lines changed or added

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