Subject: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Tue, 1 Mar 2016 15:33:46 +0000

All:

With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe the draft is shaping up nicely, but needs additional review. To that end, this message starts a Working Group Last Call (WGLC) for draft-ietf-ipsecme-ddos-protection-04.

The version to be reviewed is https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt.

Please send your comments, questions, and edit proposals to the WG mail list until March 18, 2015.  If you believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC please send a short message stating this.

Best Regards,
Dave

---

From: "Dr. Karan Verma" <[email-masked]>
Date: Fri, 4 Mar 2016 13:35:38 +0530

Hello Dave

there are some suggestions and comments:

1. The root CA certificate corresponding to the server certificate must be
installed on the client computers in the Trusted Root Certification
Authorities per-computer certificate store. The client computer must be
able to validate the server certificate as being signed by a trusted root
CA.

If you are already using SSTP connections, then you can use the same
certificate for both SSTP and IKEv2, as long as the certificate meets the
CN and EKU requirements identified previously. Because root CA certificates
are required on client computers when using SSTP, adding a certificate for
IKEv2 that was created by the same CA as an SSTP certificate means that no
client changes are needed.

2. If I keep my user and server key to a 2048-bit one it appears to be
fine.  But, if I try to use a 4096-bit certificate for either the machine
or the user's authentication the negotiation fails over anything but a
local network connection, and it appears the reason it fails is
fragmentation.  In short the keying never gets to the server and thus does
not complete.

There's an RFC for this and support on recent Strong swan releases but the
client has to ask for it during initial negotiation and the BB10 client
does not.  The result is that longer (and more-secure) keys won't work --
if you have either a 4096-bit server certificate or a 4096-bit user cert
the VPN will not come up.

 3. First, we have incompatibility between IPsec AH and NAT.   This   is
because   AH   header   incorporates   the   IP source   and
destination   addresses   in the keyed message integrity check and
therefore NAT will invalidate message integrity check by changing address
fields. This makes A unusable in the presence of NAT devices. ESP doesn't
have this problem because it doesn't incorporate the IP header inits keyed
message integrity check, so changes in IP header will not conflict with
ESP's integrity protection.

A more serious problem that affects both AH and ESP is incompatibility
between   transport   layer   checksums   and NAT. This problem occurs with
AH and ESP in transport mode.   Namely,   TCP   and   UDP   checksums
depend   on source and destination addresses and ports because of their
inclusion   in   "pseudo-header"   during   transport   protocol checksum
calculations and verifications. When a NAT box changes source and/or
destination address/port it can-not change the checksum since it's
protected by either or both ESP and AH. The partial solution is to use ESP
in tunnel mode, but in this case inner IP address, protected by NAT, is
visible to the node.

There is also incompatibility between IKEv2 address identifiers   and
NAT.   Some   phases   of   IKEv2   use   IP addresses as identifiers.
Modification of these addresses through NAT will cause mismatch between
identifiers and the addresses in the IP header. The solution to this
problem might   be   the   use   of   user   IDs   or   FQDNs   that   are
independent of IP addresses. IKE   protocol   requires   use   of   fixed
source   and destination   ports.   This   also   causes   incompatibility
with NAT. One possible scenario that might cause problems is when multiple
hosts behind the NAT (NAPT to be precise) initiate IKE SAs to the same
responder. Mechanism is needed to allow the NAPT to DE multiplex the
incoming IKE   packets   from   responder.   This   is   typically
accomplished by translating the IKE UDP source port on outbound   packets
from   initiator.   Because   of   that responders   must   be   able
to   accept   IKE   traffic   from   a various  source  ports   (other
than  500   on  which  is  IKE running), and must reply to that port. The
somewhat similar problem, but in it's own category, are the
incompatibilities between overlapping SPD entries when using NAT.   There
are situations when responder could send packets down the wrong IPsec SA
because of overlapping   SPD   entries.   This   could   happen   when
initiating hosts behind NAT use their source IP addresses in Phase 2
identifiers. Another problem between ESP  and NAT   lies  in  thein
compatibility   between   IPsec   SPI   selection   and   NAT. Since IPsec
ESP traffic is encrypted, only way for NATs to know how to demultiplex
incoming packets is to inspect information’s in the IP and ESP header.
These information’s are usually destination IP address, IPsec SPI and
security protocol (every SA is uniquely determined by this three elements).
Because of independent selection of incoming and outgoing SPIs it is
possible that the NAT will deliver the incoming IPsec packets to the wrong
place when two hosts behind the NAT attempt to create IPsec SAs at the same
destination simultaneously. Namely, this destination could choose same SPIs
and there is no way for NAT to know to which SA belong   incoming packets
from this destination. Thus, NAT neither knows where to deliver these
incoming packets. Technique that can alleviate this problem is that
receiving host (the one who generated same SPIs in our case) allocate a
unique SPI to each unicast SA. We have already mentioned that protocols who
embed IP   address   within   payload   have   a   problem   with   NAT
boxes. IPsec and its protocols aren't exception – payload could be
integrity protected and NAT couldn't translate IP addresses   embedded
within   payload.   Solution   for   this problem is to install ALGs
(Application Layer Gateways)on the host or security gateway. These ALGs
should have a possibility of operating on application traffic before IP sec
encapsulation and after IPsec decapsulation the NAT provides IPv6   nodes
with   specific   IPv6   prefix.   This prefix is retrieved from the NAT
external IPv4 address.  A part from providing the prefix, NAT also
encapsulates IPv6 packets in IPv4 for transport to other 6to4 nodes or
relays. This method   gives   a   possibility   for   communication
without problems between an IPv6 node  using IPsec and  other nodes inside
the IPv6 or 6 to 4 area.
Unfortunately, 6to4 is not universally usable. It is an appropriate
solution where a single NAT separates a client and the VPN gateway but it
cannot be used where multiple NATs   are   deployed   between   client   and
VPN   gateway. Reason for this is that forming of mentioned IPv6 prefix
requires the assignment of a routable IPv4 address to the NAT. Peers that
support IPv6 need a little upgrade to be 6to4compatible,   while   NATs
require   many   extensions   to support 6 to 4.

On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) <
[email-masked]> wrote:

> All:
>
> With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe
> the draft is shaping up nicely, but needs additional review. To that end,
> this message starts a Working Group Last Call (WGLC) for
> draft-ietf-ipsecme-ddos-protection-04.
>
> The version to be reviewed is
> https://tools.ietf.org/id/draft-ietf-ipsecme-ddos-protection-04.txt.
>
> Please send your comments, questions, and edit proposals to the WG mail
> list until March 18, 2015.  If you believe that the document is ready to be
> submitted to the IESG for consideration as a Standards Track RFC please
> send a short message stating this.
>
> Best Regards,
> Dave
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

