draft-ietf-ipsecme-ikev2-fragmentation-02.txt   draft-ietf-ipsecme-ikev2-fragmentation-03.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track September 9, 2013 Intended status: Standards Track October 4, 2013
Expires: March 13, 2014 Expires: April 7, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-02 draft-ietf-ipsecme-ikev2-fragmentation-03
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 March 13, 2014. This Internet-Draft will expire on April 7, 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 4, line 10 skipping to change at page 4, line 10
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 the set
of smaller ones, calling Fragment Messages. Fragmentation takes of smaller ones, calling 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 Fragment Message receives individual protection. On the that each IKE Fragment Message receives individual protection. On
receiving side Fragment Messages are collected, verified, decrypted the receiving side IKE Fragment Messages are collected, verified,
and merged together to get the original message before encryption. decrypted and merged together to get the original message before
For design rationale see Appendix A. encryption. For design rationale see Appendix A.
2.2. Limitations 2.2. Limitations
As Fragment Messages are cryptographically protected, SK_a and SK_e As IKE Fragment Messages are cryptographically protected, SK_a and
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 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, since IKE_SA_INIT fragmented. In most cases this is not a problem, since 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
won't help. won't help.
skipping to change at page 7, line 12 skipping to change at page 7, line 12
~ Integrity Checksum Data ~ ~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Encrypted Fragment Payload Encrypted Fragment Payload
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. 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. 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
skipping to change at page 10, line 15 skipping to change at page 10, line 15
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 Encrypted Fragment Payloads is
decrypted and merged together to form content of original Encrypted decrypted and merged together to form content of original Encrypted
Payload, and, therefore, along with IKE Header and unencrypted Payload, and, therefore, along with IKE Header and unencrypted
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 unfragmented message. was received, verified and decrypted as regular unfragmented message.
If receiver does't get all 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 IKE SA to fragmented request Message (in case of Initiator) or deems Exchange
have failed. In the former case Initiator MAY refragment request to have failed. If Exchange is abandoned, all received so far IKE
Message using smaller fragmentation threshold before retransmitting Fragment Messages for that Exchange MUST be discarded.
it (see Section 2.5.1). If Exchange is abandoned, all received so
far Fragment Messages for that Exchange MUST be discarded.
2.6.1. Changes in Replay Protection Logic 2.6.1. Changes in Replay Protection Logic
According to [RFC5996] IKEv2 MUST reject message with the same According to [RFC5996] IKEv2 MUST reject message with the same
Message ID as it has seen before (taking into consideration Response Message ID as it has seen before (taking into consideration Response
bit). This logic has already been updated by [RFC6311], which bit). This logic has already been updated by [RFC6311], which
deliberately allows any number of messages with zero Message ID. deliberately allows any number of messages with zero Message ID.
This document also updates this logic: if message contains Encrypted This document also updates this logic: if message contains Encrypted
Fragment Payload, the values of Fragment Number and Total Fragments Fragment Payload, the values of Fragment Number and Total Fragments
fields from this payload MUST be used along with Message ID to detect fields from this payload MUST be used along with Message ID to detect
skipping to change at page 10, line 48 skipping to change at page 10, line 46
it activated IKE Fragmentation. If Fragment Number in Encrypted it activated IKE Fragmentation. If Fragment Number in Encrypted
Fragment Payload in this message is equal to 1, Responder MUST Fragment Payload in this message is equal to 1, Responder MUST
fragment its response and retransmit it back to Initiator in fragment its response and retransmit it back to Initiator in
fragmented form. fragmented form.
If Responder receives a replay IKE Fragment Message for already If Responder receives a replay IKE Fragment Message for already
reassembled, verified and processed fragmented message, it MUST reassembled, verified and processed fragmented message, it MUST
retransmit response back to Initiator, but only if Fragment Number retransmit response back to Initiator, but only if Fragment Number
field in Encrypted Fragment Payload is equal to 1 and MUST silently field in Encrypted Fragment Payload is equal to 1 and MUST silently
discard received message otherwise. If Total Fragments field in discard received message otherwise. If Total Fragments field in
received IKE Fragment Message is greater than this field in Fragment received IKE Fragment Message is greater than in IKE Fragment
Messages that already processed fragmented message was reassembled Messages that already processed fragmented message was reassembled
from, Responder MAY refragment its response message using smaller from, Responder MAY refragment its response message using smaller
fragmentation threshold before resending it back to Initiator. In fragmentation threshold before resending it back to Initiator. In
this case Total Fragments field in new IKE Fragment Messages MUST be this case Total Fragments field in new IKE Fragment Messages MUST be
greater than in previously sent IKE Fragment Messages. greater than in previously sent IKE Fragment Messages.
If Initiator doesn't receive any of response IKE Fragment Messages
withing a timeout interval, it MAY refragment request Message using
smaller fragmentation threshold before retransmitting it (see
Section 2.5.1). In this case Total Fragments field in new IKE
Fragment Messages MUST be greater than in previously sent IKE
Fragment Messages. Alternatively, if Initiator does receive some
(but not all) of response IKE Fragment Messages, it MAY retransmit
only the first of request IKE Fragment Messages, where Fragment
Number field is equal to 1.
3. Interaction with other IKE extensions 3. Interaction with other IKE extensions
IKE Fragmentation is compatible with most of defined IKE extensions, IKE Fragmentation is compatible with most of defined IKE extensions,
like IKE Session Resumption [RFC5723], Quick Crash Detection Method like IKE Session Resumption [RFC5723], Quick Crash Detection Method
[RFC6290] and so on. It neither affect their operation, nor is [RFC6290] and so on. It neither affect their operation, nor is
affected by them. It is believed that IKE Fragmentation will also be affected by them. It is believed that IKE Fragmentation will also be
compatible with most future IKE extensions, if they follow general compatible with most future IKE extensions, if they follow general
principles of formatting, sending and receiving IKE messages, principles of formatting, sending and receiving IKE messages,
described in [RFC5996]. described in [RFC5996].
 End of changes. 11 change blocks. 
19 lines changed or deleted 27 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/