--- 1/draft-ietf-ipsecme-ikev2-fragmentation-01.txt 2013-09-09 06:14:24.630843659 -0700 +++ 2/draft-ietf-ipsecme-ikev2-fragmentation-02.txt 2013-09-09 06:14:24.662844505 -0700 @@ -1,18 +1,18 @@ Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS -Intended status: Standards Track August 23, 2013 -Expires: February 24, 2014 +Intended status: Standards Track September 9, 2013 +Expires: March 13, 2014 IKEv2 Fragmentation - draft-ietf-ipsecme-ikev2-fragmentation-01 + draft-ietf-ipsecme-ikev2-fragmentation-02 Abstract This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -21,21 +21,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,32 +53,32 @@ 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. Using IKE Fragmentation . . . . . . . . . . . . . . . . . 5 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 6 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 7 2.5.2. Fragmenting Messages containing unencrypted Payloads . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 9 2.6.1. Changes in Replay Protection Logic . . . . . . . . . . 10 - 3. Interaction with other IKE extensions . . . . . . . . . . . . 11 - 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 12 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 - Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 17 + 3. Interaction with other IKE extensions . . . . . . . . . . . . 12 + 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 + Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 18 Appendix B. Correlation between IP Datagram size and - Encrypted Payload content size . . . . . . . . . . . 18 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 + Encrypted Payload content size . . . . . . . . . . . 19 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC5996], uses UDP as a transport for its messages. When IKE message size exceeds path MTU, it gets 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. @@ -380,20 +380,29 @@ o Store message in the list waiting for the rest of fragments to arrive. When all IKE Fragment Messages (as indicated in the Total Fragments field) are received, content of their Encrypted Fragment Payloads is decrypted and merged together to form content of original Encrypted Payload, and, therefore, along with IKE Header and unencrypted Payloads (if any), original message. Then it is processed as if it 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 According to [RFC5996] IKEv2 MUST reject message with the same Message ID as it has seen before (taking into consideration Response bit). This logic has already been updated by [RFC6311], which deliberately allows any number of messages with zero Message ID. This document also updates this logic: if message contains Encrypted Fragment Payload, the values of Fragment Number and Total Fragments fields from this payload MUST be used along with Message ID to detect retransmissions and replays. @@ -451,20 +460,25 @@ With IKE Fragmentation if any single IKE Fragment Message get lost, receiver becomes unable to reassemble original Message. So, in general, using IKE Fragmentation implies higher probability for the Message not to be delivered to the peer. Although in most network environments the difference will be insignificant, on some lossy networks it may become noticeable. When using IKE Fragmentation implementations MAY use longer timeouts and do more retransmits 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 Most of the security considerations for IKE Fragmentation are the same as those for base IKEv2 protocol described in [RFC5996]. This extension introduces Encrypted Fragment Payload to protect content of IKE Message Fragment. This allows receiver to individually check authenticity of fragments, thus protecting peers from Denial of Service attack. 6. IANA Considerations