Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis

Valery Smyslov <smyslov.ietf@gmail.com> Tue, 11 January 2022 12:31 UTC

Return-Path: <smyslov.ietf@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 6D7CF3A0113 for <ipsec@ietfa.amsl.com>; Tue, 11 Jan 2022 04:31:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 83pvw8lmkKIM for <ipsec@ietfa.amsl.com>; Tue, 11 Jan 2022 04:31:10 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 39F2D3A0105 for <ipsec@ietf.org>; Tue, 11 Jan 2022 04:31:10 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id d3so29406090lfv.13 for <ipsec@ietf.org>; Tue, 11 Jan 2022 04:31:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=J0xrR+HkK810ZUnjh28zchUg66MFJkDMeUpq2rAP4WI=; b=d42GJLPt+B0iP9VTL7Ml8Kw5cW1w3cCurgArs6LAkKqZpEpef01kJzkrzX8DJEIUNG wTuMZLQgN/jigirTuDZtGg8XIQ9P7JBcV+C2s5d2ZwFSAto6ctgt1qglVgtVpN56Bys+ cWP1cXhqdxsO7Cxiec6STn8bjStoCFQM3kjHBMq6lqyCJzclqkttm1FkmqePthoVcWuh mj621fRwEnMBM7jq7qQ4zOO+spJI2FSTJzZI820yI9oEV+lfyYtBUPFw+Y7SkIi1ljTP 3Bt+Q+hvIxSxHpvSl+0atPwGGKLh306KN2fj+6wR/fmxCLsahib5Gwc92lBOYbHTXDGi 5QNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=J0xrR+HkK810ZUnjh28zchUg66MFJkDMeUpq2rAP4WI=; b=Z2vg9WuXnbuyxqVXz1pXec0Xiih1g9Y0jVHh3aHk9mfsYxXtcAFM66eFc1L7MQmIan ql1YpcOYjjA7ZIMmMwT6SSzEDyRuZy9rBS+Ln1ms97kZGS/lqDlrhjjTyfxbqQFf6KVt H6YkMHMzndK3eUb9lRCpHcUlOgsUMV+pxch8OnIm0Tw+y0P9M2iQLKoibHgu1MQUwPlu ALztHVtemtLRZ37i59KKB4ZE37YYlIPUczaOYzpGUuokHAVxK67IbT0OOTukaGiEmfBX 73B6kLI8OJOmYN1Wbz7DZ39pFEHxB68DVAr544NI2jNaOaMUEepZd6nGsGHku7DV6yA3 ottA==
X-Gm-Message-State: AOAM5312Lfw7c2pMTqYkwN9hd0OiacupeGHVfHq6Kpp4RTC+vrTFryuW rQmVj9ngyKfIfUZOwvmorb4CUBxAvoI=
X-Google-Smtp-Source: ABdhPJwWiFYZr3Q5fbofRzljRJxAj1m+16WwyxG+BH/oLNedUf/yhxGtwvPBxeLidDU9D7Ifwa1p0A==
X-Received: by 2002:a05:651c:154:: with SMTP id c20mr2730355ljd.448.1641904266811; Tue, 11 Jan 2022 04:31:06 -0800 (PST)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id f19sm1319641lfg.298.2022.01.11.04.31.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jan 2022 04:31:06 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Paul Wouters' <paul.wouters@aiven.io>
Cc: ipsec@ietf.org, 'Tommy Pauly' <tpauly@apple.com>
References: <acea85f6-1c72-3b79-a7f6-d4c234b9e7c@nohats.ca> <026601d80627$55c05970$01410c50$@gmail.com> <db1078ca-51ce-ad90-4869-6c7ae8cfe715@nohats.ca>
In-Reply-To: <db1078ca-51ce-ad90-4869-6c7ae8cfe715@nohats.ca>
Date: Tue, 11 Jan 2022 15:31:06 +0300
Message-ID: <02f401d806e7$1b5be950$5213bbf0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQINrN/IdsOuc0WzOJRkkxx4Plg45gI1M6jVAn97uTWrzMMDgA==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/eu4UQJlwLinTP8w_SS7TVlcWkp0>
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Jan 2022 12:31:12 -0000

Hi Paul,

> On Mon, 10 Jan 2022, Valery Smyslov wrote:
> 
> > The responder does use an existing TCP connection to reply,
> > but once it replies with cookie request, it should close this connection.
> > If it keeps this connection, then it keeps TCP state until the client
> > resends IKE_SA_INIT request (if ever) and thus thwarts the idea of being stateless.
> >
> > This is probably not so important for cookies, because the client
> > has already proved during TCP handshake, that its IP is a real IP address,
> > but it is more important in case of puzzles. But in both cases
> > I think that keeping responder stateless is a good idea.
> 
> Yes, stateless is good in those cases, but reality is we already used
> state to setup the TCP connection. So why drop all that state now. It is
> in a way too late for the "state creation savings". Instead, you are now
> creating _more_ work for a server that might be under a DoS attack.