-- 
Best Regards

Dr. Karan Verma
Assistant Professor
Computer Science and Engineering Dept.
Central University Rajasthan, India
Website: www.drkaranverma.com
Phone: +917568169258

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 Mar 2016 10:15:51 -0500 (EST)

On Fri, 4 Mar 2016, Dr. Karan Verma wrote:

[ Did this go way of-topic? This does not relate to DDOS at all? ]

> 1. The root CA certificate corresponding to the server certificate must be installed on the client computers in the
> Trusted Root Certification Authorities per-computer certificate store. The client computer must be able to validate
> the server certificate as being signed by a trusted root CA.

Unless other AUTH mechanisms are used?

> 2. If I keep my user and server key to a 2048-bit one it appears to be fine.

You are lucky. 2048 bit certificates regularly cause fragmentation.

> There's an RFC for this and support on recent Strong swan releases but the client has to ask for it during initial
> negotiation and the BB10 client does not.  The result is that longer (and more-secure) keys won't work -- if you have
> either a 4096-bit server certificate or a 4096-bit user cert the VPN will not come up.

Yes, strongswan, libreswan and even iOS I think support fragmentation for IKEv2.

>  3. First, we have incompatibility between IPsec AH and NAT.   This   is   because   AH   header   incorporates  
> the   IP source   and   destination   addresses   in the keyed message integrity check and therefore NAT will
> invalidate message integrity check by changing address fields. This makes A unusable in the presence of NAT devices.
> ESP doesn't have this problem because it doesn't incorporate the IP header inits keyed message integrity check, so
> changes in IP header will not conflict with ESP's integrity protection.

You should not use AH. Use ESP_NULL instead in Tunnel Mode.

> A more serious problem that affects both AH and ESP is incompatibility between   transport   layer   checksums   and
> NAT. This problem occurs with AH and ESP in transport mode.

Don't use Transport Mode. The few bytes gained are not worth the hassle.

> There is also incompatibility between IKEv2 address identifiers   and   NAT.   Some   phases   of   IKEv2   use   IP
> addresses as identifiers. Modification of these addresses through NAT will cause mismatch between identifiers and the
> addresses in the IP header. The solution to this problem might   be   the   use   of   user   IDs   or   FQDNs  
> that   are independent of IP addresses.

I dont understand this at all. For any incoming IKE request that is not
an IKE_INIT request, you have the SPI numbers that uniquely identify the
IKE SA to match. In IKE_AUTH you are told the AUTH method to use, which
can be anything. Outside of IKE_INIT and IKE_AUTH you are already
authenticated and have your SPI's to match your connection.

> IKE   protocol   requires   use   of   fixed   source   and destination  
> ports.   This   also   causes   incompatibility with NAT. One possible scenario that might cause problems is when
> multiple hosts behind the NAT (NAPT to be precise) initiate IKE SAs to the same responder. Mechanism is needed to
> allow the NAPT to DE multiplex the incoming IKE   packets   from   responder.

The NAT box will assign a different outgoing port for the second client
trying to use port 4500 as outgoing source port. There is no problem.

>   This   is   typically accomplished by
> translating the IKE UDP source port on outbound   packets   from   initiator.   Because   of   that responders  
> must   be   able   to   accept   IKE   traffic   from   a various  source  ports   (other  than  500   on  which  is 
> IKE running)

You are mixing up source port and destination port here. IKE daemons
only need to listen on port 500 and 4500. And they should accept any
port for the incoming IKE packets.

> , and must reply to that port. The somewhat similar problem, but in it's own category, are the
> incompatibilities between overlapping SPD entries when using NAT.

We have a draft for that we will be updating soon. But you can also work
locally on this. For example on linux you can add MARKing to the packet
and have two identical SPD's that only differ by the mark. That means
you can receive and reply conflicting SPDs fine, except you cannot
initiate traffic to one specific SPD unless you manually mark your
packet.

>   There are situations when responder could send
> packets down the wrong IPsec SA because of overlapping   SPD   entries.

That would be an implementation bug.

   This   could   happen   when initiating
> hosts behind NAT use their source IP addresses in Phase 2 identifiers.

I think you refer to two machines on 192.168.1.1 behind two different
NAT routers? There should not be a problem but again you will need to
use our natt draft lik approach or MARKing of some kind.

  Another problem between ESP  and NAT   lies 
> in  thein compatibility   between   IPsec   SPI   selection   and   NAT. Since IPsec ESP traffic is encrypted, only
> way for NATs to know how to demultiplex incoming packets is to inspect information’s in the IP and ESP header. These

NAT's don't need to demultiplex anything. They just need to conntrack
the local IP's and ports they assigned, and return reply traffic
appropriately. This has no relation whatsoever to the packets. Of
course this uses ESPinUDP.

> information’s are usually destination IP address, IPsec SPI and security protocol (every SA is uniquely determined by
> this three elements). Because of independent selection of incoming and outgoing SPIs it is possible that the NAT will
> deliver the incoming IPsec packets to the wrong place when two hosts behind the NAT attempt to create IPsec SAs at the

No that is not possible unless you have a broken implementation.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 Mar 2016 10:29:15 -0500 (EST)

> On Tue, Mar 1, 2016 at 9:03 PM, Waltermire, David A. (Fed) <[email-masked]> wrote:
>       All:
>
>       With the draft-ietf-ipsecme-ddos-protection-04 freshly minted, I believe the draft is shaping up nicely,
>       but needs additional review. To that end, this message starts a Working Group Last Call (WGLC) for
>       Please send your comments, questions, and edit proposals to the WG mail list until March 18, 2015.  If you
>       believe that the document is ready to be submitted to the IESG for consideration as a Standards Track RFC
>       please send a short message stating this.

I think the document is well written with respect to DDOS. I like
everything except the puzzles. It seems a lot of complexity for
no gain, especially with the problem being that botnets are better
at puzzle solving then mobile phones who want to not drain their
batteries. I would prefer this document to proceed without the
puzzles, but I won't object to it if it remains in the document.
As an implementor, it would be extremely unlikely that I would
implement puzzles.

Recently, I also thought about amplification attacks, which is not
covered by the document. For instance, legitimate clients could pad
their IKE_INIT Request as a way to tell the responder they are not just
using the responder to amplify a DDOS attack. I am thinking of making
that the default for some Opportunistic IPsec so it cannot be abused for
amplification. I'd like to see that added to the draft if possible. Or
if this document would not proceed, I would be tempted to write a draft
for this idea.

