draft-ietf-ipsecme-ikev2-fragmentation-01.txt   draft-ietf-ipsecme-ikev2-fragmentation-02.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track August 23, 2013 Intended status: Standards Track September 9, 2013
Expires: February 24, 2014 Expires: March 13, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-01 draft-ietf-ipsecme-ikev2-fragmentation-02
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 February 24, 2014. This Internet-Draft will expire on March 13, 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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . 7
2.5.2. Fragmenting Messages containing unencrypted 2.5.2. Fragmenting Messages containing unencrypted
Payloads . . . . . . . . . . . . . . . . . . . . . . . 8 Payloads . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9
2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10
3. Interaction with other IKE extensions . . . . . . . . . . . . 11 3. Interaction with other IKE extensions . . . . . . . . . . . . 12
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 12 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 17 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 18
Appendix B. Correlation between IP Datagram size and Appendix B. Correlation between IP Datagram size and
Encrypted Payload content size . . . . . . . . . . . 18 Encrypted Payload content size . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
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 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
original Message for some Exchange within a timeout interval, it acts
according with Section 2.1 of [RFC5996], i.e. retransmits the
fragmented request Message (in case of Initiator) or deems IKE SA to
have failed. In the former case Initiator MAY refragment request
Message using smaller fragmentation threshold before retransmitting
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
retransmissions and replays. retransmissions and replays.
skipping to change at page 13, line 5 skipping to change at page 13, line 16
With IKE Fragmentation if any single IKE Fragment Message get lost, With IKE Fragmentation if any single IKE Fragment Message get lost,
receiver becomes unable to reassemble original Message. So, in receiver becomes unable to reassemble original Message. So, in
general, using IKE Fragmentation implies higher probability for the general, using IKE Fragmentation implies higher probability for the
Message not to be delivered to the peer. Although in most network Message not to be delivered to the peer. Although in most network
environments the difference will be insignificant, on some lossy environments the difference will be insignificant, on some lossy
networks it may become noticeable. When using IKE Fragmentation networks it may become noticeable. When using IKE Fragmentation
implementations MAY use longer timeouts and do more retransmits implementations MAY use longer timeouts and do more retransmits
before considering peer dead. before considering peer dead.
Note that Fragment Messages are not individually acknowledged. The
response Fragment Messages are sent back all together only when all
fragments of request are received, the original request Message is
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 Denial of
Service attack. Service attack.
6. IANA Considerations 6. IANA Considerations
 End of changes. 7 change blocks. 
15 lines changed or deleted 29 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/