draft-ietf-ipsecme-ikev2-fragmentation-09.txt   draft-ietf-ipsecme-ikev2-fragmentation-10.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track June 6, 2014 Intended status: Standards Track June 10, 2014
Expires: December 8, 2014 Expires: December 12, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-09 draft-ietf-ipsecme-ikev2-fragmentation-10
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 December 8, 2014. This Internet-Draft will expire on December 12, 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 2, line 26 skipping to change at page 2, line 26
2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 7 2.5. Fragmenting Message . . . . . . . . . . . . . . . . . . . 7
2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 9 2.5.1. Selecting Fragment Size . . . . . . . . . . . . . . . 9
2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10 2.5.2. PMTU Discovery . . . . . . . . . . . . . . . . . . . . 10
2.5.3. Fragmenting Messages containing unprotected 2.5.3. Fragmenting Messages containing unprotected
Payloads . . . . . . . . . . . . . . . . . . . . . . . 11 Payloads . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12 2.6. Receiving IKE Fragment Message . . . . . . . . . . . . . . 12
2.6.1. Replay Detection and Retransmissions . . . . . . . . . 14 2.6.1. Replay Detection and Retransmissions . . . . . . . . . 14
3. Interaction with other IKE extensions . . . . . . . . . . . . 15 3. Interaction with other IKE extensions . . . . . . . . . . . . 15
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 22 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 23
Appendix B. Correlation between IP Datagram size and Appendix B. Correlation between IP Datagram size and
Encrypted Payload content size . . . . . . . . . . . 23 Encrypted Payload content size . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
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
skipping to change at page 18, line 5 skipping to change at page 17, line 46
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 the receiver's memory load. Some calculated dynamically depending on the receiver's memory load. Some
care should be taken when selecting this value because, if it is too care should be taken when selecting this value because, if it is too
small, it might prevent legitimate peer to establish IKE SA if the small, it might prevent legitimate peer to establish IKE SA if the
size of messages it sends exceeds this value. It is NOT RECOMMENDED size of messages it sends exceeds this value. It is NOT RECOMMENDED
for this value to exceed 64 Kbytes because any IKE message before for this value to exceed 64 Kbytes because any IKE message before
fragmentation would likely be shorter than that. fragmentation would likely be shorter than that.
If IKE fragments arrive in order, it is possible, but not advised,
for receiver to parse the beginning of the message that is being
reassembled and extract the already available payloads before the
reassembly is complete. It can be dangerous to take any action based
on the content of these payloads, because the not yet received
fragments might contain payloads that could change the meaning of
them (or could even make the whole message invalid) and this can
potentially be exploited by an attacker. It is important to address
this threat by ensuring all the fragments are received prior to parse
reassembled message, as it described in Section 2.6.
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. 6 change blocks. 
12 lines changed or deleted 23 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/