Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06

Tero Kivinen <kivinen@iki.fi> Fri, 01 July 2016 13:39 UTC

Return-Path: <kivinen@iki.fi>
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 C7E7E12D620 for <ipsec@ietfa.amsl.com>; Fri, 1 Jul 2016 06:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 5PRp7qqpK2zR for <ipsec@ietfa.amsl.com>; Fri, 1 Jul 2016 06:39:53 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5607412D1DC for <ipsec@ietf.org>; Fri, 1 Jul 2016 06:39:53 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u61Ddl5r018197 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 Jul 2016 16:39:47 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u61DdlL4019492; Fri, 1 Jul 2016 16:39:47 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22390.29347.800290.864427@fireball.acr.fi>
Date: Fri, 01 Jul 2016 16:39:47 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <A11D25A55311422A8F4D05C4587EE1F6@buildpc>
References: <alpine.LRH.2.20.1605311635540.16809@bofh.nohats.ca> <4200F5373D5542C985F3D4C51609213C@buildpc> <alpine.LRH.2.20.1606022148040.23132@bofh.nohats.ca> <E61D75BBDD0F4A159352B3258BBAA7DE@buildpc> <alpine.LRH.2.20.1606031155230.11420@bofh.nohats.ca> <A6682BC2468947F1A1669A9B9D558BF5@buildpc> <alpine.LRH.2.20.1606222214230.27151@bofh.nohats.ca> <CE2060023EDE4BDD838CBC70763875B4@buildpc> <alpine.LRH.2.20.1606300444130.4545@bofh.nohats.ca> <A11D25A55311422A8F4D05C4587EE1F6@buildpc>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 15 min
X-Total-Time: 15 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/dCofM6aJQfMOuq6xXeuMEk91-M4>
Cc: ipsec@ietf.org, Paul Wouters <paul@nohats.ca>, Yoav Nir <ynir.ietf@gmail.com>
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06
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: Fri, 01 Jul 2016 13:39:56 -0000

Valery Smyslov writes:
> > I think this document should update 7296 due to adding non-encrypted
> > payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that
> > is not allowed. Someone implementing 7296 should be aware of it to allow
> > it in their implementation.
> 
> Hmmm... Not sure it is needed. As you said RFC 7296 doesn't
> explicitely prohibit that (so we don't violate its requirements) and
> there is a clear negotiation mechanism with puzzles, so that old
> implementations won't be affected.
> 
> I think we should be consitent in our policy whether to update core RFC or not.
> For example, RFC 5723 (Resumption) defines new exchange IKE_SA_RESUME
> that can be used in conjunction with IKE_AUTH instead of IKE_SA_INIT.
> RFC 7296 tells only about IKE_SA_INIT + IKE_AUTH, however 
> RFC 5723 doesn't update IKEv2 RFC. Is our situation much
> different? I don't think so.
> 
> To be clear - I'm not against updating RFC 7296, I just think it is
> not needed.

I think the rules are

All documents which do change IKEv2 core behavior are marked as
updates 4306/5996/7296. Currently those are:

5282 Using Authenticated Encryption Algorithms with the Encrypted Payload
     of the Internet Key Exchange version 2 (IKEv2) Protocol.
     (PROPOSED STANDARD)

     Changes the format of the existing IKEv2 encrypted payload
     format. 

5998 An Extension for EAP-Only Authentication in IKEv2. (PROPOSED
     STANDARD)

     Changes the core component of IKEv2, i.e. how the authentication
     is done. 

6989 Additional Diffie-Hellman Tests for the Internet Key Exchange
     Protocol Version 2 (IKEv2) (PROPOSED STANDARD)

     Changes the mandated behaviro of 5996, by adding new tests. 

7427 Signature Authentication in the Internet Key Exchange Version 2
     (IKEv2) (PROPOSED STANDARD)

     Adds new authentication method, but there is negotiaton for it,
     but as this affects how the authentication (core IKEv2 component)
     works, this was considered to be something that updates 7296.

7670 Generic Raw Public-Key Support for IKEv2 (PROPOSED STANDARD)

     Adds new certificate encoding value, and there is no negotiation
     for it, except that implementations can ignore cert payloads they
     do not understand.

Note, that RFC4718 IKEv2 Clarifications and Implementation Guidelines
did not update 4306 as it did not change anything, it just clarified
things.

Childless initiation, high availability, secure password methods, EAP
re-authnetication, fragmentation, null authentication,
chacha20/poly1305, cloning etc did not update IKEv2, as in most cases
the extensions are something that do not change the existing behavior,
but adds new things, and on the other hand some of those are
experimental, and it was not clear whether they are going to be used
widely or not.

If there is negotiation of this feature before the IKEv2 behavior
changes I think it does not need to update 7296. If this changes
normal behavior of the IKEv2 (timers, mandatory to implement
protection mechanisms) then it needs to update 7296.

I have not yet read any of the latests drafts, so I cannot say if this
is true...
-- 
kivinen@iki.fi