Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

"Valery Smyslov" <svanru@gmail.com> Sun, 25 September 2016 20:20 UTC

Return-Path: <svanru@gmail.com>
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 4574612B01C; Sun, 25 Sep 2016 13:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.261
X-Spam-Level:
X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RgN8K6PFmmNG; Sun, 25 Sep 2016 13:20:17 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C003512B016; Sun, 25 Sep 2016 13:20:16 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id g62so125382143lfe.3; Sun, 25 Sep 2016 13:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-transfer-encoding:importance; bh=2q4sxxSFZcXqvWBlM5BkiCBVqYveQcVwpSjzRX8XOy8=; b=xv58uawxMR4T4Yi+rpT0t9ioaH9s61NJqPSCiFnxtfdt3PqFxKw4xZDHFFdns8zH/A TOo6vO1DDOXF7Xg7GTcDGox2IfYz05wIRbyFusroRl/U9ur7MzMzD0VMf2PAk+JkEgID b/NXE3BNzMiyXWxJMGrKCTIC4VuRdBxU0CRw9IfWjVxWROIiZ0pC1usIfkr0WWz4odu+ CTei7TAJPXrj6Qx3I1XY37245AcR8H4eSpAb63gKuuebLUiPRIGBDdsTDxW+xvy3iqnC 5pwpaZN5SidkKbZR+Tgj0ijawukjgSTBq8n0MfM7UuEiU6T+swftze9sGZkkSuxm+zJb YA3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=2q4sxxSFZcXqvWBlM5BkiCBVqYveQcVwpSjzRX8XOy8=; b=XD5ZdUkhLpx23CXlni58mxNiA2x5hCKqf4+2PpDTBvGCuwK2Jo2SrCBEBaKndWamP8 g48IO4uE1d+ft+FSNw3x6co7myhtYxS33TDiYLoqAYhuBYrIAZr1/SeOUOW3PWsN4ILS YbnOzkcuK60iHeP4cHpJotEacllK80MSsFXBf9sDDoxh2hxjfzMdIzIJnxm2w8+IaQkt 8s9uZHeHA/AwHIZrp8lWI0TmdLUHd68b5EQOhDBIzQQmY/k8iIl7UmeaWqIGooB0bSKX O8oARA5uT4Ik/kgCo9ez/dd666Cg+w0YYq8GuLOaXgVheLdNN8sIMtepmU83kzVa17/I wgUQ==
X-Gm-Message-State: AE9vXwPxCehsMrS9AHF9I/3n14OkJMBWk/1x+aGIls8vfqtWd0bENH+bB8mcv2tB8++CCQ==
X-Received: by 10.25.218.6 with SMTP id r6mr6826270lfg.111.1474834814426; Sun, 25 Sep 2016 13:20:14 -0700 (PDT)
Received: from chichi (ppp83-237-161-125.pppoe.mtu-net.ru. [83.237.161.125]) by smtp.gmail.com with ESMTPSA id a19sm498934lfa.19.2016.09.25.13.20.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 25 Sep 2016 13:20:13 -0700 (PDT)
Message-ID: <701DC5E23DC747588D7047D73A87D855@chichi>
From: Valery Smyslov <svanru@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Mirja Kuehlewind <ietf@kuehlewind.net>
References: <147465789941.20366.13358533684157949770.idtracker@ietfa.amsl.com> <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com>
In-Reply-To: <674D263A-4EF8-4F8A-8320-1224FABAD10C@gmail.com>
Date: Sun, 25 Sep 2016 23:20:12 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"; reply-type="original"
Content-Transfer-Encoding: 8bit
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/A0aeSkG4eEOzsZSqkgcbhvNbbjE>
Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-ddos-protection@ietf.org, The IESG <iesg@ietf.org>, David Waltermire <david.waltermire@nist.gov>
Subject: Re: [IPsec] Mirja Kühlewind's No Objection 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: Sun, 25 Sep 2016 20:20:19 -0000

Hi Mirja, Yoav,