I agree. That's why I added a clarification that TCP state SHOULD be closed
if no repeated requests are received within some short period of time.

> >> Additionally, a NAT router could give the client a different IP address
> >> for a new TCP stream, making the COOKIE invalid.
> >
> > Yes, it is possible and this situation is covered in the draft.
> > But if we choose between keeping the responder stateless and
> > the possibility of occasional failure of cookie verification,
> > I'd choose the former as more important.
> 
> I am choosing the other way around :)

That is that :-)

> > I think we can slightly change this recommendation:
> >
> >   o  if the Responder chooses to send Cookie request (possibly along
> >      with Puzzle request), then the TCP connection that the IKE_SA_INIT
> >      request message was received over SHOULD be closed after the Responder sends its reply
> >      and no repeated requests are received within some short period of time, so that the
> >      Responder remains stateless. Note that if this TCP connection is
> >      closed, the Responder MUST NOT include the Initiator's TCP port
> >      into the Cookie calculation (*), since the Cookie will be returned
> >      over a new TCP connection with a different port.
> >
> > Does it address your concern?
> 
> I don't really see much difference. If the attacker can setup a TCP
> session, surely it can write 15 lines of python to replay the cookie
> back as well. The question is really whether the responder under attack
> is better of not needing as many TCP 3way handshakes versus keeping some
> state. Since the document says to basically ignore cookies as much as
> possible, it seems inline to just keep the TCP connection.

It should be eventually closed in case the initiator
never comes back. So, the question is - what time we consider
appropriate for waiting the initiator's repeated request?
The text above specify it as "some short period of time"
and you may interpret it at your will. 

> >>  	Thus, in case of TCP encapsulation, an Initiator SHOULD NOT wait for
> >>  	additional messages in case it receives error notification from the
> >>  	Responder in the IKE_SA_INIT exchange.
> >>
> >> This is true, but the code handlling this might not be aware of the
> >> transport used. I'd rather see "an Initiator MAY skip the waiting time
> >> for additional messages" so that this advice becomes "a good idea" and
> >> not a "RFC violation" if not done.
> >
> > Hmm, I think that "SHOULD NOT wait" leaves you a possibility to wait
> > if you have good reasons for it, without being accused in "RFC violation" :-)
> >
> > I have no problems with MAY in general, but I think that it's better
> > to encourage implementers to make this optimization
> > (which MAY does not).
> 
> I'm looking at the damage here. There is again no good reason to tear
> down the TCP connection for an INVALID_KE, so why tell implementations
> to do that. Even if simple implementations might do that just because
> that's how they do it for UDP (kill entire exchange, start a fresh one)

This section is not about how you handle error notifications. It only tells that 
there is no reason to wait for another (probably good) response if
error notification is received, it never comes (unlike UDP, when it is possible).

How you handle error notification is out of scope of this section.

> But I'd like to see us re-using the same TCP when receiving INVALID_KE,
> even if it was only for the reduced latency of another 3way handshake.

You may do it and by no means the draft suggests the opposite.
Tearing down TCP is only advised in case of COOKIE (or PUZZLE)
to keep the statelessness of the responder. And only if 
the client didn't immediately repeat its request.

> >>  	Implementations that implement
> >>  	both MOBIKE and TCP encapsulation MUST support dynamically enabling
> >>  	and disabling TCP encapsulation as interfaces change.
> >>
> >> I'm not sure of the MUST here. Nice for sure, but perhaps the
> >> implementation supports MOBIKE or TCP and not both at once ?
> >> Perhaps restate as "if MOBIKE and TCP encapsulation are allowed for a
> >> configuration, the implementation MUST support ......
> >
> > OK. So, the text would look like:
> >
> >          Implementations that implement both MOBIKE and TCP
> >          encapsulation and both are allowed for a configuration
> >          MUST support dynamically enabling and disabling TCP
> >          encapsulation as interfaces change.
> 
> sure, just slightly different start:
> 
>  	Implementations that implement both MOBIKE and TCP
>  	encapsulation within the same connection configuration
>  	MUST ....

OK.

> >>  	8.3.  IKEv2 Session Resumption
> >>
> >> This section says that if a TCP encap session was suspended, that the
> >> client MUST use TCP to resume this. I don't understand why. It is likely
> >> that a resuming client has moved networks, and might be on a network
> >> that would properly support ESP or ESPinUDP. The resumption is really
> >> mostly meant to skip over DH and AUTH phases as these are costly. I see
> >> no reason to tie the transport to this. If I missed a valid reason
> >> for this to be needed, clarify what needs to happen when the server no
> >> longer can or wants to resume the session. Does the client close the TCP
> >> and go back to UDP?
> >
> > I believe you are correct. The idea was to speed up SA resumption
> > (we know that this responder didn't support UDP, but worked with UDP),
> > however you are right that the situation may change.
> >
> > So the correct recommendation for the client would be - act as if this is the IKE_SA_INIT exchange.
> 
> Yes, perfect.

Great :-) 

Regards,
Valery.

> Paul