draft-ietf-ipsecme-ikev2-fragmentation-05.txt   draft-ietf-ipsecme-ikev2-fragmentation-06.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Intended status: Standards Track November 3, 2013 Intended status: Standards Track March 14, 2014
Expires: May 7, 2014 Expires: September 15, 2014
IKEv2 Fragmentation IKEv2 Fragmentation
draft-ietf-ipsecme-ikev2-fragmentation-05 draft-ietf-ipsecme-ikev2-fragmentation-06
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 May 5, 2014. This Internet-Draft will expire on September 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14 4. Transport Considerations . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20 Appendix A. Design rationale . . . . . . . . . . . . . . . . . . 20
Appendix B. Correlation between IP Datagram size and Appendix B. Correlation between IP Datagram size and
Encrypted Payload content size . . . . . . . . . . . 21 Encrypted Payload content size . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
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. Most IKEv2 [RFC5996], 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
are transferred. When IKE message size exceeds path MTU, it gets are transferred. When IKE message size exceeds path MTU, it gets
fragmented by IP level. The problem is that some network devices, fragmented by IP level. The problem is that some network devices,
skipping to change at page 4, line 48 skipping to change at page 4, line 48
employed. According to [RFC0791] the minimum IP Datagram size that employed. According to [RFC0791] the minimum IP Datagram size that
is guaranteed not to be further fragmented is 68 bytes. So, even the is guaranteed not to be further fragmented is 68 bytes. So, even the
smallest IKE Fragment Messages could be fragmented by IP level in smallest IKE Fragment Messages could be fragmented by IP level in
some circumstances. But such extremely small PMTU sizes are very some circumstances. But such extremely small PMTU sizes are very
rare in real life. rare in real life.
2.3. Negotiation 2.3. Negotiation
Initiator MAY indicate its support for IKE Fragmentation and Initiator MAY indicate its support for IKE Fragmentation and
willingness to use it by including Notification Payload of type willingness to use it by including Notification Payload of type
IKE_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If IKEV2_FRAGMENTATION_SUPPORTED in IKE_SA_INIT request message. If
Responder also supports this extension and is willing to use it, it Responder also supports this extension and is willing to use it, it
includes this notification in response message. includes this notification in response message.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni, HDR, SAi1, KEi, Ni,
[N(IKE_FRAGMENTATION_SUPPORTED)] --> [N(IKEV2_FRAGMENTATION_SUPPORTED)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ], <-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(IKE_FRAGMENTATION_SUPPORTED)] [N(IKEV2_FRAGMENTATION_SUPPORTED)]
The Notify payload is formatted as follows: The Notify payload is formatted as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol ID(=0)| SPI Size (=0) | Notify Message Type | |Protocol ID(=0)| SPI Size (=0) | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) MUST be 0. o Protocol ID (1 octet) MUST be 0.
o SPI Size (1 octet) MUST be 0, meaning no SPI is present. o SPI Size (1 octet) MUST be 0, meaning no SPI is present.
o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned o Notify Message Type (2 octets) - MUST be xxxxx, the value assigned
for IKE_FRAGMENTATION_SUPPORTED by IANA. for IKEV2_FRAGMENTATION_SUPPORTED by IANA.
This Notification contains no data. This Notification contains no data.
2.4. Using IKE Fragmentation 2.4. Using IKE Fragmentation
IKE Fragmentation MUST NOT be used unless both peers indicated their IKE Fragmentation MUST NOT be used unless both peers indicated their
support for it. After IKE Fragmentation is negotiated, it is up to support for it. After IKE Fragmentation is negotiated, it is up to
Initiator of each Exchange, whether to use it or not. In most cases Initiator of each Exchange, whether to use it or not. In most cases
IKE Fragmentation will be used in IKE_AUTH Exchange, especially if IKE Fragmentation will be used in IKE_AUTH Exchange, especially if
certificates are employed. Initiator may first try to send certificates are employed. Initiator may first try to send
skipping to change at page 6, line 51 skipping to change at page 6, line 51
authenticated. Thus, the Encrypted Fragment Payload contains a chunk authenticated. Thus, the Encrypted Fragment Payload contains a chunk
of the original content of Encrypted Payload in encrypted form. The of the original content of Encrypted Payload in encrypted form. The
cryptographic processing of Encrypted Fragment Payload is identical cryptographic processing of Encrypted Fragment Payload is identical
to Section 3.14 of [RFC5996], as well as documents updating it for to Section 3.14 of [RFC5996], as well as documents updating it for
particular algorithms or modes, such as [RFC5282]. particular algorithms or modes, such as [RFC5282].
The Encrypted Fragment Payload, similarly to the Encrypted Payload, The Encrypted Fragment Payload, similarly to the Encrypted Payload,
if present in a message, MUST be the last payload in the message. if present in a message, MUST be the last payload in the message.
The Encrypted Fragment Payload is denoted SKF{...} and its payload The Encrypted Fragment Payload is denoted SKF{...} and its payload
type is XXX (TBA by IANA). type is XXX (TBA by IANA). This payload is also called the
"Encrypted and Authenticated Fragment" payload.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Number | Total Fragments | | Fragment Number | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector | | Initialization Vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 9 skipping to change at page 9, line 11
Initiator MAY try to discover path MTU by probing several values of Initiator MAY try to discover path MTU by probing several values of
fragmentation threshold. While doing probes, node MUST start from fragmentation threshold. While doing probes, node MUST start from
larger values and refragment message with next smaller value if it larger values and refragment message with next smaller value if it
doesn't receive response in a reasonable time after several doesn't receive response in a reasonable time after several
retransmissions. This time is supposed to be relatively short, so retransmissions. This time is supposed to be relatively short, so
that node could make all desired probes before exchange times out. that node could make all desired probes before exchange times out.
When starting new probe (with smaller threshold) node MUST reset its When starting new probe (with smaller threshold) node MUST reset its
retransmission timers so, that if it employs exponential back-off, retransmission timers so, that if it employs exponential back-off,
the timers start over. After reaching the smallest allowed value for the timers start over. After reaching the smallest allowed value for
fragmentation threshold implementation MUST continue probing using it fragmentation threshold implementation MUST continue probing using it
untill either exchange completes ot times out. until either exchange completes or times out.
PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is PMTU discovery in IKE is supposed to be coarse-grained, i.e. it is
expected, that node will try only few fragmentation thresholds, in expected, that node will try only few fragmentation thresholds, in
order to minimize possible IKE SA establishment delay. In a corner order to minimize possible IKE SA establishment delay. In a corner
case, when host will use only one value, PMTU discovery will case, when host will use only one value, PMTU discovery will
effectively be disabled. In most cases PMTU discovery will not be effectively be disabled. In most cases PMTU discovery will not be
needed, as using values, recommended in section Section 2.5.1, should needed, as using values, recommended in section Section 2.5.1, should
suffice. It is expected, that PMTU discovery may be useful in suffice. It is expected, that PMTU discovery may be useful in
environments where PMTU size are smaller, than those listed in environments where PMTU size are smaller, than those listed in
Section 2.5.1, for example due to the presence of intermediate Section 2.5.1, for example due to the presence of intermediate
tunnels. tunnels.
PMTU discovery in IKE follows recommendations, given in Section 10.4 PMTU discovery in IKE follows recommendations, given in Section 10.4
of RFC4821 [RFC4821] with some differences, induced by the of RFC4821 [RFC4821] with some differences, induced by the
specialities of IKE. In particular: specialties of IKE. In particular:
o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of o Unlike classical PMTUD [RFC1191] and PLMTUD [RFC4821] the goal of
Path MTU discovery in IKE is not to find the largest size of IP Path MTU discovery in IKE is not to find the largest size of IP
packet, that will not be fragmented en route, but to find any packet, that will not be fragmented en route, but to find any
reasonal size, probably far from optimal. reasonable size, probably far from optimal.
o There is no goal to completely disallow IP fragmentation until its o There is no goal to completely disallow IP fragmentation until its
presence leads to inability IKE to communicate (e.g. when IP presence leads to inability IKE to communicate (e.g. when IP
fragments are dropped) fragments are dropped)
o IKE usually sends large messages only in IKE_AUTH exchange, i.e. o IKE usually sends large messages only in IKE_AUTH exchange, i.e.
once per IKE SA. Most of other messages will have size below once per IKE SA. Most of other messages will have size below
several hundred bytes. Performing full PMTUD for sending exactly several hundred bytes. Performing full PMTUD for sending exactly
one large message is inefficient. one large message is inefficient.
skipping to change at page 11, line 48 skipping to change at page 11, line 49
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 already decrypted Encrypted field) are received, content of their already decrypted Encrypted
Fragment Payloads is merged together to form content of original Fragment Payloads is merged together to form content of original
Encrypted Payload, and, therefore, along with IKE Header and Encrypted Payload, and, therefore, along with IKE Header and
unencrypted Payloads (if any), original message. Then it is unencrypted Payloads (if any), original message. Then it is
processed as if it was received, verified and decrypted as regular processed as if it was received, verified and decrypted as regular
unfragmented message. unfragmented message.
If receiver does't get all IKE Fragment Messages needed to reassemble If receiver doesn't get all IKE Fragment Messages needed to
original Message for some Exchange within a timeout interval, it acts reassemble original Message for some Exchange within a timeout
according with Section 2.1 of [RFC5996], i.e. retransmits the interval, it acts according with Section 2.1 of [RFC5996], i.e.
fragmented request Message (in case of Initiator) or deems Exchange
to have failed. If Exchange is abandoned, all received so far IKE retransmits the fragmented request Message (in case of Initiator) or
Fragment Messages for that Exchange MUST be discarded. deems Exchange to have failed. If Exchange is abandoned, all
received so far IKE 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 12, line 38 skipping to change at page 12, line 42
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 in IKE 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 If Initiator doesn't receive any of response IKE Fragment Messages
withing a timeout interval, it MAY refragment request Message using within a timeout interval, it MAY refragment request Message using
smaller fragmentation threshold before retransmitting it (see smaller fragmentation threshold before retransmitting it (see
Section 2.5.1). In this case Total Fragments field in new IKE 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 MUST be greater than in previously sent IKE
Fragment Messages. Alternatively, if Initiator does receive some Fragment Messages. Alternatively, if Initiator does receive some
(but not all) of response IKE Fragment Messages, it MAY retransmit (but not all) of response IKE Fragment Messages, it MAY retransmit
only the first of request IKE Fragment Messages, where Fragment only the first of request IKE Fragment Messages, where Fragment
Number field is equal to 1. Number field is equal to 1.
3. Interaction with other IKE extensions 3. Interaction with other IKE extensions
skipping to change at page 16, line 10 skipping to change at page 16, line 10
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.
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 Fragment Payload 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
Messages Types - Status Types" registry: Message Types - Status Types" registry:
<TBA> IKE_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 and others for their reviews and valueable comments. Yaron Sheffer, Joe Touch and others for their reviews 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)",
skipping to change at page 20, line 11 skipping to change at page 20, line 11
Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
protection for UDP-based protocols", ACM Conference on protection for UDP-based protocols", ACM Conference on
Computer and Communications Security, October 2003. Computer and Communications Security, October 2003.
Appendix A. Design rationale Appendix A. Design rationale
The simplest approach to the IKE fragmentation would have been to The simplest approach to the IKE fragmentation would have been to
fragment message that is fully formed and ready to be sent. But if fragment message that is fully formed and ready to be sent. But if
message got fragmented after being encrypted and authenticated, this message got fragmented after being encrypted and authenticated, this
could open a possibility for a simple Denial of Service attack. The could open a possibility for a simple Denial of Service attack. The
attacker could infrequently emit forged but looking valid fragments attacker could infrequently emit forged but valid looking fragments
into the network, and some of these fragments would be fetched by into the network, and some of these fragments would be fetched by
receiver into the reassempling queue. Receiver could not distinguish receiver into the reassembling queue. Receiver could not distinguish
forged fragments from valid ones and could only determine that some forged fragments from valid ones and could only determine that some
of received fragments were forged when the whole message got of received fragments were forged when the whole message got
reassembled and check for its authenticity failed. reassembled and check for its authenticity failed.
To prevent this kind of attack and also to reduce vulnerability to To prevent this kind of attack and also to reduce vulnerability to
some other kinds of DoS attacks it was decided to make fragmentation some other kinds of DoS attacks it was decided to make fragmentation
before applying cryptographic protection to the message. In this before applying cryptographic protection to the message. In this
case each Fragment Message becomes individually encrypted and case each Fragment Message becomes individually encrypted and
authenticated, that allows receiver to determine forgeg fragments and authenticated, that allows receiver to determine forged fragments and
not to fetch them into the reassempling queue. not to store them in the reassembling queue.
Appendix B. Correlation between IP Datagram size and Encrypted Payload Appendix B. Correlation between IP Datagram size and Encrypted Payload
content size content size
For IPv4 Encrypted Payload content size is less than IP Datagram size For IPv4 Encrypted Payload content size is less than IP Datagram size
by the sum of the following values: by the sum of the following values:
o IPv4 header size (typically 20 bytes, up to 60 if IP options are o IPv4 header size (typically 20 bytes, up to 60 if IP options are
present) present)
skipping to change at page 21, line 30 skipping to change at page 21, line 30
o Encrypted Payload header size (4 bytes) o Encrypted Payload header size (4 bytes)
o IV size (varying) o IV size (varying)
o padding and its size (at least 1 byte) o padding and its size (at least 1 byte)
o ICV size (varying) o ICV size (varying)
The sum may be estimated as 61..105 bytes + IV + ICV + padding. The sum may be estimated as 61..105 bytes + IV + ICV + padding.
For IPv6 this estimation is difficult as there may be varying IPv6 For IPv6 Encrypted Payload content size is less than IP Datagram size
Extension headers included. by the sum of the following values:
o IPv6 header size (40 bytes)
o IPv6 extension headers (optional, size varies)
o UDP header size (8 bytes)
o non-ESP marker size (4 bytes if present)
o IKE Header size (28 bytes)
o Encrypted Payload header size (4 bytes)
o IV size (varying)
o padding and its size (at least 1 byte)
o ICV size (varying)
If no extension header is present, the sum may be estimated as 81..85
bytes + IV + ICV + padding. If extension headers are present, the
payload content size is further reduced by the sum of the size of the
extension headers. The length of each extension header can be
calculated as 8 * (Hdr Ext Len) bytes except for the fragment header
which is always 8 bytes in length.
Author's Address Author's Address
Valery Smyslov Valery Smyslov
ELVIS-PLUS ELVIS-PLUS
PO Box 81 PO Box 81
Moscow (Zelenograd) 124460 Moscow (Zelenograd) 124460
RU Russian Federation
Phone: +7 495 276 0211 Phone: +7 495 276 0211
Email: svan@elvis.ru Email: svan@elvis.ru
 End of changes. 24 change blocks. 
32 lines changed or deleted 61 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/