draft-ietf-ipsecme-ikev2-fragmentation-06.txt   draft-ietf-ipsecme-ikev2-fragmentation-07.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track March 14, 2014 Intended status: Standards Track April 4, 2014
Expires: September 15, 2014 Expires: October 6, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-06 draft-ietf-ipsecme-ikev2-fragmentation-07
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 September 15, 2014. This Internet-Draft will expire on October 6, 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 16, line 5 skipping to change at page 15, line 18
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 DoS attack. authenticity of fragments, thus protecting peers from DoS attack.
Security Considerations Section of [RFC5996] mentions possible attack Security Considerations Section of [RFC5996] mentions possible attack
on IKE by exhausting of the IP reassembly buffers. The mechanism, on IKE by exhausting of the IP reassembly buffers. The mechanism,
described in this document, allows IKE to avoid IP-fragmentation and described in this document, allows IKE to avoid IP-fragmentation and
therefore increases its robustness to DoS attacks. therefore increases its robustness to DoS attacks.
The following attack is possible with IKE Fragmentation. An attacker
can initiate IKE_SA_INIT exchange, complete it, compute SK_a and SK_e
and then send a large, but still incomplete, set of IKE_AUTH
fragments. These fragments will pass the ICV check and will be
stored in reassembly buffers, but as the set is incomplete, the
reassembling will never succeed and eventually will time out. If the
set is large, this attack could potentially exhaust the receiver's
memory resources.
To mitigate the impact of this attack, it is RECOMMENDED that
receiver limits the number of fragments it stores in reassembling
queue so that the sum of the sizes of Encrypted Fragment Payload
contents (after decryption) for fragments that are already placed
into reassembling queue be less than some value that is reasonable
for the implementation. If the peer sends so many fragments, that
the above condition is not met, the receiver can consider this
situation to be either attack or as broken sender implementation. In
either case, the receiver SHOULD drop the connection and discard all
the received fragments.
This value can be predefined, can be a configurable option, or can be
calculated dynamically depending on receiver's memory load. In any
case, the value SHOULD NOT exceed 64 Kbytes (the maximum size of UDP
datagram) because any IKE message before fragmentation must be
shorter than that.
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:
<TBA> IKEV2_FRAGMENTATION_SUPPORTED <TBA> IKEV2_FRAGMENTATION_SUPPORTED
7. Acknowledgements 7. Acknowledgements
The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters, The author would like to thank Tero Kivinen, Yoav Nir, Paul Wouters,
Yaron Sheffer, Joe Touch and others for their reviews and valuable Yaron Sheffer, Joe Touch, Derek Atkins and others for their reviews
comments. and valuable comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
 End of changes. 5 change blocks. 
6 lines changed or deleted 32 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/