Paul

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 04 Mar 2016 09:02:02 -0800

Hello Dave,

I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will choose to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones will be able to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption necessary. That being said, the document does a very good job of explaining the problem space, and the other parts of its solution (rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a responder can best protect itself if indeed the majority of its clients do not support puzzles?

One question on section 7.1.2:

If the received message contains a PUZZLE notification and doesn't
   contain a COOKIE notification, then this message is malformed because
   it requests to solve the puzzle, but doesn't provide enough
   information to do it.  In this case the Initiator SHOULD resend
   IKE_SA_INIT request.  If this situation repeats several times, then
   it means that something is wrong and the IKE SA cannot be
   established.

I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more traffic to the responder. The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be invalid. If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some malicious third party is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be in vain; in the second case, we have provided a way for a third party to cause initiators to send more traffic to the responder, thus providing an attack vector. What are your thoughts on this?

Thanks,
Tommy

> On Mar 4, 2016, at 7:29 AM, Paul Wouters <[email-masked]> wrote:
>

---

From: Yoav Nir <[email-masked]>
Date: Fri, 4 Mar 2016 19:32:54 +0200

> On 4 Mar 2016, at 7:02 PM, Tommy Pauly <[email-masked]> wrote:
> 
> Hello Dave,
> 

A proper responder would not send a malformed packet. An attacker could send a malformed response immediately after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost state. 

That is why it is always a good idea (not just in this context) for the initiator to ignore malformed responses until the timeout is reached.

Yoav

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 04 Mar 2016 10:03:47 -0800

> On Mar 4, 2016, at 9:32 AM, Yoav Nir <[email-masked]> wrote:
> 
>> 

That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to the malformed packet. Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately retrying the packet. It may be useful to clarify this in the text.

Thanks,
Tommy

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 5 Mar 2016 13:00:54 +0300

Hi Tommy,

thank you for your comments.

>>> I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will 
>>> choose
>>> to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones 
>>> will be able
>>> to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption 
>>> necessary.
>>> That being said, the document does a very good job of explaining the problem space, and the other parts of its 
>>> solution
>>> (rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a 
>>> responder
>>> can best protect itself if indeed the majority of its clients do not support puzzles?

Sections 4 - 6 describe measures other than puzzles that the responder can use to defend itself against DDoS attack.
Do you think it is not enough? Puzzles are a new thing, that's why more text is needed to explain how they are fit
into the protocol. However the draft is not solely about puzzles, and I think it covers other defending techniques in 
sufficient details.

>>> I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more 
>>> traffic to the responder.
>>> The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be 
>>> invalid.
>>> If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some 
>>> malicious third party
>>> is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be 
>>> in vain;
>>> in the second case, we have provided a way for a third party to cause initiators to send more traffic to the 
>>> responder,
>>> thus providing an attack vector. What are your thoughts on this?
>>>
>> A proper responder would not send a malformed packet. An attacker could send a malformed response immediately
>> after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost 
>> state.
>>
> That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to 
> the malformed packet.
> Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately 
> retrying the packet.
> It may be useful to clarify this in the text.

You are right that the Initiator should wait for the retransission timer to expire before resending message.
I agree that the wording is ambiguous about that. How about the following?

   If the received message contains a PUZZLE notification and doesn't
   contain a COOKIE notification, then this message is malformed because
   it requests to solve the puzzle, but doesn't provide enough
   information to do it.  In this case the Initiator MUST ignore
   the received message and continue to wait until either the valid one
   is received or the retransmission timer fires. If it fails to receive the valid
   message after several retransmissions of IKE_SA_INIT request, then
   it means that something is wrong and the IKE SA cannot be established.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 5 Mar 2016 13:34:49 +0300

Hi Paul,

> As an implementor, it would be extremely unlikely that I would

I agree that puzzles is a controversal thing. However currently we have no
better idea how at least to try to defend against powerful botnets. If you can
come up with such an idea, you are very welcome.

(W.Churchill said that democracy is the worst form of government,
except all those others that have been tried. [1]
I think that's a good analogy for puzzles.)

And note, that the way puzzles are used in the draft makes every
attempt to not discriminate those initiators that don't support puzzles
or cannot afford enough power to solve them. In other words -
puzzles mechanism in the draft is not an absolute barrier for
unsupported clients, it is just a first-class ticket for those who support and afford.

> if this document would not proceed, I would be tempted to write a draft

Could you, please, elaborate what scenario do you have in mind?

Regards,
Valery.

[1] 
http://www.academia.edu/1877336/_It_has_been_said_that_democracy_is_the_worst_form_of_government_except_all_those_others_that_have_been_tried_Winston_Churchill

---

From: Paul Wouters <[email-masked]>
Date: Sat, 5 Mar 2016 06:32:49 -0500 (EST)

On Sat, 5 Mar 2016, Valery Smyslov wrote:

> better idea how at least to try to defend against powerful botnets. If you 
> can come up with such an idea, you are very welcome.

If there is no consensus about puzzles, perhaps we should leave that
part out of the document?

> unsupported clients, it is just a first-class ticket for those who support 

which is the botnet more than mobile phones. Which is why I don't see I
would implement this. It seems session resumption would be more
effective at distinguishing returning clients from a botnet.

> Could you, please, elaborate what scenario do you have in mind?

If you have an IPsec server willing to talk IKE/IPsec to anonymous
clients. So one-side AUTH_NULL, the other a real authentication. Since
the server talks to everyone who sends it an IKE_INIT, it is important
that this IKE_INIT reply is much smaller than the IKE_INIT request,
so this does not become a new amplification target. Currently, such
a server could only always require dcookies to accomplish this, but
that takes an additional round trip. Some kind of padding in the
IKE_INIT request could easilly prevent this.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 5 Mar 2016 16:11:21 +0300

> part out of the document?

I had an impression that threre was a consensus when
the document was adopted by WG. In any case, I think that 
it is better to have an interoperable specification 
than to leave puzzles at all (and thus make them a subject
for a proprietary solutions).

> effective at distinguishing returning clients from a botnet.

Sure. But before every client becomes a "returning" one it must pass 
usual IKE_SA_INIT. And it cannot be a returning client the rest of its
life - it must be fully reauthenticated from time to time.
Thus the resumption cannot make the task of DDoS protection in 
IKE_SA_INIT non-existent.

> the server talks to everyone who sends it an IKE_INIT, 

How it is concerned with AUTH_NULL? In IKE_SA_INIT the responder
doesn't yet know that the initiator will use NULL auth or real auth, so 
any server usually replies to everyone who sends IKE_SA_INIT request.

> it is important
> so this does not become a new amplification target. 

IKE_SA_INIT reply in most cases is smaller than request.
The responder returns only a subset of initiator's SA transforms, 
a subset of initiator's  notifications (returning only supported ones),
and usually only a subset of VIDs.
In which real life scenario it is larger than request?

> Currently, such

Sorry, I failed to understand how additional padding would work.
Are you going to reject initiators that don't include this additional padding
(i.e. - all usual IKEv2 clients)? Am I missing something?

Regards,
Valery.

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 05 Mar 2016 17:38:24 -0800

Hi Valery,

Responses inline.

Thanks!
Tommy

> On Mar 5, 2016, at 2:00 AM, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Tommy,
> 
>>>> I tend to agree with Paul that I find it unlikely, from an implementor’s standpoint, that many Initiators will choose
>>>> to implement the puzzle logic, especially ones that are running on mobile devices. It is unlikely that the phones will be able
>>>> to solve the puzzles quickly enough to beat out botnets, and it would be hard to justify the battery consumption necessary.
>>>> That being said, the document does a very good job of explaining the problem space, and the other parts of its solution
>>>> (rate-limiting and suggesting session resumption) make good sense. Perhaps there can be more focus on how a responder
> into the protocol. However the draft is not solely about puzzles, and I think it covers other defending techniques in sufficient details.

Perhaps it would be useful to rearrange the sections to highlight this more clearly. The first section about a solution is Puzzles (section 3), followed by sections 4-6 which cover other aspects of DDoS avoidance strategies, which is then followed by an in-depth explanation of the Puzzles in the protocol (sections 7-9). Since the other aspects and sandwiched in between sections purely focused on puzzles, the draft really feels like it is about puzzles. What if the other approaches were moved before the first puzzles section, so the entire section on puzzles can be contiguous?

>>>> I am concerned that the suggestion for the initiator reacting to malformed IKE_SA_INIT packets is to send more traffic to the responder.
>>>> The responder should not legitimately send a PUZZLE notification without a COOKIE notification, since this would be invalid.
>>>> If the initiator sees this, it can either assume that (a) the responder’s implementation is out of spec, or (b) some malicious third party
>>>> is deliberately modifying the unencrypted packet. In the first case, trying to send the IKE_SA_INIT again would be in vain;
>>>> in the second case, we have provided a way for a third party to cause initiators to send more traffic to the responder,
>>> after the initiator sends the request. By the time the initiator gets the real responder’s response, it has lost state.
>>> 
>> That makes sense. The wording, however, could imply that the Initiator should resend the request as if in response to the malformed packet.
>> Based on your comment, the Initiator should wait for the usual amount of time before retrying, rather than immediately retrying the packet.

I think that is more clear, thanks!

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 05 Mar 2016 17:49:35 -0800

> On Mar 5, 2016, at 5:11 AM, Valery Smyslov <[email-masked]> wrote:
> 
> the document was adopted by WG. In any case, I think that it is better to have an interoperable specification than to leave puzzles at all (and thus make them a subject

I agree that interoperability is key, and having a definition is useful if anyone will be implementing it. 

> Sure. But before every client becomes a "returning" one it must pass usual IKE_SA_INIT. And it cannot be a returning client the rest of its
> Thus the resumption cannot make the task of DDoS protection in IKE_SA_INIT non-existent.

Going along with Paul’s point, it does seem that the approach of session resumption would favor the legitimate mobile-device client, where the puzzle approach may unintentionally favor the botnets themselves. But it is also a good point that session resumption alone cannot solve the DDoS problem.

Would it be possible, I wonder, to try to combine these approaches to create a solution that has the responder-protecting properties of puzzles, while still favoring legitimate clients? This would require using some property of legitimate clients (who will be able to successfully authenticate later in the negotiation) as part of the puzzle-challenge, or a way to skew the results in their favor. I’m not sure if this is possible from the algorithmic perspective, but it would be interesting to use some pre-known value (a shared secret, an initiator or responder ID, etc) as a key to the puzzle that, if known, would allow a quicker solution. It should be impossible to tell what this original key or salt is from an eavesdropper’s perspective, but it could make the calculation quicker for a client with a weak processor that was correctly provisioned to communicate with the server.

Thanks,
Tommy

> doesn't yet know that the initiator will use NULL auth or real auth, so any server usually replies to everyone who sends IKE_SA_INIT request.
> 
>> it is important
> The responder returns only a subset of initiator's SA transforms, a subset of initiator's  notifications (returning only supported ones),

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Sun, 6 Mar 2016 15:28:02 +0000

Hi

The only case I could imagine that this could occur is if the Initiators
Nonce and KE were purposely made very small and the Initiator did not
perform any validation on this, sending it¹s own reply where the KE and
Nonce were considerably larger.

I¹ve seen an amplification attack, where an implementation (as a
responder) would reply to a SA_INIT. If the responder did not receive a
reply to its SA_INIT it would re-transmit either 3 or 5 times (can¹t
remember exactly). (this seemed to not conform to 2.1 retransmission
timers..

cheers

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Mar 2016 19:09:46 +0200

> On 6 Mar 2016, at 5:28 PM, Graham Bartlett (grbartle) <[email-masked]> wrote:
> 
> Hi
> 

It doesn’t conform.  I think this was more common in IKEv1, but I’m not sure why. Maybe because of the need to store a larger state for Main Mode.

In IKEv2 a Responder should only reply once, but store the reply for retransmission in case the request is received again.

IMHO even in that case this is not an interesting attack. We should be worried about amplification attacks where little traffic causes a lot of traffic, not a case where I send a 200-byte packet which results in a 250-byte packet, and not even a 5 250-byte packets. Sending a request and directing a server to send an entire movie in 4K quality using RTP in an interesting amplification attack. Using a 10-Mbps uplink to generate 12-Mbps of traffic is not.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Mar 2016 19:16:45 +0200

> On 4 Mar 2016, at 5:29 PM, Paul Wouters <[email-masked]> wrote:
> 
> batteries.

I wish we had better numbers on the actual power of mobile phones. It’s all a question of how many times they can perform PRF-HMAC-SHA256 per second. Tommy?

Regardless, FWIW I (with implementer hat on) would implement DDoS puzzles. As the draft suggests, they would be used selectively and only as a last resort. I also think that if we had IPsec everywhere as Paul would like, DDoS attacks on IKE responders (which is basically all of the Internet) would become much more attractive. As it is, with IPsec-based remote access the VPN gateway is an attractive target, so we should have more aggressive methods in our arsenal.

Yoav

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Sun, 6 Mar 2016 19:12:16 +0000

With my hat off, I like the idea of reorganizing the puzzle oriented content in the draft to after the current section 4-6 content. IMHO, I think this could improve the flow and organization of the document.

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Saturday, March 05, 2016 8:38 PM
> To: Valery Smyslov <[email-masked]>
> Cc: Yoav Nir <[email-masked]>; [email-masked]; Paul Wouters
> <[email-masked]>; Waltermire, David A. (Fed) <[email-masked]>
> Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04
> 
> Hi Valery,
> 
> Responses inline.
> 
> Thanks!
> Tommy
> 
> >>>> I tend to agree with Paul that I find it unlikely, from an
> >>>> implementor’s standpoint, that many Initiators will choose to
> >>>> implement the puzzle logic, especially ones that are running on mobile
> devices. It is unlikely that the phones will be able to solve the puzzles quickly
> enough to beat out botnets, and it would be hard to justify the battery
> consumption necessary.
> >>>> That being said, the document does a very good job of explaining
> >>>> the problem space, and the other parts of its solution
> >>>> (rate-limiting and suggesting session resumption) make good sense.
> Perhaps there can be more focus on how a responder can best protect itself
> if indeed the majority of its clients do not support puzzles?
> >
> > Sections 4 - 6 describe measures other than puzzles that the responder can
> use to defend itself against DDoS attack.
> > Do you think it is not enough? Puzzles are a new thing, that's why
> > more text is needed to explain how they are fit into the protocol. However
> the draft is not solely about puzzles, and I think it covers other defending
> techniques in sufficient details.
> 
> Perhaps it would be useful to rearrange the sections to highlight this more
> clearly. The first section about a solution is Puzzles (section 3), followed by
> sections 4-6 which cover other aspects of DDoS avoidance strategies, which is
> then followed by an in-depth explanation of the Puzzles in the protocol
> (sections 7-9). Since the other aspects and sandwiched in between sections
> purely focused on puzzles, the draft really feels like it is about puzzles. What
> if the other approaches were moved before the first puzzles section, so the
> entire section on puzzles can be contiguous?
> 
> >
> >>>> contain a COOKIE notification, then this message is malformed
> >>>> because it requests to solve the puzzle, but doesn't provide enough
> >>>> I am concerned that the suggestion for the initiator reacting to
> malformed IKE_SA_INIT packets is to send more traffic to the responder.
> >>>> The responder should not legitimately send a PUZZLE notification
> without a COOKIE notification, since this would be invalid.
> >>>> If the initiator sees this, it can either assume that (a) the
> >>>> responder’s implementation is out of spec, or (b) some malicious
> >>>> third party is deliberately modifying the unencrypted packet. In
> >>>> the first case, trying to send the IKE_SA_INIT again would be in vain; in
> the second case, we have provided a way for a third party to cause initiators
> to send more traffic to the responder, thus providing an attack vector. What
> are your thoughts on this?
> >>>>
> >>> A proper responder would not send a malformed packet. An attacker
> >>> could send a malformed response immediately after the initiator sends
> the request. By the time the initiator gets the real responder’s response, it
> has lost state.
> >>>
> >>> That is why it is always a good idea (not just in this context) for the
> initiator to ignore malformed responses until the timeout is reached.
> >>>
> >> That makes sense. The wording, however, could imply that the Initiator
> should resend the request as if in response to the malformed packet.
> >> Based on your comment, the Initiator should wait for the usual amount of
> time before retrying, rather than immediately retrying the packet.
> > information to do it.  In this case the Initiator MUST ignore  the
> > received message and continue to wait until either the valid one  is
> > received or the retransmission timer fires. If it fails to receive the
> > valid  message after several retransmissions of IKE_SA_INIT request,
> > then  it means that something is wrong and the IKE SA cannot be
> established.
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Mar 2016 15:44:29 +0200

> part out of the document?

I think it is good thing to have puzzles in there, even if we do not
enable them now. 

> effective at distinguishing returning clients from a botnet.

I think it is good idea to have the puzzles already defined, so if
this really comes a problem and puzzles are needed, we already have
solution for that in the specification, we simply need to roll on the
new implementations :-)

I would hope server side gatways would implement those, but most
likely they would only be enabled when someone is really under big
attack.

Also modern mobile phones do have more power than home area switches,
adsl routers, coffee pots and other internet of target devices. Those
very low end devices have so little cpu power that people do not even
care if they are protected or not, and generating huge botnets of them
might be way to make DDoS attacks.

Also even the desktop and laptops do not have that much more raw cpu
power than modern mobile phones. Yes, doing puzzles do consume also
energy on phones, but you simply need to do it once, and then you are
through. Botnets need to use cpu power all the time to beat you.

I.e. phone should be willing to use few seconds of full cpu power to
create the VPN tunnel and then keep it up and running for the whole
day. 

> IKE_INIT request could easilly prevent this.

IKI_SA_INIT response and IKE_SA_INIT request are almost the same size,
I do not think there is need for padding. 

The SAr1 will always be subset of SAi1, i.e., it is either same size
or smaller. The KEr is same size as KEr. Nr can be selected so that it
is same size as Ni, so there is no difference. Only thing that is in
the response which is not in the request is the CERTREQ if you are
using certificate based authentication, and that is few tens of bytes
(unless you have large number of CAs).

On the other hand request also usually have different notifications
indicating features etc, and in most cases those notifications are
only included in response only if they were also in the request.

You do might want to limit of sending lots of different vendor IDs in
the server, as those might make the packet bigger...

IKEv1 is much different in this case, as if client sends one packet to
server, the server will then reply back and will most likely
retransmit its response back until it gets next packet from client, or
until request times out, thus in IKEv1 it is easy to get amplification
factor of ten (if servers retry limit is for example 10).
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 8 Mar 2016 16:04:43 +0200

Yoav Nir writes:
> It doesn’t conform.  I think this was more common in IKEv1, but I’m
> not sure why. Maybe because of the need to store a larger state for
> Main Mode.

It was because IKEv1 did not specify request response pairs. Every
message was fire and forget message, and the sender of the mssage was
supposed to take care whether it reached the other end or not. See
section 5.1 of RFC2408:

----------------------------------------------------------------------
   When transmitting an ISAKMP message, the transmitting entity
   (initiator or responder) MUST do the following:

   1.  Set a timer and initialize a retry counter.

       NOTE: Implementations MUST NOT use a fixed timer.  Instead,
       transmission timer values should be adjusted dynamically based on
       measured round trip times.  In addition, successive
       retransmissions of the same packet should be separated by
       increasingly longer time intervals (e.g., exponential backoff).

   2.  If the timer expires, the ISAKMP message is resent and the retry
       counter is decremented.

   3.  If the retry counter reaches zero (0), the event, RETRY LIMIT
       REACHED, MAY be logged in the appropriate system audit file.

   4.  The ISAKMP protocol machine clears all states and returns to
       IDLE.
----------------------------------------------------------------------

> In IKEv2 a Responder should only reply once, but store the reply for
> retransmission in case the request is received again.

Yep. See section 2.1 of RFC7296.

> IMHO even in that case this is not an interesting attack. We should
> be worried about amplification attacks where little traffic causes a
> lot of traffic, not a case where I send a 200-byte packet which
> results in a 250-byte packet, and not even a 5 250-byte packets.
> Sending a request and directing a server to send an entire movie in
> 4K quality using RTP in an interesting amplification attack. Using a
> 10-Mbps uplink to generate 12-Mbps of traffic is not. 

The IKEv1 reflection attacks can be bad, as sending single packet, you
can generate 10 packets to be sent over several tens of seconds.
-- 
[email-masked]

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Tue, 8 Mar 2016 22:56:41 +0000

Hi

I¹ve updated the draft (attached). Please see section 6.2, where I
describe a method to (potentially) pull your movie in 4k quality..

cheers

On 06/03/2016 17:09, "Yoav Nir" <[email-masked]> wrote:

>Sending a request and directing a server to send an entire movie in 4K
>quality using RTP in an interesting amplification attack.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 9 Mar 2016 14:46:36 +0300

Hi Graham,

a few comments on your text.

   A number of attacks can occur if implementations use the HASH and
   URL, malicious parties can send a URL to redirect a VPN gateway to a
   server which does not contain the HASH of the certificate, but

The server never contains hash, it contains the certificate (or CertBundle)
matching the hash.

   instead contains a large file that is then downloaded by the VPN
   gateway consuming CPU and memory. For this reason the size of file
   pulled by the server SHOULD be limited to a certain value dictated by
   the policy for the issuing Certificate Authority. The VPN gateway

I'm not sure if CAs have such a policy (there is a BasicConstraints extension
in certificates, which is relevant, but not the same).

   Malicious or mis-configured clients can make numerous requests that
   exhaust the HTTP or TCP daemon running on the VPN gateway. The amount
   of requests that are performed in a given time should be monitored
   and rate limited should HTTP connections fail. The VPN gateway
   architecture should be designed so that the repository containing
   certificates is on the protected interface of the VPN gateway. This

Sorry, this is impossible (if by "protected interface" you mean
the interface protected by IPsec). That's a chicken-and-egg problem -
you need to get the certificate before the SA is established
(see Section 2 of RFC7296).

Generally speaking, I don't think the attack is so serious.
It is the IKE responder who retrieves data, so it is up to the responder
to decide how much data it retrieves. The malicious http server cannot send
more than one TCP window bytes unless the responder sends next ACK.
And I think that the sane responder would read the first few bytes
and determine the size of the whole ASN structure (certificate or CertBundle),
since all the structures are required to be DER-encoded.
And I agree with you that if the length is suspicious (e.g.
greater than 16 KBs, which is more than enough to hold
four certificates, the number - required to be supported by RFC7296),
then it can just abort the TCP session.

So I don's see it as an amplification attack that Yoav described -
it is not full 4K moovie unless the responder is absolutely careless.

Anyway, isn't the text better be placed in the Security Considerations section?

Regards,
Valery.

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Thu, 10 Mar 2016 07:07:43 +0000

(Resending as my 1st attempt didn’t seem to make it to the list..)

Hi Valery

>The server never contains hash, it contains the certificate (or

Thanks - sorry, I used the wrong terminology.

Just to confirm  - for the malicious case I setup my webserver
www.evilgraham.com, I send you HASH + URL

http://www.evilgraham.com/djfjkdfkdfkdfjfdj

(hash being 'djfjkdfkdfkdfjfdj')

there’s a file on my server named ‘djfjkdfkdfkdfjfdj’ (Yoav’s 4k movie..)

You now download this movie..

>in certificates, which is relevant, but not the same).

Sorry - I wasn’t clear. I was referring to security policy for the CA. So
say your CA issues certs with a RSA 2048bit keypair, you would know the
approx size of the certificates generated. You would know not to download
a cert bigger than X bytes. As I understand some certificate can become
very large (if containing images etc..), there’s no hard set limit on a
certifciate size, but
the ‘security policy' for the CA (what attributes are included would be
known), so an informed decision could be made to the size of the
certificates.

>(see Section 2 of RFC7296).

I don’t mean IPsec protected interface. Think LAN and WAN. So IKE/IPsec
comes into the WAN interface and then your protected networks are on your
LAN.

Maybe better terminology would have been Management, basically an
interface that isn’t internet (or WAN) facing and not accessible by the
IKE clients (so can’t be turned over). I’ll reword this, thanks for the
pointer.

>then it can just abort the TCP session.

But there’s also the case for someone getting the VPN gateway to connect
to a malicious HTTP server, even for the 16k limit they can drip feed the
file (very slow transfer). Do this a number of times and you could exhaust
all TCP sockets on the VPN gateway (maybe then preventing CRLs being
retried etc).

>it is not full 4K moovie unless the responder is absolutely careless.

Well - for those careless responders it’s 2 packets to the get the VPN
gateway to download the movie (200k+ packets etc…)

Seems like a nice amplification to me.

>Anyway, isn't the text better be placed in the Security Considerations

Sure - I can put it in there. I’ll tidy up the words to clear up the
confusion. Thanks for the comments Valery.

cheers

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Tue, 15 Mar 2016 15:25:58 +0000

Hi

Last night I noticed the following,

https://community.akamai.com/docs/DOC-5289

It talks of various results when using a single packet to generate an
amplification attack. (well worth a read..)

As we discussed last week, all implementations that send multiple replies
to a single SA_INIT would be broken in some form. Because of the impact of
this (and these shocking results), I¹d like to add the following words to
the security considerations around retransmissions with respect to
amplification attacks using SA_INIT / IKE_AUTH;

"As described in RFC7296 Use of Retransmission Timers. For every pair of
message it is the responsibility of the initiator to retransmit should a
message be lost. A responder MUST only send a single reply to an SA_INIT
or IKE_AUTH message and MUST never engage the retransmission mechanism,
even if a reply is not received. This mitigates the chances that a
response will become a victim of an amplification attack where a single
packet is used to generate multiple replies."

Thoughts?

cheers

On 06/03/2016 17:09, "Yoav Nir" <[email-masked]> wrote:

>IMHO even in that case this is not an interesting attack. We should be
>worried about amplification attacks where little traffic causes a lot of
>traffic, not a case where I send a 200-byte packet which results in a
>250-byte packet, and not even a 5 250-byte packets. Sending a request and
>directing a server to send an entire movie in 4K quality using RTP in an
>interesting amplification attack. Using a 10-Mbps uplink to generate
>12-Mbps of traffic is not.
>
>Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 15 Mar 2016 18:55:48 +0300

Hi Graham,

I don't think it is necessary, since RFC7296 already has
the requirement in Section 2.1:

   For every pair of IKE messages, the initiator is responsible for
   retransmission in the event of a timeout.  The responder MUST never
   retransmit a response unless it receives a retransmission of the
   request.

So, such implementations are obviously broken, and I don't
think we need to duplicate the RFC2119 requirements from IKEv2 spec.
If you think it's worth to emphasize this requirement, then, I think,
it  must be re-worded without using RFC2119 words,
and must refer to the RFC7296 as the source of requirement.
Something like that:

    To prevent amplification attacks the Responder must
    retransmit the response message only if it receives a
    retransmitted request from Initiator, and must not do it
    under any other circumstances. Note, that this behaviour
    is already prescribed in Section 2.1 of RFC7296.

Regards,
Valery.

----- Original Message ----- 
From: "Graham Bartlett (grbartle)" <[email-masked]>
To: "Yoav Nir" <[email-masked]>
Cc: "Valery Smyslov" <[email-masked]>; "Paul Wouters" <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 15, 2016 6:25 PM
Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-ddos-protection-04

Hi

this (and these shocking results), I№d like to add the following words to

Thoughts?

cheers

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Mar 2016 02:51:56 +0200

> amplification attack. (well worth a read..)

And it does NOT talk about IKEv2 at all. The whole text is only
covering IKEv1, even if they claim to cover both IKE and IKEv2.

RFC2048 is wrong RFC number, they mean RFC2408, and that ONLY covers
IKEv1. The IKEv2 RFC is the RFC 7296 and it clearly specifies
completely different transmission policy, i.e. it does not use what is
defined in the RFC2408.

This paper is just completely wrong and the conclusions for it is also
completely wrong for IKEv2.

It should really say that everybody simply should DISABLE IKEv1 and
only enable IKEv2 in their configuration and that should fix the issue.

The paper does not even have any kind of contact information, so there
is no way to send in comments to try to get them to understand that
their paper is completely wrong when related to the IKEv2.

> amplification attacks using SA_INIT / IKE_AUTH;

In their paper there was not asingle IKE_SA_INIT nor IKE_AUTH packets
sent. All the frames used Exchange Type of 2 (Identity Protect ==
IKEv1 Main Mode), not the Exchange types 32-37 (IKE_SA_INIT, IKE_AUTH
etc). 

> packet is used to generate multiple replies."

This requirement is already in the RFC7296 section 2.1, and there is
no point of say it again here. Even if we say it here, it does not
change the retransmissions for the IKEv1, as this draft does not cover
IKEv1.

What we could say in the DDoS draft is to add saying that IKEv1
protocol is obsoleted, and will be common avenue for the DDoS attacks,
and because of that it MUST be disabled.

Or perhaps we need the IKEv1 considered harmful draft /
ikev1-diediediediedie... 
-- 
[email-masked]

---

From: "Dr. Karan Verma" <[email-masked]>
Date: Wed, 16 Mar 2016 06:40:32 +0530

yes, it's right

+1

-- 
Best Regards

Dr. Karan Verma
Assistant Professor

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Wed, 16 Mar 2016 09:19:19 +0000

Hi Tero

There’s many references to IKEv2 in the paper. E.g.

"Figure 1: Zmap scan using our IKEv2 payload”..

I’ve managed to track the author down and made contact. I’ll sync you in
on a mail and hopefully we can verify what was exactly was used.

All I would ask is - if many IKEv2 implementation are vulnerable to an
amplification attack, I feel it would be prudent to add some words to
remind implementors of the risk.

cheers

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 08:27:44 -0400

> Or perhaps we need the IKEv1 considered harmful draft /

I don't think that will help. I've seen how reluctant people are to change their 10 year old working VPN. 

IKEv1 is dying pretty quickly now, thanks to mobile phones. But it will be another year or two. Right now,
a diediedie document won't help me remove or disable IKEv1 code.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Mar 2016 14:39:05 +0200

> On 16 Mar 2016, at 2:27 PM, Paul Wouters <[email-masked]> wrote:
> 
> 
>> 
> IKEv1 is dying pretty quickly now, thanks to mobile phones.

Really?  Granted, it’s been a couple of years since I’ve checked the VPN capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and XAuth (A Cisco extension to IKEv1). We have some people from Apple in the working group who are talking about IKEv2 on the phone, but I don’t think they’re removing the support for L2TP or XAuth.

Android IIRC also has the L2TP with IKEv1. Not sure what else.

Windows Mobile?  You can add your own, or you have the usual Windows PPTP, L2TP (again with IKEv1) and IKEv2.

Who’s killing IKEv1?

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 08:54:48 -0400

These are all backwards compatible things. The cool things are happening at IKEv2, and the management tools and required features will push users to v2. Sure static v1 site to site will remain in place until 3des or hmac-md5 is broken (and they'd still not upgrade)

Just make sure people don't implement support for tcp in v1 :)

Sent from my iPhone

> On Mar 16, 2016, at 08:39, Yoav Nir <[email-masked]> wrote:
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Mar 2016 09:23:02 -0400

> Or perhaps we need the IKEv1 considered harmful draft /

Yes, I would say so.

I'd even suggest that maybe it needs a CVE against products that have IKEv1
turned on by default.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 11:53:02 -0400 (EDT)

> I'd even suggest that maybe it needs a CVE against products that have IKEv1

No, because it is perfectly possible to implement IKEv1 without this
problem. Libreswan is moving towards that, see:

https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 11:55:35 -0400 (EDT)

> Really?  Granted, it’s been a couple of years since I’ve checked the VPN capabilities of an iPhone, but I remember it having L2TP (using IKEv1) and XAuth (A Cisco extension to IKEv1). We have some…

Apple is pretty aggressively pushing IKEv2 (Thanks Tommy!)

> Windows Mobile?  You can add your own, or you have the usual Windows PPTP, L2TP (again with IKEv1) and IKEv2.

What I meant was in the last two years, the switch has been to have
IKEv2 be the "current default VPN" and IKEv1 be the "legacy VPN".

Note Windows Mobile did not have PPTP or L2TP until a few months ago,
when they re-added it :(

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 16 Mar 2016 19:46:10 +0300

Hi Paul,

> https://lists.libreswan.org/pipermail/swan-dev/2016-March/001394.html

Making only the initiator be responsible for retransmissions is possible 
in the IKEv1 Main Mode. However, it is impossible in Aggressive Mode
(and in Quick Mode too, although it is irrelevant here).

The problem is that the last message comes from the initiator, and if this message
got lost, the initiator never knew about it it unless the responder retransmits the response
to the very first message from the initiator. It's an immanent feature of IKEv1
caused by odd number of messages in these exchanges. It can't be solved.

And besides the possibility of amplification attack, IKEv1 has so many 
problems, that the only reason it is still used is maintaining interoperability
with older products.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 12:55:27 -0400 (EDT)

On Wed, 16 Mar 2016, Valery Smyslov wrote:

> Making only the initiator be responsible for retransmissions is possible in 
> the IKEv1 Main Mode. However, it is impossible in Aggressive Mode

I'm confused? Why does it matter if the initial aggressive mode request
is lost or the initial aggresside mode response is lost? to the
initiator, both look the same, so it should re-transmit its original
packet?

> problems, that the only reason it is still used is maintaining 

It does have a cryptographically stronger PSK :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 16 Mar 2016 20:29:58 +0300

> initiator, both look the same, so it should re-transmit its original

Aggressive Mode (and Quick Mode) consist of 3 messages.
If the initial  message from initiator or (the response to it from responder) 
get lost, that initiator can detect it (it doesn't receive the response)
and retransmit its initial message. But once it receives
response it sends the third (the last) message to the responder.
At this point the exchange is successfully completed from initiator's
point of view (and from its point of view there is no reason to restransmit
that last message). However, if that last message get lost, then the 
exchange remains unfinished from responder's point of view.
The only thing the responder can do is to retransmit its response
to the initiator's initial message to force it to retransmit its last message.

In some cases workarounds are possible. For example,
the initiator may always retransmit its last message N times.
Another workaround is the following. In most cases Quic Mode
immediately follows Aggresive Mode. Since in case the last message
from initiator get lost the IKE SA is not created yet from responder's 
point of view, it most likely won't reply at all or will reply with some error 
like INVALID_MESSAGE_ID. So, no response or error response on initial 
Quick Mode message immediately followed the last Aggressive Mode 
message could be an indication for initiator that it must retransmit
not only that initial Quick Mode message, but also the last 
message of Aggressive Mode.

But these are plain hacks. If Aggressive Mode happens alone
(e.g. when user pressed CONNECT button), then the only way to deal
with the possibility of the last message from initiator to get lost is to make
a responder to retransmit its response to the initial message.

> It does have a cryptographically stronger PSK :)

That's true. However, it is almost impossible to use this feature
unless peers have fixed IP.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 13:42:15 -0400 (EDT)

> response it sends the third (the last) message to the responder.

I did not suggest not retransmitting this. I was ONLY talking about the
first response packet of any IKEv1 exchange. Once you receive the 2nd
packet on the responder, it has your SPI's so you know the source IP
was not spoofed and so you don't need to worry about amplification.

> with the possibility of the last message from initiator to get lost is to 
> make a responder to retransmit its response to the initial message.

I still do not see that:

   AggrOutI1   --->
               <----   AggrOutR1
      [ rest of exchange ]

If AggrOutI1 is dropped:

   AggrOutI1   ---> X
   AggrOutI1   --->
               <----   AggrOutR1
      [ rest of exchange ]

If AggrOutR1 is dropped:

   AggrOutI1   --->
             X <----   AggrOutR1
   AggrOutI1   --->
               <----   AggrOutR1
      [ rest of exchange ]

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 16 Mar 2016 20:50:15 +0300

>      [ rest of exchange ]

"rest of exchange" is most important thing here

   AggrOutI1   --->
               <----   AggrOutR1
   AggOutI2 ---> X

at this point initiator completed the exchange and has working IKE SA.
However, since AggOutI2 is lost, then responder doesn't have IKE SA yet.
Since initiator has ready IKE SA it has no reasons to retransmit AggOutI2.
The only way responder can force initiator to retransmit AggOutI2 is
to retransmit AggrOutR1:

   AggrOutI1   --->
               <----   AggrOutR1
   AggOutI2 ---> X
               <----   AggrOutR1
   AggOutI2 --->

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Mar 2016 16:29:07 -0400 (EDT)

[ on not sending retransmits in AggrOutR1 state ]

> The only way responder can force initiator to retransmit AggOutI2 is

I see. That is true. Some possible solutions to this:

1) Initiator can always send a DPD probe after 3s to confirm the IKE SA.

2) Initiator waits a few seconds and check if the IPsec SA received
    incoming traffic as something should have triggered the IKE SA.
    If not, either tear down IKE SA or do 1)

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 17 Mar 2016 02:59:11 +0200

> There’s many references to IKEv2 in the paper. E.g.

There is references to the IKEv2, but the paper is not talking about
the IKEv2. It is clear from the packet traces (see version number),
and the retransmission behavior seen.

In the IKEv2 the responder will NEVER retransmit the response unless
initiator retransmits its request (provided the implementation folows
what RFC mandates). 

> remind implementors of the risk.

I do not know any IKEv2 implementations that would be vulnerable to
this multiple responses attack, and if IKEv2 is implemented as
specified in the RFC7296, they are not vulnerable.

>From RFC7296:

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 17 Mar 2016 08:51:25 +0300

> 1) Initiator can always send a DPD probe after 3s to confirm the IKE SA.

Sure.

>    If not, either tear down IKE SA or do 1)

No, it'll work differently. To have IPsec SA the initiator must initiate Quick Mode
right after Phase I is completed. And the Quick Mode will fail since
the responder didn't complete Aggressive Mode exchange. 

But these workarounds just solve the "black hole" problem, so they
allow the initiator to detect, that the responder doesn't have an IKE SA.
Sometime it'll become evident for the initiator in any case, even
without DPD etc.

The problem with IKEv1 is that if the responder never retransmits
in Aggressive (and Quick) Mode, then the protocol becomes intolerable
to a single packet loss that makes it very unreliable. And it can't be solved.

Regards,
Valery.