< draft-ietf-ipsecme-ddos-protection-05.txt   draft-ietf-ipsecme-ddos-protection-06.txt >
IPSecME Working Group Y. Nir IPSecME Working Group Y. Nir
Internet-Draft Check Point Internet-Draft Check Point
Intended status: Standards Track V. Smyslov Intended status: Standards Track V. Smyslov
Expires: September 22, 2016 ELVIS-PLUS Expires: October 17, 2016 ELVIS-PLUS
March 21, 2016 April 15, 2016
Protecting Internet Key Exchange Protocol version 2 (IKEv2) Protecting Internet Key Exchange Protocol version 2 (IKEv2)
Implementations from Distributed Denial of Service Attacks Implementations from Distributed Denial of Service Attacks
draft-ietf-ipsecme-ddos-protection-05 draft-ietf-ipsecme-ddos-protection-06
Abstract Abstract
This document recommends implementation and configuration best This document recommends implementation and configuration best
practices for Internet Key Exchange Protocol version 2 (IKEv2) practices for Internet Key Exchange Protocol version 2 (IKEv2)
Responders, to allow them to resist Denial of Service and Distributed Responders, to allow them to resist Denial of Service and Distributed
Denial of Service attacks. Additionally, the document introduces a Denial of Service attacks. Additionally, the document introduces a
new mechanism called "Client Puzzles" that help accomplish this task. new mechanism called "Client Puzzles" that help accomplish this task.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 22, 2016. This Internet-Draft will expire on October 17, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3 3. The Vulnerability . . . . . . . . . . . . . . . . . . . . . . 3
4. Defense Measures while IKE SA is being created . . . . . . . 6 4. Defense Measures while IKE SA is being created . . . . . . . 6
4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6 4.1. Retention Periods for Half-Open SAs . . . . . . . . . . . 6
4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 6
4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7 4.3. The Stateless Cookie . . . . . . . . . . . . . . . . . . 7
4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Puzzles . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10 4.5. Session Resumption . . . . . . . . . . . . . . . . . . . 10
4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 10 4.6. Keeping computed Shared Keys . . . . . . . . . . . . . . 10
4.7. Preventing Attacks using "Hash and URL" Certificate 4.7. Preventing Attacks using "Hash and URL" Certificate
Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11 Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11
4.8. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 11
5. Defense Measures after IKE SA is created . . . . . . . . . . 11 5. Defense Measures after IKE SA is created . . . . . . . . . . 11
6. Plan for Defending a Responder . . . . . . . . . . . . . . . 12 6. Plan for Defending a Responder . . . . . . . . . . . . . . . 13
7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 14 7. Using Puzzles in the Protocol . . . . . . . . . . . . . . . . 15
7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15 7.1. Puzzles in IKE_SA_INIT Exchange . . . . . . . . . . . . . 15
7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 15 7.1.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 16
7.1.2. Solving Puzzle and Returning the Solution . . . . . . 18 7.1.2. Solving Puzzle and Returning the Solution . . . . . . 18
7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 18 7.1.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 19
7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19 7.1.4. Analyzing Repeated Request . . . . . . . . . . . . . 19
7.1.5. Making Decision whether to Serve the Request . . . . 20 7.1.5. Making Decision whether to Serve the Request . . . . 20
7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 21 7.2. Puzzles in IKE_AUTH Exchange . . . . . . . . . . . . . . 21
7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22 7.2.1. Presenting Puzzle . . . . . . . . . . . . . . . . . . 22
7.2.2. Solving Puzzle and Returning the Solution . . . . . . 22 7.2.2. Solving Puzzle and Returning the Solution . . . . . . 23
7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 23 7.2.3. Computing Puzzle . . . . . . . . . . . . . . . . . . 23
7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 23 7.2.4. Receiving Puzzle Solution . . . . . . . . . . . . . . 24
8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 24 8. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 24
8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 24 8.1. PUZZLE Notification . . . . . . . . . . . . . . . . . . . 24
8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25 8.2. Puzzle Solution Payload . . . . . . . . . . . . . . . . . 25
9. Operational Considerations . . . . . . . . . . . . . . . . . 26 9. Operational Considerations . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 28 13.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Denial of Service (DoS) attacks have always been considered a serious Denial of Service (DoS) attacks have always been considered a serious
threat. These attacks are usually difficult to defend against since threat. These attacks are usually difficult to defend against since
the amount of resources the victim has is always bounded (regardless the amount of resources the victim has is always bounded (regardless
of how high it is) and because some resources are required for of how high it is) and because some resources are required for
distinguishing a legitimate session from an attack. distinguishing a legitimate session from an attack.
The Internet Key Exchange protocol version 2 (IKEv2) described in The Internet Key Exchange protocol version 2 (IKEv2) described in
skipping to change at page 6, line 47 skipping to change at page 6, line 52
Even with DDoS, the attacker has only a limited amount of nodes Even with DDoS, the attacker has only a limited amount of nodes
participating in the attack. By limiting the amount of half-open SAs participating in the attack. By limiting the amount of half-open SAs
that are allowed to exist concurrently with each such node, the total that are allowed to exist concurrently with each such node, the total
amount of half-open SAs is capped, as is the total amount of key amount of half-open SAs is capped, as is the total amount of key
derivations that the Responder is forced to complete. derivations that the Responder is forced to complete.
In IPv4 it makes sense to limit the number of half-open SAs based on In IPv4 it makes sense to limit the number of half-open SAs based on
IP address. Most IPv4 nodes are either directly attached to the IP address. Most IPv4 nodes are either directly attached to the
Internet using a routable address or are hidden behind a NAT device Internet using a routable address or are hidden behind a NAT device
with a single IPv4 external address. IPv6 networks are currently a with a single IPv4 external address. For IPv6, ISPs assign between a
rarity, so we can only speculate on what their wide deployment will /48 and a /64, so it makes sense to use a 64-bit prefix as the basis
be like, but the current thinking is that ISP customers will be for rate limiting in IPv6.
assigned whole subnets, so we don't expect the kind of NAT deployment
that is common in IPv4. For this reason, it makes sense to use a
64-bit prefix as the basis for rate limiting in IPv6.
The number of half-open SAs is easy to measure, but it is also The number of half-open SAs is easy to measure, but it is also
worthwhile to measure the number of failed IKE_AUTH exchanges. If worthwhile to measure the number of failed IKE_AUTH exchanges. If
possible, both factors should be taken into account when deciding possible, both factors should be taken into account when deciding
which IP address or prefix is considered suspicious. which IP address or prefix is considered suspicious.
There are two ways to rate-limit a peer address or prefix: There are two ways to rate-limit a peer address or prefix:
1. Hard Limit - where the number of half-open SAs is capped, and any 1. Hard Limit - where the number of half-open SAs is capped, and any
further IKE_SA_INIT requests are rejected. further IKE_SA_INIT requests are rejected.
skipping to change at page 7, line 47 skipping to change at page 7, line 49
to counteract the attack can be avoided. to counteract the attack can be avoided.
4.3. The Stateless Cookie 4.3. The Stateless Cookie
Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attack: Section 2.6 of [RFC7296] offers a mechanism to mitigate DoS attack:
the stateless cookie. When the server is under load, the Responder the stateless cookie. When the server is under load, the Responder
responds to the IKE_SA_INIT request with a calculated "stateless responds to the IKE_SA_INIT request with a calculated "stateless
cookie" - a value that can be re-calculated based on values in the cookie" - a value that can be re-calculated based on values in the
IKE_SA_INIT request without storing Responder-side state. The IKE_SA_INIT request without storing Responder-side state. The
Initiator is expected to repeat the IKE_SA_INIT request, this time Initiator is expected to repeat the IKE_SA_INIT request, this time
including the stateless cookie. including the stateless cookie. This mechanism prevents DoS attacks
from spoofed IP addresses, since an attacker needs to have a routable
IP address to return the cookie.
Attackers that have multiple source IP addresses with return Attackers that have multiple source IP addresses with return
routability, such as in the case of bot-nets, can fill up a half-open routability, such as in the case of bot-nets, can fill up a half-open
SA table anyway. The cookie mechanism limits the amount of allocated SA table anyway. The cookie mechanism limits the amount of allocated
state to the size of the bot-net, multiplied by the number of half- state to the number of attackers, multiplied by the number of half-
open SAs allowed per peer address, multiplied by the amount of state open SAs allowed per peer address, multiplied by the amount of state
allocated for each half-open SA. With typical values this can easily allocated for each half-open SA. With typical values this can easily
reach hundreds of megabytes. reach hundreds of megabytes.
4.4. Puzzles 4.4. Puzzles
The puzzle introduced here extends the cookie mechanism from The puzzle introduced here extends the cookie mechanism from
[RFC7296]. It is loosely based on the proof-of-work technique used [RFC7296]. It is loosely based on the proof-of-work technique used
in Bitcoins [bitcoins]. This sets an upper bound, determined by the in Bitcoins [bitcoins]. This sets an upper bound, determined by the
attacker's CPU, to the number of negotiations it can initiate in a attacker's CPU, to the number of negotiations it can initiate in a
skipping to change at page 10, line 44 skipping to change at page 10, line 44
When the Responder is under attack, it MAY choose to prefer When the Responder is under attack, it MAY choose to prefer
previously authenticated peers who present a Session Resumption previously authenticated peers who present a Session Resumption
ticket (see [RFC5723] for details). The Responder MAY require such ticket (see [RFC5723] for details). The Responder MAY require such
Initiators to pass a return routability check by including the COOKIE Initiators to pass a return routability check by including the COOKIE
notification in the IKE_SESSION_RESUME response message, as allowed notification in the IKE_SESSION_RESUME response message, as allowed
by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache by Section 4.3.2. of [RFC5723]. Note that the Responder SHOULD cache
tickets for a short time to reject reused tickets (Section 4.3.1), tickets for a short time to reject reused tickets (Section 4.3.1),
and therefore there should be no issue of half-open SAs resulting and therefore there should be no issue of half-open SAs resulting
from replayed IKE_SESSION_RESUME messages. from replayed IKE_SESSION_RESUME messages.
Several kinds of DoS attacks are possible on servers supported IKE
Session Resumption. See Section 9.3 of [RFC5723] for details.
4.6. Keeping computed Shared Keys 4.6. Keeping computed Shared Keys
Once the IKE_SA_INIT exchange is finished, the Responder is waiting Once the IKE_SA_INIT exchange is finished, the Responder is waiting
for the first message of the IKE_AUTH exchange from the Initiator. for the first message of the IKE_AUTH exchange from the Initiator.
At this point the Initiator is not yet authenticated and this fact At this point the Initiator is not yet authenticated and this fact
allows a malicious peer to perform an attack, described in Section 3 allows a malicious peer to perform an attack, described in Section 3
- it can just send a garbage in the IKE_AUTH message thus forcing the - it can just send a garbage in the IKE_AUTH message thus forcing the
Responder to perform CPU costly operations to compute SK_* keys. Responder to perform CPU costly operations to compute SK_* keys.
If the received IKE_AUTH message failed to decrypt correctly (or If the received IKE_AUTH message failed to decrypt correctly (or
skipping to change at page 11, line 28 skipping to change at page 11, line 30
providing an URL pointing to a large file possibly containing providing an URL pointing to a large file possibly containing
garbage. While downloading the file the responder consumes CPU, garbage. While downloading the file the responder consumes CPU,
memory and network bandwidth. memory and network bandwidth.
To prevent this kind of attacks the responder should not blindly To prevent this kind of attacks the responder should not blindly
download the whole file. Instead it SHOULD first read the initial download the whole file. Instead it SHOULD first read the initial
few bytes, decode the length of the ASN.1 structure from these bytes, few bytes, decode the length of the ASN.1 structure from these bytes,
and then download no more than the decoded number of bytes. Note, and then download no more than the decoded number of bytes. Note,
that it is always possible to determine the length of ASN.1 that it is always possible to determine the length of ASN.1
structures used in IKEv2 by analyzing the first few bytes, if they structures used in IKEv2 by analyzing the first few bytes, if they
are DER-encoded. Implementations SHOULD also apply a configurable are DER-encoded. However, since the content of the file being
hard limit to the number of pulled bytes and SHOULD provide an downloaded can be under attacker's control, implementations should
ability for an administrator to either completely disable this not blindly trust the decoded length and SHOULD check whether it
feature or to limit its use to a configurable list of trusted URLs. makes sense before continue downloading. Implementations SHOULD also
apply a configurable hard limit to the number of pulled bytes and
SHOULD provide an ability for an administrator to either completely
disable this feature or to limit its use to a configurable list of
trusted URLs.
4.8. IKE Fragmentation
IKE Fragmentation described in [RFC7383] allows IKE peers to avoid IP
fragmentation of large IKE messages. Attackers can mount several
kinds of DoS attacks using IKE Fragmentation. See Section 5 of
[RFC7383] for details.
5. Defense Measures after IKE SA is created 5. Defense Measures after IKE SA is created
Once IKE SA is created there is usually not much traffic over it. In Once IKE SA is created there is usually not much traffic over it. In
most cases this traffic consists of exchanges aimed to create most cases this traffic consists of exchanges aimed to create
additional Child SAs, rekey, or delete them and check the liveness of additional Child SAs, rekey, or delete them and check the liveness of
the peer. With a typical setup and typical Child SA lifetimes, there the peer. With a typical setup and typical Child SA lifetimes, there
are typically no more than a few such exchanges, often less. Some of are typically no more than a few such exchanges, often less. Some of
these exchanges require relatively little resources (like liveness these exchanges require relatively little resources (like liveness
check), while others may be resource consuming (like creating or check), while others may be resource consuming (like creating or
skipping to change at page 12, line 5 skipping to change at page 12, line 18
Since any endpoint can initiate a new exchange, there is a Since any endpoint can initiate a new exchange, there is a
possibility that a peer would initiate too many exchanges that could possibility that a peer would initiate too many exchanges that could
exhaust host resources. For example, the peer can perform endless exhaust host resources. For example, the peer can perform endless
continuous Child SA rekeying or create overwhelming number of Child continuous Child SA rekeying or create overwhelming number of Child
SAs with the same Traffic Selectors etc. Such behavior may be caused SAs with the same Traffic Selectors etc. Such behavior may be caused
by buggy implementation, misconfiguration or be intentional. The by buggy implementation, misconfiguration or be intentional. The
latter becomes more of a real threat if the peer uses NULL latter becomes more of a real threat if the peer uses NULL
Authentication, described in [RFC7619]. In this case the peer Authentication, described in [RFC7619]. In this case the peer
remains anonymous, allowing it to escape any responsibility for its remains anonymous, allowing it to escape any responsibility for its
actions. actions. See Section 3 of [RFC7619] for details.
The following recommendations for defense against possible DoS The following recommendations for defense against possible DoS
attacks after IKE SA is established are mostly intended for attacks after IKE SA is established are mostly intended for
implementations that allow unauthenticated IKE sessions; however, implementations that allow unauthenticated IKE sessions; however,
they may also be useful in other cases. they may also be useful in other cases.
o If the IKEv2 window size is greater than one, then the peer could o If the IKEv2 window size is greater than one, then the peer could
initiate multiple simultaneous exchanges that could increase host initiate multiple simultaneous exchanges that could increase host
resource consumption. Since currently there is no way in IKEv2 to resource consumption. Since currently there is no way in IKEv2 to
decrease window size once it was increased (see Section 2.3 of decrease window size once it was increased (see Section 2.3 of
skipping to change at page 12, line 32 skipping to change at page 12, line 45
often, implementations can respond to some of these requests with often, implementations can respond to some of these requests with
the TEMPORARY_FAILURE notification, indicating that the request the TEMPORARY_FAILURE notification, indicating that the request
should be retried after some period of time. should be retried after some period of time.
o If the peer creates too many Child SA with the same or overlapping o If the peer creates too many Child SA with the same or overlapping
Traffic Selectors, implementations can respond with the Traffic Selectors, implementations can respond with the
NO_ADDITIONAL_SAS notification. NO_ADDITIONAL_SAS notification.
o If the peer initiates too many exchanges of any kind, o If the peer initiates too many exchanges of any kind,
implementations can introduce an artificial delay before implementations can introduce an artificial delay before
responding to request messages. This delay would decrease the responding to each request message. This delay would decrease the
rate the implementation need to process requests from any rate the implementation need to process requests from any
particular peer, making it possible to process requests from the particular peer, making it possible to process requests from the
others. The delay should not be too long to avoid causing the IKE others. Note, that if the Responder receives retransmissions of
SA to be deleted on the other end due to timeout. It is believed the request message during the delay period, the retransmitted
that a few seconds is enough. Note, that if the Responder messages should be silently discarded. The delay should not be
receives retransmissions of the request message during the delay too long to avoid causing the IKE SA to be deleted on the other
period, the retransmitted messages should be silently discarded. end due to timeout. It is believed that a few seconds is enough.
Note however, that even a few seconds may be too long in those
settings, that rely on immediate response to the request message,
e.g. for the purposes of quick detection of a dead peer.
o If these counter-measures are inefficient, implementations can o If these counter-measures are inefficient, implementations can
delete the IKE SA with an offending peer by sending Delete delete the IKE SA with an offending peer by sending Delete
Payload. Payload.
In IKEv2 client can request various configuration attributes from
server. Most often those attributes include internal IP addresses.
Malicious clients can try to exhaust server's IP address pool by
continuously requesting a large number of internal addresses. Server
implementations SHOULD limit the number of IP addresses allocated to
any particular client. Note, that it is not possible with clients
using NULL Authentication, since their identity cannot be verified.
6. Plan for Defending a Responder 6. Plan for Defending a Responder
This section outlines a plan for defending a Responder from a DDoS This section outlines a plan for defending a Responder from a DDoS
attack based on the techniques described earlier. The numbers given attack based on the techniques described earlier. The numbers given
here are not normative, and their purpose is to illustrate the here are not normative, and their purpose is to illustrate the
configurable parameters needed for defeating the DDoS attack. configurable parameters needed for defeating the DDoS attack.
Implementations may be deployed in different environments, so it is Implementations may be deployed in different environments, so it is
RECOMMENDED that the parameters be settable. As an example, most RECOMMENDED that the parameters be settable. As an example, most
commercial products are required to undergo benchmarking where the commercial products are required to undergo benchmarking where the
skipping to change at page 27, line 5 skipping to change at page 27, line 24
e.g. mobile phones or some IoT devices. If puzzles are hard then the e.g. mobile phones or some IoT devices. If puzzles are hard then the
required additional power consumption may appear to be unacceptable required additional power consumption may appear to be unacceptable
for some Initiators. The Responder SHOULD take this possibility into for some Initiators. The Responder SHOULD take this possibility into
considerations while choosing the puzzles difficulty and while considerations while choosing the puzzles difficulty and while
selecting which percentage of Initiators are allowed to reject selecting which percentage of Initiators are allowed to reject
solving puzzles. See Section 7.1.4 for details. solving puzzles. See Section 7.1.4 for details.
If the Initiator uses NULL Authentication [RFC7619] then its identity If the Initiator uses NULL Authentication [RFC7619] then its identity
is never verified, that may be used by attackers to perform DoS is never verified, that may be used by attackers to perform DoS
attack after IKE SA is established. Responders that allow attack after IKE SA is established. Responders that allow
unauthenticated Initiators to connect must be prepared deal with unauthenticated Initiators to connect must be prepared to deal with
various kinds of DoS attacks even after IKE SA is created. See various kinds of DoS attacks even after IKE SA is created. See
Section 5 for details. Section 5 for details.
To prevent amplification attacks implementations must strictly follow To prevent amplification attacks implementations must strictly follow
the retransmission rules described in Section 2.1 of [RFC7296]. the retransmission rules described in Section 2.1 of [RFC7296].
11. IANA Considerations 11. IANA Considerations
This document defines a new payload in the "IKEv2 Payload Types" This document defines a new payload in the "IKEv2 Payload Types"
registry: registry:
 End of changes. 22 change blocks. 
34 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/