I agree with Yoav's answers, just want to clarify a few things. See below
(I removed the comments where I have nothing to add to Yoav's answers).

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Some questions:
> >
> > 1) sec 7.1.2: If there is a puzzle but no cookie, maybe the initiator
> > should ignore it and try to send reply without the puzzle solution, as
> > there might be still a change to get served…? If it then received another
> > packet with puzzle it can still solve it and reply.
>
> A response that contains neither COOKIE nor INVALID_KE_PAYLOAD nor the regular payloads like SA is invalid according 
> to RFC 7296.
> That is one reason why we chose to keep the COOKIE notification and add a PUZZLE notification rather than put both 
> pieces of
> data in the new notification. A response with only PUZZLE and no COOKIE is invalid and should be treated as such.
> So after some (not specified anywhere) time, the Initiator should start a new IKE_SA_INIT exchange, hoping that this 
> time the
> Responder returns a valid response.

Actually, the Initiator sends requests, not responses. So, if the Initiator ignores
invalid response from the Responder, then the only thing it can do is to wait
some time and sends another request (or just retransmit the sent request in hope
that invalid response was from an attacker who wants to break IKE SA establishment).
If the situation doesn't improve (the Initiator continues to receive invalid responses),
then the Initator has nothing to do but give up.

I just want to emphasise that Mirja's suggestion (ignore invalid response) is exactly
what the draft suggests to do in this case, as Yoav correctly outlined. Isn't it clear enough from the
document? Should we add more clarifications?

> > 3) also sec 7.1.4: Does the following sentence really makes sense? How
> > doe the responser know? Maybe just remove it?
> > „The more time the Initiator spent solving the puzzles, the higher
> > priority it should receive.“
>
> The Responder cannot know. It can only assume based on the expected number of steps in finding a solution with a 
> certain number of trailing zero bits.

The Responder can also measure the time between the puzzle request and
the reception of puzzle solution (and the Responder can do this in a stateless manner).
Sure this measurment cannot be accurate, because it includes RTT, but it
can be used as additional input to the prioritizing algorithm (along
with puzzle difficulty and the number of times the puzzle was requested).
But in general the prioritizing algorithm is a local matter of Responder
and the draft doesn't mandatae it in any way.

> > 5) sec 7.2.2 says „If the IKE_SA_INIT response message contains the
> > PUZZLE notification and the Initiator supports puzzles, it MUST solve the
> > puzzle.“
> > Should this be „IKE_SA_AUTH“ here instead of „IKE_SA_INIT“?
> > Otherwise it contradicts sec 7.1.2 („The Initiator MAY ignore the PUZZLE
> > notification…“)
>
> Sure. Seems to be a typo.

No, that's not a typo. Note, that unlike IKE_SA_INIT exchange the IKE_AUTH exchange
cannot be restarted. So, if we want the puzzle solution to be in IKE_AUTH request
(that is sent by the Initiator), the puzzle must be given to the Initiator earlier,
i.e. in the preceding response from the Responder, i.e. in the IKE_SA_INIT response.
So the text is correct.

However, I understand Mirja's source of confusion - in IKEv2 there are
three different kinds of IKE_SA_INIT responses ("regular", COOKIE and
INVALID_KE_PAYLOAD) and unfortunately RFC7296 doesn't give them distinct
names - they all are IKE_SA_INIT response. So, there is no contradiction with
7.1.2, because 7.1.2 tells about IKE_SA_INIT response that contain COOKIE request
(and PUZZLE request), while 7.2.2 tells about "regular" IKE_SA_INIT response,
i.e. that contains SA, KE, NONCE payloads etc. So, while in the first case
the Initiator can ignore puzzle request (if PUZZLE is present in a response containing COOKIE)
and still have a chance to be served, in the second case it cannot ignore puzzle request
(when PUZZLE is present in a "regular" IKE_SA_INIT response).

Do you think it is not clear enough and more clarifications are needed?

Regards,
Valery.