Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

Valery Smyslov <svan@elvis.ru> Tue, 27 September 2016 19:09 UTC

Return-Path: <svan@elvis.ru>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF01412B255; Tue, 27 Sep 2016 12:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.777
X-Spam-Level:
X-Spam-Status: No, score=-3.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRo7MYyauY1V; Tue, 27 Sep 2016 12:09:16 -0700 (PDT)
Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6FD127077; Tue, 27 Sep 2016 12:09:16 -0700 (PDT)
Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from <svan@elvis.ru>) id 1boxj5-0000e2-MS; Tue, 27 Sep 2016 22:07:35 +0300
Received: from chichi (10.100.101.1) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 22:07:35 +0300
Message-ID: <4CD64EE0965C4CC7882942207906422F@chichi>
From: Valery Smyslov <svan@elvis.ru>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com>
In-Reply-To: <147499618776.4465.11672584634820556976.idtracker@ietfa.amsl.com>
Date: Tue, 27 Sep 2016 22:07:32 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/mdfP-HAlkEAMU6STJUPzwAg3nOg>
Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, david.waltermire@nist.gov
Subject: Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 19:09:21 -0000

Hi Stephen,

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> This is a nicely written document... thanks!

Thank you!

> - I vaguely recalled that puzzles and IPR rang a bell.  Did
> the WG consider [1]? If not, and if it helps, I'm fine with
> making a 3rd party declaration on that and last call could be
> done again. Or maybe there's a better way to handle it. Or
> maybe the WG considered it and are happy enough already that
> it's not relevant or about to expire or abandoned or
> something.  ("Not relevant" would puzzle me:-)
> 
>    [1] https://datatracker.ietf.org/ipr/417/

The WG didn't consider this particular IPR.

> - section 3: "if certificates are involved" - you could note
> here that involving certificates can introduce a network
> based delay (OCSP, CRLs etc) that's a little different from
> CPU consumption. (But it's a nit, and you do note a similar
> issue in 4.7.)

The network delay does not necessary take place
(OCSP is optional, CRL may be cached), while CPU consumption 
is unavoidable. 

> - 4.2: "ratelimits should be done based on either the /48 or
> /64" - would it be better to say "something between a /48 and
> a /64" maybe? Don't some ISPs assign things in-between?

This particular sentence was discussed by WG. 
I think that "either /48 or /64" was chosen for simplicity.

> - 4.4: Did you consider making the "4 keys" requirement tied
> to the PRF algorithm identifier? That would allow for a
> future where e.g. 6 keys are needed for the same PRF, if that
> were ever useful. (Without changing current implementations.)
> I guess you'd need a separate IANA registry that'd initially
> duplicate stuff in that case so maybe not worth doing. (And
> could be done later.)

Several puzzle solutions help reduce volatility of 
time needed to solve any given puzzle. I don't think
it is related to particular PRF, since any "good" PRF must 
generate pseudorandom result and finding a key for that result 
would always involve a fortune for the Initiator.
The fixed number of keys (4) is a compromise.
We considered setting it to larger value, say 16
(and it would make correlation between puzzle difficulty 
and the time needed to solve it more predictable), 
but it would increase IKE message size in initial exchange.
And it is a bad thing, since it increases the chances that 
the message exceeds MTU and is fragmented by IP,
with all negative consequences.

> - 7.1.1 - you don't clearly say if the cookie value here can
> be a new one or should be the same as one previously used (if
> one was previously used). That may just be my ignorance of
> IPsec cookies though, but I wondered if there are any cases
> where the initiator gets to work away on the puzzle ahead of
> time if the same cookie is used for multiple interactions.
> There's not much (or zero) of an improvement to the attack
> here, though maybe the attacker could more easily offload
> puzzle solving to someone else in that case?

In IKEv2 the cookie is usually generated by applying hash
function to Initiator's IP, SPI, nonce and some secret maintained
by Responder. Since the cookie must be stateless for the Responder,
it is not stored on the Responder (except for the secret,
which is global and is changed periodically). So, if the Initiator
uses the same IP, same SPIi and the same nonce, it will very likely
receive the same cookie until the secret is changed. However, it won't much 
help an attacker. Once the puzzle is solved and the attacker successfully creates
half-open SA on the Responder, it cannot use the same combination
of IP and SPI to create another one, because all the initial messages
with the same IP+SPI will be delivered to that half-open SA and discarded.

The attacker can however gain some benefits if he/she waits some time
until the half-open SA is expired on Responder and chooses the same SPI and nonce 
for the next connection request. He/she will receive the same puzzle
if the Responder doesn't change value of secret yet. Note that RFC7296 recommends
changing secret frequently if under attack (RFC7296, Section 2.6):

   The responder should change the value of <secret> frequently, especially
   if under attack.

I think we can add some words to the draft that will recommend
to generate cookie in such a manner, that the cookie is not repeated
even if the same IP, SPI and nonce are used by Initiator.

Thank you,
Valery Smyslov.