From nobody Tue Feb 11 11:48:01 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F361E12081C; Tue, 11 Feb 2020 11:47:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: David Waltermire , Yoav Nir , ipsecme-chairs@ietf.org, ynir.ietf@gmail.com, ipsec@ietf.org, iesg-secretary@ietf.org Message-ID: <158145047998.19911.13374031355410849376.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2020 11:47:59 -0800 Archived-At: Subject: [IPsec] Publication has been requested for draft-ietf-ipsecme-ipv6-ipv4-codes-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 19:48:00 -0000 Yoav Nir has requested publication of draft-ietf-ipsecme-ipv6-ipv4-codes-04 as Proposed Standard on behalf of the IPSECME working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ From nobody Thu Feb 13 17:35:58 2020 Return-Path: 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 6693C12001A; Thu, 13 Feb 2020 17:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 g2ebDb5TTfls; Thu, 13 Feb 2020 17:35:54 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 3251E120019; Thu, 13 Feb 2020 17:35:54 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id x123so5286629vsc.2; Thu, 13 Feb 2020 17:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cgd3ywN5y2zc+28Pgg4FSfboXBs9VLjehiGQXv70F0A=; b=gyJtEYvG3mEA/RG528Xzpv0mM+S8Sh8aqEsEOumVVFQGhWK5DW3KjGV1RyoKNrdcqU ROXqJ6QzhKuFUWdPmySOEARDK69YaeEIPUvhD8azG0iMryGRC5Oq+3O5iE+SPtwE+ePC bZb/Z2GpbsZa6gk3DtmLlumb3+HS69jnffYhRqfWdTOs+kVRCwSkOWv0t5GpnBe8dgOq RCTzLogk6/yFyr6yeYV2mdFSapqoa0Ad/52d0B6kz2Mjo2r5TqXIyySEj3jJDX9Q24PG ECwGA6BaOQKfq7xZkfFiBKiXm9UBQ8ockNxjt7m5MG8W/PI9qDuSNq/rh6l6wV3zZfzj 4gzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cgd3ywN5y2zc+28Pgg4FSfboXBs9VLjehiGQXv70F0A=; b=bj8OhX6i7blVgpZMWjVDPLNQY4FYJG2iCD+U2i+hlgnex7ir/Tm+ZrJxd5WayRWAbl 8ENF99sOns1DToW42veaNvzunpzX5Fkp2Dxtujn8w5+/QZhqWfy1DxP6+7DUKppzG5Sm XkrQkSTazyufxNH1B27Z55iiQ0xCj090eK+mq+bfz0gXh2D9BCwypj+sji3CMCy1bKyX 6XYu9/EIzI5N4+mNWpqKHOF0UaIOzokOaBqDh8IIOIg9MWFtiw9eEgPyMj+HYqAEz3TM QXqNWfzJdCWSQf7pqr0TEyXtGuUqDikcmHcl1fwx6ttQwpDPjRvK9txatrzc7iPMupOJ sQwA== X-Gm-Message-State: APjAAAW1ZKKuSY9Ks/QBrcapcZScA6i0PjCVtRbP+IH5Aei+k1GdP9LK NK426SVvk+XuuRzlv6cIL1NBBQoLjBzYbduXWURAUmdcoMs= X-Google-Smtp-Source: APXvYqwSh6KwEne385dLstsDKm2JZDsIHM2m+mspqOT+BE5AUSmAnPUuuTF2s0QYbZ9+vRLaGFNGLk4/UomCzApQ0mY= X-Received: by 2002:a67:b309:: with SMTP id a9mr159690vsm.97.1581644153135; Thu, 13 Feb 2020 17:35:53 -0800 (PST) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 13 Feb 2020 20:35:42 -0500 Message-ID: To: saag , tls , IPsecME WG Content-Type: multipart/alternative; boundary="000000000000e8ab79059e7f395e" Archived-At: Subject: [IPsec] Netdev 0x14 co-located with IETF107 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 01:35:57 -0000 --000000000000e8ab79059e7f395e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This is just to let you know that Netdev 0x14 is back co-locating with IETF 107 in Vancouver. There are several security related talks that may be of interest= . Note: Early bird registration is still open until 17th and that many other talks, sessions, workshops are also happening https://netdevconf.info/0x14/accepted-sessions.html 1) Performance study of kernel based TLS handshakes https://netdevconf.info/0x14/session.html?talk-performance-study-of-kernel-= TLS-handshakes 2) TLS performance characterization on modern x86 CPUs https://netdevconf.info/0x14/session.html?talk-TLS-performance-characteriza= tion-on-modern-x86-CPUs 3) Kernel based TLS Hardware offload https://netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementati= on-and-performance-gains 4) Addressing DDoS: Issuing SYN cookies in XDP https://netdevconf.info/0x14/session.html?talk-issuing-SYN-cookies-in-XDP 5) Security and Control of SR-IOV: What=E2=80=99s Our Responsibility if th= e Kernel is Bypassed? https://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR-I= OV Yours, Daniel --000000000000e8ab79059e7f395e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

This is just to le= t you know that Netdev 0x14 is back co-locating with IETF 107 in
V= ancouver. There are several security related talks that may be of interest.=

Note: Early bird registration is still open until 17th and tha= t many other talks, sessions, workshops are also happening=C2=A0
https://netde= vconf.info/0x14/accepted-sessions.html=C2=A0=C2=A0

1) Performanc= e study of kernel based TLS handshakes
https://netdevconf.info/0x14/session.html?ta= lk-performance-study-of-kernel-TLS-handshakes

2) TLS performance= characterization on modern x86 CPUs
https://netdevconf.info/0x14/session.= html?talk-TLS-performance-characterization-on-modern-x86-CPUs

3)= Kernel based TLS Hardware offload
https://netdevconf.info/0x14/session.h= tml?talk-kTLS-HW-offload-implementation-and-performance-gains

4)= Addressing DDoS: Issuing SYN cookies in XDP
https://netdevconf.info/0x14/session.html?talk-issuing= -SYN-cookies-in-XDP

5)=C2=A0 Security and Control of SR-IOV: Wha= t=E2=80=99s Our Responsibility if the
Kernel is Bypassed?
https://netdevconf.info/0x14/sessi= on.html?talk-security-and-control-of-SR-IOV

Your= s,=C2=A0
Daniel

--000000000000e8ab79059e7f395e-- From nobody Sat Feb 22 09:57:42 2020 Return-Path: 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 35BCA3A053E; Sat, 22 Feb 2020 09:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 GuIwjXWu3g_g; Sat, 22 Feb 2020 09:57:21 -0800 (PST) Received: from mail-yw1-xc2c.google.com (mail-yw1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 816B13A053F; Sat, 22 Feb 2020 09:57:21 -0800 (PST) Received: by mail-yw1-xc2c.google.com with SMTP id f204so3163648ywc.10; Sat, 22 Feb 2020 09:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NEEQagSV/x8YSoP51AKzrXJqXpOdwfatLpL8VeDDyF8=; b=S5V6qS9As3g+EJFM1Ot6ozLaKF893g8GHlklJZ3VlqRm0AINVYg1hbgNIt9vlVrOLc UcDgPTkQa4SmvuitWhKdRevhVFIjnhAxM7XvCdYa95tk6DwzUw/bSTXH12S5Vz/JP91i i5Gv4Tn3bGFKvaOocvKb+EnznAoc5C5kScLjXmulhpN0U1nPg+FKY1Fwddav2gMopvll ezd2na9XySI3GtBUofGtlaU3UQWkUD8WRFu/mbw1Lc4Pb9mnwh4Yk9Amm4Wn3sjO8D4r U6tMUMiOo4uZMN8IVhSew6KsH1kjMyp7/tsL3iD2yfie0bWd83BELdGgM6h+GYZ/qrrX L9Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NEEQagSV/x8YSoP51AKzrXJqXpOdwfatLpL8VeDDyF8=; b=mGl4/RFqbNNyYvf83epEjyesrqXiRib1oms9C9ij9k0n9mkYihKWlNWccN4piu8cfL D4N5oA+WEV4KBwV8Nxgb9uWp9Z568rn7bwBzkhCPDeuDhGeHH7fCAgTO/xf9ERBYDIg0 C2IOC4D0B06buN/X8fddFGg+JauhYggCdbxPM7MH48+v5KZdqn17dOSWAr8Y4gCGAAf4 7kkaHJiPAlKT6MxrPyp6geimJ9O+FeEQ25GncFQnVfyX5rcNbaCBJQWbLfDi1khFrgdf KFONPg90pLAaTkOaaIMrV0uKrO3ubNZi2WswrX0x5ImnrC2X6/oQuk8rN4qfmGkbzhjk Ch2w== X-Gm-Message-State: APjAAAW+I6wbqBJfWLiEfWSm32qdR76LqIZZ/K7jOwWsgNhJw/PjtjcM lCkOlGMZ3HoCEvMXCdXaaIXVVfvHlthH8mpXmvJ+czot X-Google-Smtp-Source: APXvYqyOZR9VjQrXORj9fFzf52Wx/H7QYnU4osepy4KTVtz6GCT5QnVsCZlSFBuv9bAwgBwofX5/DPCXQhLX0KMaLto= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr20481655uaq.114.1582390491500; Sat, 22 Feb 2020 08:54:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Sat, 22 Feb 2020 11:54:40 -0500 Message-ID: To: saag , tls , IPsecME WG , NVO3 , sfc@ietf.org, int-area , t2trg@irtf.org, tsv-area@ietf.org Content-Type: multipart/alternative; boundary="000000000000245448059f2cff2c" Archived-At: Subject: Re: [IPsec] Netdev 0x14 co-located with IETF107 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 17:57:23 -0000 --000000000000245448059f2cff2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Just to follow-up with Netdev 0x14 co-located with the IETF. The schedule has been announced [1], and the schedule [2] published. You can even filter according to your own interests (AI, container, DDoS, driver, IoT, kubernetes, L2, L3, wireless, security, ... and many more!). Please have look and check here ! Check out registration information here [3] Yours, Daniel [1] https://netdevconf.info/0x14/news.html?schedule-up [2] https://netdevconf.info/0x14/schedule.html [3] https://netdevconf.info/0x14/registration.html On Thu, Feb 13, 2020 at 8:35 PM Daniel Migault wrote: > Hi, > > This is just to let you know that Netdev 0x14 is back co-locating with > IETF 107 in > Vancouver. There are several security related talks that may be of > interest. > > Note: Early bird registration is still open until 17th and that many othe= r > talks, sessions, workshops are also happening > https://netdevconf.info/0x14/accepted-sessions.html > > 1) Performance study of kernel based TLS handshakes > > https://netdevconf.info/0x14/session.html?talk-performance-study-of-kerne= l-TLS-handshakes > > 2) TLS performance characterization on modern x86 CPUs > > https://netdevconf.info/0x14/session.html?talk-TLS-performance-characteri= zation-on-modern-x86-CPUs > > 3) Kernel based TLS Hardware offload > > https://netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementa= tion-and-performance-gains > > 4) Addressing DDoS: Issuing SYN cookies in XDP > https://netdevconf.info/0x14/session.html?talk-issuing-SYN-cookies-in-XDP > > 5) Security and Control of SR-IOV: What=E2=80=99s Our Responsibility if = the > Kernel is Bypassed? > > https://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR= -IOV > > Yours, > Daniel > > --=20 Daniel Migault Ericsson --000000000000245448059f2cff2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Check out registration information here=C2=A0[3]

Yours,=C2=A0
Daniel=C2=A0

[1]=C2=A0https://netdev= conf.info/0x14/news.html?schedule-up


On Thu, Feb 13, 2020 at 8= :35 PM Daniel Migault <mglt.ietf@= gmail.com> wrote:
Hi,=C2=A0

This is= just to let you know that Netdev 0x14 is back co-locating with IETF 107 in=
Vancouver. There are several security related talks that may be o= f interest.

Note: Early bird registration is still open until 1= 7th and that many other talks, sessions, workshops are also happening=C2=A0=
https://netdevconf.info/0x14/accepted-sessions.html=C2= =A0=C2=A0

1) Performance study of kernel based TLS handshakes
https://netdev= conf.info/0x14/session.html?talk-performance-study-of-kernel-TLS-handshakes=

2) TLS performance characterization on modern x86 CPUs
https:/= /netdevconf.info/0x14/session.html?talk-TLS-performance-characterization-on= -modern-x86-CPUs

3) Kernel based TLS Hardware offload
https://= netdevconf.info/0x14/session.html?talk-kTLS-HW-offload-implementation-and-p= erformance-gains

4) Addressing DDoS: Issuing SYN cookies in XDP<= br>https://netdevconf.info/= 0x14/session.html?talk-issuing-SYN-cookies-in-XDP

5)=C2=A0 Secur= ity and Control of SR-IOV: What=E2=80=99s Our Responsibility if the
Kern= el is Bypassed?
http= s://netdevconf.info/0x14/session.html?talk-security-and-control-of-SR-IOV

Yours,=C2=A0
Daniel



--
Daniel Migault
Ericsson
--000000000000245448059f2cff2c-- From nobody Mon Feb 24 11:50:28 2020 Return-Path: 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 258FA3A11F4; Mon, 24 Feb 2020 11:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 RpuVuMeiqRFs; Mon, 24 Feb 2020 11:50:24 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9253A11F2; Mon, 24 Feb 2020 11:50:20 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 148C5548048; Mon, 24 Feb 2020 20:50:14 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0C7A4440040; Mon, 24 Feb 2020 20:50:14 +0100 (CET) Date: Mon, 24 Feb 2020 20:50:14 +0100 From: Toerless Eckert To: ipsec@ietf.org, ipsecme@ietf.org Cc: mcr+ietf@sandelman.ca, draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:50:26 -0000 [hope its fine to cross-post ipsec and ipsecme given how one is concluded, but may have more long-time subscribers] We're looking for opinions about an IPsec profile for "Autonomic Control Plane" draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt Quick background so you do not need to read anything more than 6.7.1.1.1: ACP builds an "overlay" network with hop-by-hop IKEv2/ESP "tunnels". These hops are meant to be typical enterprise/WAN/DC software...Giga/Terrabit routers. Hence some interest on side of the authors (me) to see how we can adopt the crypto algorithm rementserofile of RFC8221 to minimize high-speed algorithm implementation requirements so that ACP would be as easy to adopt across various vendor crypto HW as possible. Note that ACP also supports DTLS, but we think that DLS would primarily be used in lower-end devices, so crypto woould be done in software there, hence we do not bother taking the step to try to optimize / minimize the number of required algorithms. Here is the adoption of the RFC8221 algorithms: OTHERS - as in RFC8221 (MUST NOT / SHOULD NOT) ENCR_NULL - MUST NOT (require confidentiality of payload in ACP) (was MUST in RFC8221) ENCR_AES_GCM_16 - MUST (was MUST in RFC8221) ENCR_AES_CBC - SHOULD if higher perf than ENCR_AES_GCM_16, else MAY (was MUST in RFC8221) ENCR_AES_CCM_8 - SHOULD if higher perf than ENCR_AES_GCM_16, else MAY (was SHOULD in RFC8221) ENCR_CHACHA20_POLY1305 - SHOULD with equal or higher perf than ENCR_AES_GCM_16, else MAY (was SHOULD in RFC8221) To make life easy, we have one ESP MTI algo to interop, that's GCM_16. Because packets will be hop-by-hop forwarded across multiple tunnels, ACP has no legacy interop requirements. Aka: We only need to think about the relevant algorithms for device types so old, that they would never implement ACP (and we have to guess for those devices of course, but we have some good experience of pre-standard vendor implementations). Effectively, we downgrade and modify requirements for CBC, CCM_8 and POLY1305 acording to our understandings: 1. Given how we have one MTI (GCM_16), and no further need for legacy compatibility, there is no need for additional MTI (MUST), so the remaining desirable algorithms can be SHOULD or less. 2. A SHOULD only makes sense in the ACP use case if the actual performance is higher than that of the MTI, hence the opportunistic performance conditioned SHOULD in CBC and CCM_8. Expectation is that those algos would be supported by a vendor if it can make it faster, and then that speed benefit would be had when connecting that vendors devices together. 3. POLY1305 is really desirable as crypto backup to the AES options, so the performance based SHOULD is not opportunistic as for CBC and CCM_8. Maybe the language is not 100% correct. Maybe the language is not perfect. seems like i could leave out all the "MAY" at the end and achieve the same. Cheers Toerless From nobody Tue Feb 25 12:17:46 2020 Return-Path: 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 CF4973A151A; Tue, 25 Feb 2020 12:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 J7ndumDlABou; Tue, 25 Feb 2020 12:17:43 -0800 (PST) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 BC0783A1519; Tue, 25 Feb 2020 12:17:42 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id m16so160555wrx.11; Tue, 25 Feb 2020 12:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=slgvusqTM/1p1dZvMq7GVCofQyDLWxdmgtwhwUCzoj0=; b=Q6k6UHtJjhpJWl/7i1z7xt6sr+UufOpwJnhIjGyuhOYCp+jJ0ZIBieR4NnqrtvjdXv /mJzVsYy8xage08rVJJNNLOJKnTlAU1LYoViFmOXMOE52fYqu0qI0Oa70QbgW6mTNHVL qGZ/mdGF8Q8tqe0s+YUPbFJXUl8R4P8HypgV06H1kPfuVyQ/RtPRNn373cX5MrUyf/5E 49vmiu1cHQ/Gs9tuAdKU+YCfrBrJlCWJcRo5JKksUKjZSnZbnnzz/TaunXrk5ZsGSv6w 9HYZV9ujb4G5zd6x4ekQqj8orhtRyolqCIOwPyN3a2/Dny2vIZnesDPadvfNAFUDA9Bh 6OXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=slgvusqTM/1p1dZvMq7GVCofQyDLWxdmgtwhwUCzoj0=; b=TZ1ia0vkC6NDZu9tGVi73g+fQ60b77oHqeSI/VUHD00OmmWBZOYyeBxiTtw9ZGJqdG HqzMNFIsvHBonxOpVCYS7um0iY89IfhFSWKghKDqvWZ0GDOAyToHRYCRiTVWZPCUwqxe 2T+svwetOSJhYVMJY20fyXXgKFQU7ag51LOyS0mJPYoDbqLl+sSSvRiJI85Tn2QBSA9g QJQ/HHtD3IPeRrllWflV+e3Ty7mG8pUMXIrLLYSMSId7NLq5xn72I+E1IPcm2J0qC17J m/vJi4fIQHvAWaoaCvJ6Z7vAa1mZ+gl1Oqpg6kyGfuXHsliV4jJpKLdWwPkPwaLQHbZe BqTQ== X-Gm-Message-State: APjAAAW4CnscAyvathWmvSH4QeUnYshwzMzcJdTiWxQ6zOUFpWu13y1a XQUj/u0edrkDsmd1mDoKXvet09GUh4Q= X-Google-Smtp-Source: APXvYqypu+GhcQEmn0nOh619DCPmW6XQfTqzjtYhWVov6XyjGDnjsc1mnA7zG3JhUfk0juoBvroqug== X-Received: by 2002:adf:e686:: with SMTP id r6mr839306wrm.177.1582661861219; Tue, 25 Feb 2020 12:17:41 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g2sm24782909wrw.76.2020.02.25.12.17.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 12:17:33 -0800 (PST) From: Yoav Nir Message-Id: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8B685F3-71DA-4A1F-A10B-1EA733F55775" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Tue, 25 Feb 2020 22:17:30 +0200 In-Reply-To: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> Cc: "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org To: Toerless Eckert References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 20:17:45 -0000 --Apple-Mail=_C8B685F3-71DA-4A1F-A10B-1EA733F55775 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Toerless. I trimmed below most of your background info. > On 24 Feb 2020, at 21:50, Toerless Eckert wrote: >=20 > [hope its fine to cross-post ipsec and ipsecme given how one is = concluded, but may have > more long-time subscribers] ipsec is this group=E2=80=99s mailing list. I don=E2=80=99t know that = there even is an ipsecme@ietf.org > We're looking for opinions about an IPsec profile for "Autonomic = Control Plane" > draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 = of: >=20 > = https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be05667= 9b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane= /draft-ietf-anima-autonomic-control-plane.txt >=20 > Quick background so you do not need to read anything more than = 6.7.1.1.1: I read a little more. Hope you don=E2=80=99t mind. The profile seems fine to me. There is one thing that I think is = missing. The profile specifies that the ACP nodes should use tunnel mode (when = GRE is not used), because: IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure channels, and not only its own generated ACP packets. With IPsec transport mode, it would only be possible to send packets originated by the ACP node itself. OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, = but that=E2=80=99s not important here) they need an IPsec policy that = specifies traffic selectors so that IKEv2 can specify traffic selectors. = Nowhere in your draft do I see a specification of what traffic = selectors need to be negotiated. If I understand the above paragraph correctly, both the source of the = packet and the destination can be the IP address of any ACP node, = neither of which are required to be the tunnel endpoints. This implies = some sort of generic traffic selector. The draft should specify this, = IMO Yoav --Apple-Mail=_C8B685F3-71DA-4A1F-A10B-1EA733F55775 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Toerless.

I trimmed = below most of your background info.

On 24 = Feb 2020, at 21:50, Toerless Eckert <tte@cs.fau.de> wrote:

[hope = its fine to cross-post ipsec and ipsecme given how one is concluded, but = may have
more long-time subscribers]

ipsec is = this group=E2=80=99s mailing list. I don=E2=80=99t know that there even = is an ipsecme@ietf.org

We're looking = for opinions about an IPsec profile for "Autonomic Control Plane"
draft-ietf-anima-autonomic-control-plane, or specifically = 6.7.1.1.1 of:

https://raw.githubusercontent.com/anima-wg/autonomic-control-pl= ane/be056679b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-co= ntrol-plane/draft-ietf-anima-autonomic-control-plane.txt

Quick background so you do not need to read = anything more than 6.7.1.1.1:

I read a = little more. Hope you don=E2=80=99t mind.

The profile seems fine to me. There is one thing = that I think is missing.

The = profile specifies that the ACP nodes should use tunnel mode (when GRE is = not used), because:
   IPsec tunnel mode is required because the ACP will =
route/forward
   packets received from any other ACP node across the ACP secure
   channels, and not only its own generated ACP packets.  With IPsec
   transport mode, it would only be possible to send packets originated
   by the ACP node itself.
OK. When IKEv2 is used = to negotiate tunnel-mode SAs (and transport mode, but that=E2=80=99s not = important here) they need an IPsec policy that specifies traffic = selectors so that IKEv2 can specify traffic selectors.  Nowhere in = your draft do I see a specification of what traffic selectors need to be = negotiated.

If = I understand the above paragraph correctly, both the source of the = packet and the destination can be the IP address of any ACP node, = neither of which are required to be the tunnel endpoints.  This = implies some sort of generic traffic selector.  The draft should = specify this, IMO

Yoav

= --Apple-Mail=_C8B685F3-71DA-4A1F-A10B-1EA733F55775-- From nobody Tue Feb 25 12:37:59 2020 Return-Path: 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 0F3943A1563; Tue, 25 Feb 2020 12:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Z2NECJm2NhWc; Tue, 25 Feb 2020 12:37:56 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FEA53A155B; Tue, 25 Feb 2020 12:37:55 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 34722548048; Tue, 25 Feb 2020 21:37:51 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2DAF9440040; Tue, 25 Feb 2020 21:37:51 +0100 (CET) Date: Tue, 25 Feb 2020 21:37:51 +0100 From: Toerless Eckert To: Yoav Nir Cc: "ipsec@ietf.org WG" , Michael Richardson , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200225203751.GH39574@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 20:37:58 -0000 On Tue, Feb 25, 2020 at 10:17:30PM +0200, Yoav Nir wrote: > ipsec is this group???s mailing list. I don???t know that there even is an ipsecme@ietf.org Yepp. Silly me. Didn't check that ipsecme was keeping the old mailing list name. > I read a little more. Hope you don???t mind. > > The profile seems fine to me. Great! > There is one thing that I think is missing. > > The profile specifies that the ACP nodes should use tunnel mode (when GRE is not used), because: > IPsec tunnel mode is required because the ACP will route/forward > packets received from any other ACP node across the ACP secure > channels, and not only its own generated ACP packets. With IPsec > transport mode, it would only be possible to send packets originated > by the ACP node itself. > OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, but that???s not important here) they need an IPsec policy that specifies traffic selectors so that IKEv2 can specify traffic selectors. Nowhere in your draft do I see a specification of what traffic selectors need to be negotiated. > > If I understand the above paragraph correctly, both the source of the packet and the destination can be the IP address of any ACP node, neither of which are required to be the tunnel endpoints. This implies some sort of generic traffic selector. The draft should specify this, IMO Great catch. How about: The traffic selector for the SA MUST be set to IPv6 ANY ANY (::/0, ::/0). (was trying to find an RFC with the same requirement, but to difficult to grep ;-) Cheers toerless From nobody Tue Feb 25 14:44:15 2020 Return-Path: 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 5D0DF3A046E; Tue, 25 Feb 2020 14:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Jzob6_8X2Jnz; Tue, 25 Feb 2020 14:44:11 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C4C3A045B; Tue, 25 Feb 2020 14:44:11 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D5BB538983; Tue, 25 Feb 2020 17:43:09 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6ACA8825; Tue, 25 Feb 2020 17:44:10 -0500 (EST) From: Michael Richardson To: Yoav Nir cc: Toerless Eckert , "ipsec\@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 22:44:14 -0000 --=-=-= Content-Type: text/plain Yoav Nir wrote: > The profile specifies that the ACP nodes should use tunnel mode (when > GRE is not used), because: IPsec tunnel mode is required because the > ACP will route/forward packets received from any other ACP node across > the ACP secure channels, and not only its own generated ACP packets. It's a VTI-type interface. The TS should be for hostA<->hostB with protocol GRE. It could be in tunnel or transport mode. hostA and hostB are identified, btw, with IPv6 LL addresses. > If I understand the above paragraph correctly, both the source of the > packet and the destination can be the IP address of any ACP node, > neither of which are required to be the tunnel endpoints. This implies > some sort of generic traffic selector. The draft should specify this, > IMO The GRE layer and the routing protocol would take care of the ::/0<->::/0 needs, not IPsec. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5VozoACgkQgItw+93Q 3WX7Lgf/Zlm+v1tv8dLKd61UBsSMmrE7KwD/aVFGfL1lResULxXb4xROKqM+H6Cy 9fFiW/xuMjdNoLR1CcTAO0u7TGFUM2clA16vefTkJzKqc2NJTKb0+Md2zMd3Mtd2 fWgu22GYS8O9bqSk1e8Q2LvCVE73GGdvkpE64xmMjUNb5NW398Bt9Dz+K0wy0FUI 3S6APUsEGKzyNwVGnNjnhI/gVJadz9DJfblo06KhFsE4+ZvfWMYmDqgyiQolvmuQ Xr4rcGJjDZEIOBYRcNMJBSBtDv7CyCxg72tRVtjOHgNIyjRzE645bNxio6mVyzty 73GYYPsbFqkkKU/IyuR3CJDJzXau6g== =Tmsi -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 25 16:03:26 2020 Return-Path: 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 D985B3A090B; Tue, 25 Feb 2020 16:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 Y0aR5GrCmlO4; Tue, 25 Feb 2020 16:03:23 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376653A0906; Tue, 25 Feb 2020 16:03:23 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 59E70548048; Wed, 26 Feb 2020 01:03:18 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56874440040; Wed, 26 Feb 2020 01:03:18 +0100 (CET) Date: Wed, 26 Feb 2020 01:03:18 +0100 From: Toerless Eckert To: Michael Richardson Cc: Yoav Nir , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23402.1582670650@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:03:25 -0000 Michael: Yoav talked about the non-GRE case. On Tue, Feb 25, 2020 at 05:44:10PM -0500, Michael Richardson wrote: > > Yoav Nir wrote: > > The profile specifies that the ACP nodes should use tunnel mode (when > > GRE is not used), because: IPsec tunnel mode is required because the > > ACP will route/forward packets received from any other ACP node across > > the ACP secure channels, and not only its own generated ACP packets. > > It's a VTI-type interface. > The TS should be for hostA<->hostB with protocol GRE. > It could be in tunnel or transport mode. > hostA and hostB are identified, btw, with IPv6 LL addresses. > > > If I understand the above paragraph correctly, both the source of the > > packet and the destination can be the IP address of any ACP node, > > neither of which are required to be the tunnel endpoints. This implies > > some sort of generic traffic selector. The draft should specify this, > > IMO > > The GRE layer and the routing protocol would take care of the ::/0<->::/0 > needs, not IPsec. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- --- tte@cs.fau.de From nobody Tue Feb 25 17:20:28 2020 Return-Path: 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 059403A07A8; Tue, 25 Feb 2020 17:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 XGNHVLhdcuSD; Tue, 25 Feb 2020 17:20:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FAF13A079F; Tue, 25 Feb 2020 17:20:24 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5DCF038983; Tue, 25 Feb 2020 20:19:22 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 117682EB6; Tue, 25 Feb 2020 20:20:23 -0500 (EST) From: Michael Richardson To: Toerless Eckert cc: Yoav Nir , "ipsec\@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 01:20:27 -0000 --=-=-= Content-Type: text/plain > Michael: Yoav talked about the non-GRE case. In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode. Which is literally the VTI case. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5Vx9YACgkQgItw+93Q 3WW8dggApiQKn66lcqcEkCMVCCNI8e4wzLxRCogB8V0uyZHhDRaqtaW/moMj22nc VvVj8311atfAKVWm7AnPYLrqt6YPEl3PJhaJ1x2QRiE8OvQVnnnBHuGduB2crgqH re8LJcp5PlgFImRloS2nJTUsrmGLtI5+yW21DSFZ3SGOwNzJpfWWB5uCjWXb6xEn Pwya94xu9rVa+c6/rYih60n7uev/iOzpjip16xsLdcNJ39ilQ0ru8OnGDSevGUwo SRlXpymap2R81YE2da8OIMLHoTSojuNcQoH8Q4UVLdDG9/kG2KyYECq2gaPN6lKa 8/B6FonNPn4uvM63pj+qQm7ac5rGFw== =Iv4H -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Feb 25 21:51:31 2020 Return-Path: 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 AA0023A0DF7; Tue, 25 Feb 2020 21:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=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 M_a4XQAKjn6I; Tue, 25 Feb 2020 21:51:24 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 C24F53A0A59; Tue, 25 Feb 2020 21:51:23 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id z3so1427130wru.3; Tue, 25 Feb 2020 21:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=las242xdIKrY0gG2uIlMZybFr46DTMtaHR9GtHm7he4=; b=Fhr1iSZbC98Tj7VlOj1MnkhSLv4Au0oo3g5BDLrr+iR0nNs+W1ML+eejY2NjR5QWV+ yoPRunlVvC2QycmKdIUb/lGsKB42hK/J+mCppB299KpcrevwpivC/oUMlmNjShAC4UXm h3AKNAqiKC5m7LahFrr/FUfO6f1mQWEz/qxcY2dl7kqBLsLXMs0Wssl0EMfvqxq4AmLc x2G9pfe/c9ntG8La4FgJlJRM/1/5fpvnD8gExInUv3knR3aTzEr+CUcJzu7NzYDrQ2Cx KXYgf9ObuZi+KHreIPLoCWdXhbqjLktO+XGnRqFZxP5UTWpZ1AH2WEv6NcjmMPODPlRy Hs6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=las242xdIKrY0gG2uIlMZybFr46DTMtaHR9GtHm7he4=; b=Keg3cqo3vWrCByihJc57CjipCOstGTGf/RJnmTfLojD22Si54ZoXVWKGumPlMusI8W Ql8fLoSMReA+A/ScuvEuN3Gg6PILfMEd8nfRs3uFV/SGcU61nZoH3ouiaj7W/e2ETJkW VrDOBxTksOR6otOZfsvqL1RTd6zz9AtmRrE4s/W9mApx+Oioxx63kW0ioVzc8miziM0j UdemTOy5MD/hBRxsuq9gKl5A+Pba1TrEhIgxsbznltQzfRxQAuAO/qsyas/LsWo9MS8X Shy2oUgUF2jnT5a8jW9JLzJtxhZPce5s70GRPHci8GloNKwsOlnG26WsAS2oFoeykA7l J1vQ== X-Gm-Message-State: APjAAAX5HqCkjif6CDZHYRE3mjs1mhDgy68Vy9QkR59tDt2HIhfryJMa PUjVlH/RVuKNiq0Thu8Mkg4= X-Google-Smtp-Source: APXvYqykgtvGQ5rvruzJTCnBEKoOhHCSfe1WwDcLP9hsv7K+Laq169cnUzD6KIxZu2LOLc2pTnMHnQ== X-Received: by 2002:adf:9d4a:: with SMTP id o10mr3473269wre.392.1582696282171; Tue, 25 Feb 2020 21:51:22 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id h13sm2053980wrw.54.2020.02.25.21.51.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2020 21:51:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Yoav Nir In-Reply-To: <31896.1582680023@localhost> Date: Wed, 26 Feb 2020 07:51:19 +0200 Cc: Toerless Eckert , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 05:51:27 -0000 The draft says =E2=80=9CIPsec tunnel mode is required =E2=80=9D, so = it=E2=80=99s not transport. What goes in the TS payloads? > On 26 Feb 2020, at 3:20, Michael Richardson = wrote: >=20 >=20 >> Michael: Yoav talked about the non-GRE case. >=20 > In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode. > Which is literally the VTI case. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 From nobody Wed Feb 26 06:03:43 2020 Return-Path: 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 71F9D3A03FC; Wed, 26 Feb 2020 06:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.586 X-Spam-Level: X-Spam-Status: No, score=-0.586 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, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 eYg7lVLK0YBM; Wed, 26 Feb 2020 06:03:33 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 B82B73A044A; Wed, 26 Feb 2020 06:03:17 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id t23so3205569wmi.1; Wed, 26 Feb 2020 06:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=2Wy9WzkZcjdlym76a+sSu2mA+ElwTOakTIhRH4zxSqc=; b=vdvyZNK4kRsjbxrBug6pTTznaEfWfAvc2EWnFj3DxgD5Nm+kLtlBoRIophnHr5SaOK pmGHOF8bwSLDZu47JDJM95/Hvq1PSefeTdlbEu07ocyEJ4ZRK4FuiunUoAkaL094+NoD DLzvixBG6+wAwh0k34K8C/OSTfHAv4VO7DDL0dxFjVROP+r3zlg8AZJ9D7APUkVXWcBr yCSQUfikQcaRdnsTpdGlObRMI89qMT30dDBOj5KhHqQ9pekudQWuL1mjOfUynpxtbJzk qp5MhuD7igEalTUZBjYi1nzjsnRBUwOmQE95CDweyqDtXSkK4/1BC6NF4Z3wsKLr1EaC R0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=2Wy9WzkZcjdlym76a+sSu2mA+ElwTOakTIhRH4zxSqc=; b=MjMAEFkAAI33qQxdh+g3QQ5eBM9xrJp2aRnamUNIy8pkleG91tia0ry60E3lJAmRDP oxhFeWbCTahDjq+Dc/u51XRtMRjm+UkKj1EV3t6cGaZERbD3afBaBwiLWUm6tVAg1DIU XTlb16zQtX7YQbqC9Cr2p71fnNX8jUxKyqO7hsJYuDLL0vipKB1dbZpC/L2SYaBgSwXN Bg/kxhnntLbV/0Rz+17e2jHymuIB2tPwvVIfZfJPPs0wHBxUHdHNxobgyGg7QxtyqBnt W6Lzsju3BwIn/PVLiUW+sijgDovPhdPU/rDmNGUW31id4EHwQmtzlQW3jjGNLUErHKMJ QrYg== X-Gm-Message-State: APjAAAXGp9Q29KPjrIQr0J0C0q8xW7s6EXPJXaY350pDMjSayQ+QBoRe TjdA+C2I42nhgC0gJ2ma+4/S2gKR X-Google-Smtp-Source: APXvYqyOMP6rFSam3+gFOVtupoPg66tL0wdJ60GDiF62d/U6QxguueL0PqOYt58BcslqHQijxtj0SQ== X-Received: by 2002:a7b:c119:: with SMTP id w25mr5974423wmi.112.1582725788120; Wed, 26 Feb 2020 06:03:08 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id y7sm7920220wmd.1.2020.02.26.06.03.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 26 Feb 2020 06:03:06 -0800 (PST) From: "Valery Smyslov" To: "'Yoav Nir'" , "'Toerless Eckert'" Cc: , "'Michael Richardson'" , References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> In-Reply-To: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> Date: Wed, 26 Feb 2020 17:03:08 +0300 Message-ID: <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B81_01D5ECC6.9F1D3970" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMQRTEh8jiXoowGsPdFJKCFNOl05wMD9EZlpaCl+NA= Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 14:03:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B81_01D5ECC6.9F1D3970 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 a couple of comments. =20 I think that the profile is generally OK, but it seems to me that a few = issues persist. =20 1. The Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter names used in this text. =20 =E2=80=9CPKCS #7 wrapped X.509 certificate=E2=80=9D certificate = encoding is deprecated and is not used in IKEv2=20 (see = https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#= ikev2-parameters-11). Generally, I see no need for the text that imposes requirements on = certificate encoding at all =E2=80=93=20 we never run into the interoperability problems with this? as far = as I remember. I suggest to remove this text. =20 2. If certificate chains are used, all intermediate certificates up = to, and including the locally provisioned trust anchor certificate MUST be signaled. See Section 6.10.7 for the sub-CA example in which certificate chains are used. =20 This is confusing. I read this text as the =E2=80=9CMUST=E2=80=9D is = imposed only if=20 =E2=80=9Ccertificate chains are used=E2=80=9D. Does it mean that = implementations=20 may skip this =E2=80=9CMUST=E2=80=9D if EE certificate is directly = signed by CA certificate and there is no intermediate certificates? Or is it still a chain and =E2=80=9Cif=E2=80=9D is relevant to the case when there is no CA = and there is a direct trust to EE certificates (in which case PKI is not needed at all and you can use RAW public = keys)? =20 Another point: trust anchors certificates usually are not included = in CERT payload in IKEv2. I see draft=E2=80=99s a reasoning that this inclusion would allow = better network debugging, but I=E2=80=99m not sure I can buy this argument. Probably more = detailed explanation is needed. =20 3. IKEv2 authentication MUST use authentication method 14 ("Digital Signature") for ACP certificates; this authentication method can be used with both RSA and ECDSA certificates, as indicated by a PKIX- style OID. =20 I think it=E2=80=99s better to rephrase this more accurately: = =E2=80=9Cindicated by an ASN.1 object AlgorithmIdentifier=E2=80=9D (which may include parameters besides OID). =20 A typo in the title of 6.7.1.1.2.: s/RFC847/RFC8247 =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, February 25, 2020 11:18 PM To: Toerless Eckert Cc: ipsec@ietf.org WG; Michael Richardson; = draft-ietf-anima-autonomic-control-plane@ietf.org Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic = control plane) =20 Hi, Toerless. =20 I trimmed below most of your background info. On 24 Feb 2020, at 21:50, Toerless Eckert wrote: =20 [hope its fine to cross-post ipsec and ipsecme given how one is = concluded, but may have more long-time subscribers] =20 ipsec is this group=E2=80=99s mailing list. I don=E2=80=99t know that = there even is an ipsecme@ietf.org We're looking for opinions about an IPsec profile for "Autonomic Control = Plane" draft-ietf-anima-autonomic-control-plane, or specifically 6.7.1.1.1 of: https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/be0566= 79b9c9cac8c2d664958a3b91585b010a83/draft-ietf-anima-autonomic-control-pla= ne/draft-ietf-anima-autonomic-control-plane.txt Quick background so you do not need to read anything more than = 6.7.1.1.1: =20 I read a little more. Hope you don=E2=80=99t mind. =20 The profile seems fine to me. There is one thing that I think is = missing. =20 The profile specifies that the ACP nodes should use tunnel mode (when = GRE is not used), because: IPsec tunnel mode is required because the ACP will route/forward packets received from any other ACP node across the ACP secure channels, and not only its own generated ACP packets. With IPsec transport mode, it would only be possible to send packets originated by the ACP node itself. OK. When IKEv2 is used to negotiate tunnel-mode SAs (and transport mode, = but that=E2=80=99s not important here) they need an IPsec policy that = specifies traffic selectors so that IKEv2 can specify traffic selectors. = Nowhere in your draft do I see a specification of what traffic = selectors need to be negotiated. =20 If I understand the above paragraph correctly, both the source of the = packet and the destination can be the IP address of any ACP node, = neither of which are required to be the tunnel endpoints. This implies = some sort of generic traffic selector. The draft should specify this, = IMO =20 Yoav =20 ------=_NextPart_000_0B81_01D5ECC6.9F1D3970 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

a couple of comments.

 

I think that the profile is generally OK, but it seems to me that a = few issues persist.

 

1. The

=C2=A0=C2=A0 = Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) = MUST be

=C2=A0=C2=A0 = supported.=C2=A0 See [IKEV2IANA] for this and other IANA IKEv2 = parameter

=C2=A0=C2=A0 names = used in this text.

 

=C2=A0=C2=A0=C2=A0 =E2=80=9CPKCS #7 wrapped X.509 = certificate=E2=80=9D certificate encoding is deprecated and is not used = in IKEv2

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(see = https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#= ikev2-parameters-11).

=C2=A0=C2=A0=C2=A0=C2=A0 Generally, I see no need for the text that = imposes requirements on certificate encoding at all =E2=80=93 =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0we never run into the interoperability = problems with this? as far as I remember. I suggest to remove this = text.

 

2.=C2=A0=C2=A0 If certificate chains are =
used, all intermediate certificates up to,

=C2=A0=C2=A0 and = including the locally provisioned trust anchor certificate = MUST

=C2=A0=C2=A0 be = signaled.=C2=A0 See Section 6.10.7 for the sub-CA example in = which

=C2=A0=C2=A0 = certificate chains are used.

 

=C2=A0=C2=A0=C2=A0 This is confusing. I read this text as the = =E2=80=9CMUST=E2=80=9D is imposed only if

=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=9Ccertificate chains are = used=E2=80=9D. Does it mean that implementations =

=C2=A0=C2=A0=C2=A0=C2=A0may skip this =E2=80=9CMUST=E2=80=9D if EE = certificate is directly signed by CA certificate

=C2=A0=C2=A0=C2=A0 and there is no intermediate certificates? Or is = it still a chain

=C2=A0=C2=A0=C2=A0 and =E2=80=9Cif=E2=80=9D is relevant to the case = when there is no CA and there is a direct trust to EE = certificates

=C2=A0=C2=A0=C2=A0 (in which case PKI is not needed at all and you = can use RAW public keys)?

=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Another point: trust anchors = certificates usually are not included in CERT payload in = IKEv2.

=C2=A0=C2=A0=C2=A0=C2=A0 I see draft=E2=80=99s a reasoning that this = inclusion would allow better network debugging,

=C2=A0=C2=A0=C2=A0=C2=A0 but I=E2=80=99m not sure I can buy this = argument. Probably more detailed

=C2=A0=C2=A0=C2=A0=C2=A0 explanation is = needed.

 

3.=C2=A0=C2=A0 IKEv2 authentication MUST =
use authentication method 14 ("Digital

=C2=A0=C2=A0 = Signature") for ACP certificates; this authentication method can = be

=C2=A0=C2=A0 used = with both RSA and ECDSA certificates, as indicated by a = PKIX-

=C2=A0=C2=A0 style OID.

 

=C2=A0=C2=A0=C2=A0 I think it=E2=80=99s better to rephrase this more = accurately: =E2=80=9Cindicated by an ASN.1 object = AlgorithmIdentifier=E2=80=9D

=C2=A0=C2=A0=C2=A0 (which may include parameters besides = OID).

 

A typo in the title of 6.7.1.1.2.: = =C2=A0s/RFC847/RFC8247

 

Regards,

Valery.

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent: Tuesday, February 25, 2020 11:18 PM
To: = Toerless Eckert
Cc: ipsec@ietf.org WG; Michael Richardson; = draft-ietf-anima-autonomic-control-plane@ietf.org
Subject: Re: = [IPsec] IPsec profile feedback wanted (draft autonomic control = plane)

 

Hi, = Toerless.

 

I = trimmed below most of your background info.



On 24 = Feb 2020, at 21:50, Toerless Eckert <tte@cs.fau.de> = wrote:

 

[hope its fine to cross-post ipsec and ipsecme given = how one is concluded, but may have
more long-time = subscribers]

 

ipsec = is this group=E2=80=99s mailing list. I don=E2=80=99t know that there = even is an ipsecme@ietf.org



We're looking for opinions about an IPsec profile for = "Autonomic Control = Plane"
draft-ietf-anima-autonomic-control-plane, or specifically = 6.7.1.1.1 of:

https://raw.gith= ubusercontent.com/anima-wg/autonomic-control-plane/be056679b9c9cac8c2d664= 958a3b91585b010a83/draft-ietf-anima-autonomic-control-plane/draft-ietf-an= ima-autonomic-control-plane.txt

Quick background so you do = not need to read anything more than = 6.7.1.1.1:

 

I read = a little more. Hope you don=E2=80=99t mind.

 

The profile seems fine to me. There is one thing that = I think is missing.

 

The profile specifies that the ACP nodes should use = tunnel mode (when GRE is not used), = because:

=C2=A0=C2=A0 IPsec tunnel mode is required because =
the ACP will route/forward
=C2=A0=C2=A0 packets received from any other ACP =
node across the ACP secure
=C2=A0=C2=A0 channels, and not only its own =
generated ACP packets.=C2=A0 With =
IPsec
=C2=A0=C2=A0 transport mode, it would only be =
possible to send packets originated
=C2=A0=C2=A0 by the ACP node =
itself.

OK. When IKEv2 = is used to negotiate tunnel-mode SAs (and transport mode, but = that=E2=80=99s not important here) they need an IPsec policy that = specifies traffic selectors so that IKEv2 can specify traffic selectors. =  Nowhere in your draft do I see a specification of what traffic = selectors need to be negotiated.

 

If I understand the above paragraph correctly, both = the source of the packet and the destination can be the IP address of = any ACP node, neither of which are required to be the tunnel endpoints. =  This implies some sort of generic traffic selector.  The = draft should specify this, IMO

 

Yoav

 

------=_NextPart_000_0B81_01D5ECC6.9F1D3970-- From nobody Wed Feb 26 08:18:32 2020 Return-Path: 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 E34463A0AB0; Wed, 26 Feb 2020 08:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Jy61Q8amZSog; Wed, 26 Feb 2020 08:18:21 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 1174F3A0A1F; Wed, 26 Feb 2020 08:18:20 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 48SLZL0BFvzKGd; Wed, 26 Feb 2020 17:18:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1582733898; bh=lQO8y5c7z52FodeQTooUOvvQ7iIQd6o5GrA8oY0X3PM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=crcRW4BKXVjKI/vbSx2GzDFkJ8+f3MB7GpzzOt8Vi4gXTw6MJO98/5aQv6738/NKo zrDzDl6KkQx1SvlTME/QYxA8yE4FbqGVxwoMss4H5ZAELvytaR7djk/P6vS2mqa/Ca SqYF3yUGqiK3uQaZ1yI/0SbPfPuqfKjQIVCUzi5g= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id DqDAKDu4rtfk; Wed, 26 Feb 2020 17:18:17 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 26 Feb 2020 17:18:17 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E08456029B99; Wed, 26 Feb 2020 11:18:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DF7A4669C5; Wed, 26 Feb 2020 11:18:15 -0500 (EST) Date: Wed, 26 Feb 2020 11:18:15 -0500 (EST) From: Paul Wouters To: Michael Richardson cc: Yoav Nir , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org, Toerless Eckert In-Reply-To: <23402.1582670650@localhost> Message-ID: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 16:18:30 -0000 On Tue, 25 Feb 2020, Michael Richardson wrote: > Yoav Nir wrote: > > The profile specifies that the ACP nodes should use tunnel mode (when > > GRE is not used), because: IPsec tunnel mode is required because the > > ACP will route/forward packets received from any other ACP node across > > the ACP secure channels, and not only its own generated ACP packets. > > It's a VTI-type interface. > The TS should be for hostA<->hostB with protocol GRE. Only if you want to create a routing based VPN. If you do a GRE tunnel, then you should really stick to transport mode plus GRE traffic selectors (assuming no NAT - if NAT is involved, transport mode should be avoided). If you do a non-GRE tunnel, then tunnel mode makes sense if you still expect trffic from other ACP nodes that need to go through the tunnel. > It could be in tunnel or transport mode. If using GRE, there is likely no need for tunnel mode. > > If I understand the above paragraph correctly, both the source of the > > packet and the destination can be the IP address of any ACP node, > > neither of which are required to be the tunnel endpoints. This implies > > some sort of generic traffic selector. The draft should specify this, > > IMO > > The GRE layer and the routing protocol would take care of the ::/0<->::/0 > needs, not IPsec. Building 0/0 to 0/0 IPsec tunnels based on routing is the least secure option you can use. So I agree here that in the GRE case, one should not build 0/0 to 0/0 IPsec policy tunnels. Paul From nobody Wed Feb 26 09:56:13 2020 Return-Path: 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 B10773A0ED5; Wed, 26 Feb 2020 09:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 8qzwFSbr-H3w; Wed, 26 Feb 2020 09:56:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F693A0ECF; Wed, 26 Feb 2020 09:56:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 12C5A38982; Wed, 26 Feb 2020 12:55:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4D5EC68B; Wed, 26 Feb 2020 12:56:08 -0500 (EST) From: Michael Richardson To: Yoav Nir cc: Toerless Eckert , "ipsec\@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 17:56:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > The draft says =E2=80=9CIPsec tunnel mode is required =E2=80=9D, so i= t=E2=80=99s not > transport. What goes in the TS payloads? TSi=3DHostA-LL/128, TSr=3DHostB-LL/128, Protocol =3D GRE(47) or IPIP(41) >> On 26 Feb 2020, at 3:20, Michael Richardson >> wrote: >> >> >>> Michael: Yoav talked about the non-GRE case. >> >> In the non-GRE case, then it's just IPIP-over-IPSEC-transport mode. >> Which is literally the VTI case. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5WsTgACgkQgItw+93Q 3WXsRwf+PYnPTdNAGl9CqBNyyndrup4O+hHhY+2wxA2VO7/1NLvLwWZb44aKBLeM c88eBbC/qg9JQHFL0s4JFtCTYEGi+IrfucQcwQImH2lsiODx6xXPaG8zRc+2b5g+ ws7t+Pozvzu/hLTtBK17Yt0gLjl5cDdkWtlaydiBybVb4cHIzVga5PNauRXzKuDP c0EWi5KpRYa4vVpOGKmwXM8QtE5+3HpDuFlzCSUuyqRgb5UUid9h3k/Iz0xcnhss GTKDBJ+BPFnUjo+bhEC/AJDygJKfCCMV9gtKsviIoDiUs9hNi80WpikpncWGrW/N BXAAw6tJqraaWoEtyg0CqGMV+QCEpQ== =i8q2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 26 12:11:10 2020 Return-Path: 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 9EB713A1376; Wed, 26 Feb 2020 12:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 N_WCRaPVOiNk; Wed, 26 Feb 2020 12:11:00 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9A6093A1349; Wed, 26 Feb 2020 12:11:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 48SRkp68sbzKH9; Wed, 26 Feb 2020 21:10:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1582747858; bh=7wszjncCHzZRoARUboAq5kAl1rVxAA2FwVaZSuTrbqs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=P3zs5ekWQBkI27mhiVK5wnhHTYiL7aRWh/ZTUh4khjhHM5FV4qwHU4lfDr6BpZ9XQ rpbtf0x7pTkJe9NZtZINsKvsiSRk2B4bAUqAXbnRJohYGUzIFA4lfriLlceTdQ+JSp sQ6AqgZ8sXxHeCIongks4iHU2W7OI2k9V3SZ2i0Y= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YLsdnNqOSfaX; Wed, 26 Feb 2020 21:10:57 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 26 Feb 2020 21:10:57 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 011ED602980C; Wed, 26 Feb 2020 15:10:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F17C9384C6; Wed, 26 Feb 2020 15:10:55 -0500 (EST) Date: Wed, 26 Feb 2020 15:10:55 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'Yoav Nir' , 'Toerless Eckert' , ipsec@ietf.org, 'Michael Richardson' , draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> Message-ID: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:11:09 -0000 On Wed, 26 Feb 2020, Valery Smyslov wrote: > 1. The >    Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be >    supported.  See [IKEV2IANA] for this and other IANA IKEv2 parameter >    names used in this text. >   >     “PKCS #7 wrapped X.509 certificate” certificate encoding is deprecated and is not used in IKEv2 >      (see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-11). >      Generally, I see no need for the text that imposes requirements on certificate encoding at all – >      we never run into the interoperability problems with this? as far as I remember. I suggest to remove > this text. Actually we do. We had to add pkcs7 to ikev2 to be compatible with some windows deployments when intermediate certificates were being sent. On top of that, Microsoft did it wrong, as the format does not allow a chain but they added more than one anyway. So if anything, we DO NOT want to see more pkcs7 in IKEv2. > 2.   If certificate chains are used, all intermediate certificates up to, >    and including the locally provisioned trust anchor certificate MUST >    be signaled.  See Section 6.10.7 for the sub-CA example in which >    certificate chains are used. >   >     This is confusing. I read this text as the “MUST” is imposed only if >     “certificate chains are used”. Does it mean that implementations >     may skip this “MUST” if EE certificate is directly signed by CA certificate >     and there is no intermediate certificates? Or is it still a chain >     and “if” is relevant to the case when there is no CA and there is a direct trust to EE certificates >     (in which case PKI is not needed at all and you can use RAW public keys)? I agree it should not try to dictate how certificate based IKE certification works, but just reference to IKEv2 and its updates for that. >      Another point: trust anchors certificates usually are not included in CERT payload in IKEv2. >      I see draft’s a reasoning that this inclusion would allow better network debugging, >      but I’m not sure I can buy this argument. Probably more detailed >      explanation is needed. They could suggest that for easier debuggint a CERTREQ payload is included. That has the hash of the CA, which should be good enough. But again, IKEv2 already specifies this. Why is this document trying to change IKEv2 certificate processing? > 3.   IKEv2 authentication MUST use authentication method 14 ("Digital >    Signature") for ACP certificates; this authentication method can be >    used with both RSA and ECDSA certificates, as indicated by a PKIX- >    style OID. >   >     I think it’s better to rephrase this more accurately: “indicated by an ASN.1 object > AlgorithmIdentifier” Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo (SPKI) ASN.1 object" ? Paul From nobody Wed Feb 26 12:20:22 2020 Return-Path: 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 EC3DE3A1382; Wed, 26 Feb 2020 12:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 Wy5fTC8z97GZ; Wed, 26 Feb 2020 12:20:17 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88D3E3A1371; Wed, 26 Feb 2020 12:20:17 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F091138982; Wed, 26 Feb 2020 15:19:14 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4E95068B; Wed, 26 Feb 2020 15:20:16 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org In-Reply-To: References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 20:20:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > I agree it should not try to dictate how certificate based IKE > certification works, but just reference to IKEv2 and its updates for > that. +1 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Another point: trust anchors certifica= tes usually are not >> included in CERT payload in IKEv2. =C2=A0=C2=A0=C2=A0=C2=A0 I see d= raft=E2=80=99s a reasoning >> that this inclusion would allow better network debugging, =C2=A0=C2= =A0=C2=A0=C2=A0 but I=E2=80=99m >> not sure I can buy this argument. Probably more detailed =C2=A0=C2= =A0=C2=A0=C2=A0 >> explanation is needed. > They could suggest that for easier debuggint a CERTREQ payload is > included. That has the hash of the CA, which should be good enough. > But again, IKEv2 already specifies this. Why is this document trying = to > change IKEv2 certificate processing? By construction, all the certificates in the ACP should be from the same CA. But, there may be edges that connect to other domains (ISP peering points, for instance), and it could be that they attempt to connect. That ought to= fail. What I want, is the knowledge of what the anchors were. I agree, we could instead include a CERTREQ. >> 3.=C2=A0=C2=A0 IKEv2 authentication MUST use authentication method 1= 4 ("Digital >> =C2=A0=C2=A0 Signature") for ACP certificates; this authentication m= ethod can be >> =C2=A0=C2=A0 used with both RSA and ECDSA certificates, as indicated= by a PKIX- >> =C2=A0=C2=A0 style OID. =C2=A0 =C2=A0=C2=A0=C2=A0 I think it=E2=80= =99s better to rephrase this more >> accurately: =E2=80=9Cindicated by an ASN.1 object AlgorithmIdentifie= r=E2=80=9D > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyIn= fo > (SPKI) ASN.1 object" ? I have no opinion here. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl5W0wAACgkQgItw+93Q 3WVQhAf/WHQUTQzpZv3fo6rU1Qg4xGLjb+8S+wqAFO4pxLHLMmUtzCwn3OSHiGxi vI+susR8q8IxNfzHxi4yRwmKIHp94OY9yzfnW1da/V+9k+sAwJZwC+oEj3stIx9f 5piY/f2mSW8cB3TPKY8W5RSVUnJU6FCy0cOOTwV6zWUxVHKNZPmqINPDC3zvvqPV HUV0q6vEv+sAlsLzIuYicJTBDSNaJ/hpPN29S1nF5fNbiojNKtNtUJ+0a6IfxWFc unBc556IN3iWuJepAqdcJJvg7Y/VBAKNnoaox+L1TOyguWg/VCtZMoMFr5ltRxsB B9UasNKnUwyScmrJelZzb6lZG3VgoQ== =WXFy -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 26 14:42:05 2020 Return-Path: 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 904F73A0978; Wed, 26 Feb 2020 14:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=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 asSgikd8wbqq; Wed, 26 Feb 2020 14:42:02 -0800 (PST) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 3E3633A0989; Wed, 26 Feb 2020 14:42:02 -0800 (PST) Received: by mail-wr1-x42a.google.com with SMTP id z15so883410wrl.1; Wed, 26 Feb 2020 14:42:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fv/Uj8gHSoTVYru5nw6jYLDXtyZXfSfXBDhFUZ5BrJ0=; b=hr9xbPL7P+IMjyd8pOLppSUWZk9rKJPugULyYwbnYWwIUb5kdIdtLFHewZpzr5jO1K 1KP5+yrw5OClSYRgQFeLMbzT3oDFRSpuSX7xKsrN+hnIuwKxPNNekzuWg7VlvWags18n GqYYAd7+JZrN1VcEDpIorDt7bUCqa/0Q36BotNxUhLezEn88rGWipYjLZenWV9RY8AsK MWYnBMaffW2x/AgIYVylIgoTlt4RNFeJ7K3aSe5wcoT2QbvZsrrHTUae2ZxLjQG5jxh/ NJiW8sCnl5JD7vOIauHYIxBFFf0P26Y7dP32nNXemNQtKp7GTksBHWQWu0xeFZVNXN67 XlYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fv/Uj8gHSoTVYru5nw6jYLDXtyZXfSfXBDhFUZ5BrJ0=; b=gsfY0Nja8dtB+gtaGPiLK96cM2zDU7gwRfILVXdFAZD6dhz5HgNGKSATUcY9ADSH0h aI5dbV5t3MIFSUAlR2PXw0YMz8vGwpbrxlaPRJg9aOMHRyOrvq2Hvp0drSMsJ2lB5RMA krh07YH7X87OinOZwxwYEcZ9cIRGbMHZHTcikeNWRevPJJZwA25UjkxUZF4YOHu6H9PQ 0aFJYyb1DTefLqWRB6gpHhhl9J3gHKFObi7JDsCxdq8zwBOn4Tb3ClAkjDLFBIKKagSs ryM1r4bbJX+/wPvr9MtQOLdgbNut5j+Yvb+SYBB4y+RGinBz7anuv2c5EPh2vTOMZTOO nvbA== X-Gm-Message-State: APjAAAV7T0IAboglhgVROF7/4yETOPC6dpX/ycDtmTMu+mD3o2Y2IDsC GPCgpcDlRFxc1dYxYubgWE8= X-Google-Smtp-Source: APXvYqw/c4CNAILlFYbxfcVCKe/Nyh9KpMDN5qKT2Qz/TgPUM0YseTyEJ96wqy/fttbcFFBbsIwGRQ== X-Received: by 2002:adf:eb48:: with SMTP id u8mr826080wrn.283.1582756920786; Wed, 26 Feb 2020 14:42:00 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id h13sm5762589wrw.54.2020.02.26.14.41.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 14:41:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Yoav Nir In-Reply-To: <27926.1582739768@localhost> Date: Thu, 27 Feb 2020 00:41:55 +0200 Cc: Toerless Eckert , "ipsec@ietf.org WG" , draft-ietf-anima-autonomic-control-plane@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E1FEB34-E329-4686-80CE-0DFE253409C2@gmail.com> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <23402.1582670650@localhost> <20200226000318.GJ39574@faui48f.informatik.uni-erlangen.de> <31896.1582680023@localhost> <8A7ABA50-0ACB-41A2-9AE5-4EE15DB86F3A@gmail.com> <27926.1582739768@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:42:04 -0000 > On 26 Feb 2020, at 19:56, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> The draft says =E2=80=9CIPsec tunnel mode is required =E2=80=9D, so = it=E2=80=99s not >> transport. What goes in the TS payloads? >=20 > TSi=3DHostA-LL/128, TSr=3DHostB-LL/128, Protocol =3D GRE(47) or = IPIP(41) If that=E2=80=99s the intention, I don=E2=80=99t see why this should be = tunnel mode. Both GRE and IPIP are tunnels, and they do not require ESP = tunnel mode to add yet another IP header. Yoav From nobody Thu Feb 27 00:58:56 2020 Return-Path: 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 7CFC53A1587; Thu, 27 Feb 2020 00:58:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hBjlgzS0f7Vi; Thu, 27 Feb 2020 00:58:54 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 D5EAD3A1585; Thu, 27 Feb 2020 00:58:53 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id r14so1483979lfm.5; Thu, 27 Feb 2020 00:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=tgAW6hibomdYWfZc9jtWIS9cPY39LDjpriz/WR0638s=; b=KlUxhi35khvV72X/7CfdntcdUoL6zyk4W2jGph2uRijYb+SsXl5ODZqefrHED1TaHO LXVUBEbSFhMEpj2oJbpLlH2KgyHaP9aaiP56A7K1xC02EGvXrt2kwtyBcuhqoiC+mb7Y meiashAXgWDm30yp7fw/jnnoy8wxeBj32iNKOMqxIrQcafzyfvgxblxuZfP2v4FdMce8 5UajPHzq+P5CBCNvTJdborFjS7ZfTPVkIG2DAap+Pdb5fbbnJAHACf5VVX6SVMvOA80E XEEoll4C0G3FDimY5uPEOF36KDhlcIVKPQQ8EOat8c31RM0ipUqbE9HdatTQIH5SFT8t VUJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=tgAW6hibomdYWfZc9jtWIS9cPY39LDjpriz/WR0638s=; b=tpt16+U6+ZLe9gXToICyqPCCKr/AW5V0BIlil3Sxsx0H4HpQmhwb44b3q0dbmNPYqY ez6wyJueCcEepnPGGVsOHfxzXQ8vCGpGVKRoLbHjcyTqTFTcTmH+9DdCdF4sAcE1SMij Na3GTQ3xstlttZ7fpKg0Sc1vnhXQsrUQ+Hk5TUonMWABC1FHgtTsuVrr9I+bv74IHP/y dzGA8E2UF/C8qFwB9PMXZLKpGHxRjU0+NxyPMNXEYLnmNa9S6f99MCKgKbsgDRH7FHwj kq/6uLufg00S7NpUkRoD/npg/q/cCpeWG3cxa03uA7n94HGrwXpFuEMA0884l9pRLxEY yAuA== X-Gm-Message-State: ANhLgQ3rlywTc4S5GMJ2ElYJL0lBjjO78Lqh6GfwzWNBiJmYLZLHTnXq XMPcWY+GrX/gEgmZCw+T5iP1M7jG X-Google-Smtp-Source: ADFU+vvyRHoobv7an0CqEJkXaqA0hX8nLJMGHe8ptxgzt0rMnJr9u6VuTf/npPgBrKtDOZ3nZyuCgw== X-Received: by 2002:a19:c34d:: with SMTP id t74mr1514573lff.197.1582793931629; Thu, 27 Feb 2020 00:58:51 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g28sm2357951lfj.71.2020.02.27.00.58.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Feb 2020 00:58:50 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Yoav Nir'" , "'Toerless Eckert'" , , "'Michael Richardson'" , References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> In-Reply-To: Date: Thu, 27 Feb 2020 11:58:53 +0300 Message-ID: <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMQRTEh8jiXoowGsPdFJKCFNOl05wMD9EZlAcKt9BsCbOJ5MKWAZ9kg Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 08:58:56 -0000 Hi Paul, > > 1. The > > Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST = be > > supported. See [IKEV2IANA] for this and other IANA IKEv2 = parameter > > names used in this text. > > > > =E2=80=9CPKCS #7 wrapped X.509 certificate=E2=80=9D certificate = encoding is deprecated and is not used in IKEv2 > > (see = https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#= ikev2-parameters- > 11). > > Generally, I see no need for the text that imposes requirements = on certificate encoding at all =E2=80=93 > > we never run into the interoperability problems with this? as = far as I remember. I suggest to remove > > this text. >=20 > Actually we do. We had to add pkcs7 to ikev2 to be compatible with = some > windows deployments when intermediate certificates were being sent. On > top of that, Microsoft did it wrong, as the format does not allow a > chain but they added more than one anyway. So if anything, we DO NOT > want to see more pkcs7 in IKEv2. We do support PKCS#7 too, but officially it's not specified for IKEv2 = and thus must not be specified in the profile.=20 > > 2. If certificate chains are used, all intermediate certificates = up to, > > and including the locally provisioned trust anchor certificate = MUST > > be signaled. See Section 6.10.7 for the sub-CA example in which > > certificate chains are used. > > > > This is confusing. I read this text as the = =E2=80=9CMUST=E2=80=9D is imposed only if > > =E2=80=9Ccertificate chains are used=E2=80=9D. Does it mean that = implementations > > may skip this =E2=80=9CMUST=E2=80=9D if EE certificate is = directly signed by CA certificate > > and there is no intermediate certificates? Or is it still a = chain > > and =E2=80=9Cif=E2=80=9D is relevant to the case when there is = no CA and there is a direct trust to EE certificates > > (in which case PKI is not needed at all and you can use RAW = public keys)? >=20 > I agree it should not try to dictate how certificate based IKE > certification works, but just reference to IKEv2 and its updates for > that. That was my point :-) > > Another point: trust anchors certificates usually are not = included in CERT payload in IKEv2. > > I see draft=E2=80=99s a reasoning that this inclusion would = allow better network debugging, > > but I=E2=80=99m not sure I can buy this argument. Probably more = detailed > > explanation is needed. >=20 > They could suggest that for easier debuggint a CERTREQ payload is > included. That has the hash of the CA, which should be good enough. > But again, IKEv2 already specifies this. Why is this document trying > to change IKEv2 certificate processing? Agree. > > 3. IKEv2 authentication MUST use authentication method 14 = ("Digital > > Signature") for ACP certificates; this authentication method can = be > > used with both RSA and ECDSA certificates, as indicated by a = PKIX- > > style OID. > > > > I think it=E2=80=99s better to rephrase this more accurately: = =E2=80=9Cindicated by an ASN.1 object > > AlgorithmIdentifier=E2=80=9D >=20 > Wouldn't it be more correct to say "indicated by a = SubjectPublicKeyInfo > (SPKI) ASN.1 object" ? No, as far as I understand the text, it tells that the particular signing algorithm is indicated in the AUTH payload by inclusion its OID. = That's partially true, it is indicated by inclusion AlgorithmIdentifier = ASN.1 object=20 (and not SubjectPublicKeyInfo or pure OID). It's probably better to just delete the text in the last sentence "as = indicated by a PKIX-style OID". Regards, Valery. > Paul From nobody Thu Feb 27 10:32:42 2020 Return-Path: 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 F3DD43A0807; Thu, 27 Feb 2020 10:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 NXdHH0M3eDVs; Thu, 27 Feb 2020 10:32:31 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36B293A07D0; Thu, 27 Feb 2020 10:32:30 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7FAAB548005; Thu, 27 Feb 2020 19:32:25 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 797F6440040; Thu, 27 Feb 2020 19:32:25 +0100 (CET) Date: Thu, 27 Feb 2020 19:32:25 +0100 From: 'Toerless Eckert' To: Valery Smyslov Cc: 'Paul Wouters' , ipsec@ietf.org, 'Michael Richardson' , 'Yoav Nir' , draft-ietf-anima-autonomic-control-plane@ietf.org Message-ID: <20200227183225.GP39574@faui48f.informatik.uni-erlangen.de> References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 18:32:40 -0000 Thanks. I think ACP has no specific encoding preference for the exchanged certificates, but we do of course MUST support BRSKI enrolled certificate (chains), and i think PKS#7 is MTI there (Michael ?). Can PKS#7 certificate chains be converted locally into any potential other possible IKEv2 supported encoding format ? Then i think ACP is open to pick any encoding you could suggest to us. Othewise PKCS#7 is the safe ACP requirement. More inline. On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote: > Hi Paul, > > > > 1. The > > > Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be > > > supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter > > > names used in this text. > > > > > > ???PKCS #7 wrapped X.509 certificate??? certificate encoding is deprecated and is not used in IKEv2 > > > (see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters- > > 11). > > > Generally, I see no need for the text that imposes requirements on certificate encoding at all ??? > > > we never run into the interoperability problems with this? as far as I remember. I suggest to remove > > > this text. > > > > Actually we do. We had to add pkcs7 to ikev2 to be compatible with some > > windows deployments when intermediate certificates were being sent. On > > top of that, Microsoft did it wrong, as the format does not allow a > > chain but they added more than one anyway. So if anything, we DO NOT > > want to see more pkcs7 in IKEv2. > > We do support PKCS#7 too, but officially it's not specified for IKEv2 and > thus must not be specified in the profile. Ok. Great. I read this as you think this requirement is necessary to ensure peers can interoperate in exchaning their cert chains during IKEv2. > > > 2. If certificate chains are used, all intermediate certificates up to, > > > and including the locally provisioned trust anchor certificate MUST > > > be signaled. See Section 6.10.7 for the sub-CA example in which > > > certificate chains are used. > > > > > > This is confusing. I read this text as the ???MUST??? is imposed only if > > > ???certificate chains are used???. Does it mean that implementations > > > may skip this ???MUST??? if EE certificate is directly signed by CA certificate > > > and there is no intermediate certificates? Or is it still a chain > > > and ???if??? is relevant to the case when there is no CA and there is a direct trust to EE certificates > > > (in which case PKI is not needed at all and you can use RAW public keys)? > > > > I agree it should not try to dictate how certificate based IKE > > certification works, but just reference to IKEv2 and its updates for > > that. > > That was my point :-) There are two things here: -> Originally i wrote the text without need to include TA in the signaled cert chain. Reason: I worked with IPsc implementations that did not signal/verify cert chains, and i also think to remember that i discussed and was told that the specs do not mandate this, so that behavor was a valid option. If you can confirm, that compliance with IKEv2 MANDATES the need to signal cert chain (eg: through MUST in one of the MANDATORY normative PKI references), then i could remove the text if we wanted just to have "standard behavior". -> Michael wanted the additional signaling of the TA for diagnostic purposes. When this was added, the original text was not correctly adjusted, so now it sounds as if this all only applies IF there is more than the node cert and a root (no intermediate CA). That of course is wrong. We would always want to signal the cert chain including TA (remove "if..." condition). > > > Another point: trust anchors certificates usually are not included in CERT payload in IKEv2. > > > I see draft???s a reasoning that this inclusion would allow better network debugging, > > > but I???m not sure I can buy this argument. Probably more detailed > > > explanation is needed. > > > > They could suggest that for easier debuggint a CERTREQ payload is > > included. That has the hash of the CA, which should be good enough. > > But again, IKEv2 already specifies this. Why is this document trying > > to change IKEv2 certificate processing? > > Agree. It seems to me as if standard cert processing is primarily concerned with the minimum mandatory signaling for security. Maybe there is even the thinking that its a possible security feature that if you don't know the TA hash, you can not learn the TA cert. In the case of ACP, we do not care about such possible strange TA cert hiding security feature. An ACP can potentially have a bunch of TAs, for example under mergers & aquisitions. And especially if BRSKI is not used, these may be provisioned by all type of flawed mechanisms, like broken SDN controllers. Or incorrectly refreshed. Just think of the simple local diagnostics when a peer fails to connect and it for example has the correct TA, but unfortunately an expired cert for it. TA cert hash mismatch, but easily diagnosed when the TA cert iss signaled. Without having to go to a possible non-existant archive of prior TE certs from a company just aquired 9 months ago, where ACPs where merged. > > > 3. IKEv2 authentication MUST use authentication method 14 ("Digital > > > Signature") for ACP certificates; this authentication method can be > > > used with both RSA and ECDSA certificates, as indicated by a PKIX- > > > style OID. > > > > > > I think it???s better to rephrase this more accurately: ???indicated by an ASN.1 object > > > AlgorithmIdentifier??? > > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo > > (SPKI) ASN.1 object" ? > > No, as far as I understand the text, it tells that the particular > signing algorithm is indicated in the AUTH payload by inclusion its OID. > That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 object > (and not SubjectPublicKeyInfo or pure OID). > > It's probably better to just delete the text in the last sentence "as indicated by a PKIX-style OID". ;-) Going once, going twice ? ... If not, i'll follow this advice Thanks! Toerless > Regards, > Valery. > > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Feb 27 23:52:14 2020 Return-Path: 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 3CAC53A1261; Thu, 27 Feb 2020 23:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 wQICSnutGzcu; Thu, 27 Feb 2020 23:52:04 -0800 (PST) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 702483A126B; Thu, 27 Feb 2020 23:52:03 -0800 (PST) Received: by mail-wm1-x331.google.com with SMTP id n64so828615wme.3; Thu, 27 Feb 2020 23:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=WUtLPJLzjufW1qhRbQOUCPWhTTmzHi27ARWLIY9VW0k=; b=gk9toHWOO8SQnbpCI5xqZETKjwINezaM6Irp9GL38ISSswAA8ZL86pInpkbvHjYn/i AdtLN509ut2dGLmXg30wlNhwvrarg3QVMDrmFuY8GXVUgTdu8PuUW80UDr1iNfX28jtn ysw2DNannAL7GdlCZwl61wnblJh7Sh0P01mGuhrY8fE5MUKvuO8kMRk+IVP4cTz4vVwp UPwFlEF/ifF/OFWMDqtS2ZNM7P6No8zCMViBO1Gg7MbdFxK0wJH5f+X4VwcvtiOJIauN JxE505vKweu8nzbpy7X0VzAsH8vRmfXNK2zpDo93mz3QTvXuqcJ7KZ0q32d0jWoKWA/N zXFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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=WUtLPJLzjufW1qhRbQOUCPWhTTmzHi27ARWLIY9VW0k=; b=dgWKnYZVXq+zKvOkH8ExnY5T9m5Z8BMDm/CduxC66r+dospJ0uz4hMlyZZxIb49BTN RgZrmlzdEqZ3g+uIIN/ocJLSFq9PkFkYxwiW1UA2Whn0GTFyu6jQDONyI6XuvmHA+wL0 je7aErrf8kNU8fk5F0urE0nYU4Q4D1iHEi1R6QOWOalLbKr59U6y6K2UOJ/Yae2KvT28 xz1sUOqDAaRqYYJt00LQQ+8lgMulWiZ4MgR8mvw/AlVg5/OFb+yKzBedkFOmI9qoPcQK c8nOb+g8xuy0e2EfpGtDPcaxE25pyYVqsExKhwjM9xdOWEEFe//2cFAL0TJ2TonA9Gsv VBqw== X-Gm-Message-State: APjAAAVHGqw7LAkZXQCkWzF36KQKwiFyuYBj0wj0jw6HYsJP4Gdo5TH8 dwMeLZKxSwo9w5gf44k6OwY4KmmT X-Google-Smtp-Source: APXvYqyuo1gUMGeGdqRcf6PkGGEJU95KeHI4Gi/ruXN/qDkuVoWbS6+24zlFwEsWxQm5yySrUSmwlw== X-Received: by 2002:a05:600c:22d3:: with SMTP id 19mr3435824wmg.20.1582876320389; Thu, 27 Feb 2020 23:52:00 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e22sm990052wme.45.2020.02.27.23.51.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Feb 2020 23:51:59 -0800 (PST) From: "Valery Smyslov" To: "'Toerless Eckert'" Cc: "'Paul Wouters'" , , "'Michael Richardson'" , "'Yoav Nir'" , References: <20200224195013.GA3878@faui48f.informatik.uni-erlangen.de> <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200227183225.GP39574@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200227183225.GP39574@faui48f.informatik.uni-erlangen.de> Date: Fri, 28 Feb 2020 10:52:02 +0300 Message-ID: <0e5f01d5ee0b$f77182c0$e6548840$@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: AQMQRTEh8jiXoowGsPdFJKCFNOl05wMD9EZlAcKt9BsCbOJ5MAG4ZZ1EAjNLfe+lYnSfMA== Content-Language: ru Archived-At: Subject: Re: [IPsec] IPsec profile feedback wanted (draft autonomic control plane) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 07:52:12 -0000 Hi Toerless, > Thanks. > > I think ACP has no specific encoding preference for the > exchanged certificates, but we do of course MUST support BRSKI > enrolled certificate (chains), and i think PKS#7 is MTI there (Michael ?). > > Can PKS#7 certificate chains be converted locally into any potential > other possible IKEv2 supported encoding format ? Then i think ACP > is open to pick any encoding you could suggest to us. Othewise > PKCS#7 is the safe ACP requirement. I believe it's possible to convert. The encoding most widely used is "X.509 Certificate - Signature", so it's just a certificate without any envelopes. You may include as many CERT payloads as you wish, each containing a single certificate. The is also an encoding for CRLs ("Certificate Revocation List (CRL)"). But as others have already suggested, I'd rather remove all this certificates stuff from the draft and just point to the RFC7296. > More inline. > > On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote: > > Hi Paul, > > > > > > 1. The > > > > Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be > > > > supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter > > > > names used in this text. > > > > > > > > ???PKCS #7 wrapped X.509 certificate??? certificate encoding is deprecated and is not used in IKEv2 > > > > (see https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2- > parameters- > > > 11). > > > > Generally, I see no need for the text that imposes requirements on certificate encoding at all ??? > > > > we never run into the interoperability problems with this? as far as I remember. I suggest to remove > > > > this text. > > > > > > Actually we do. We had to add pkcs7 to ikev2 to be compatible with some > > > windows deployments when intermediate certificates were being sent. On > > > top of that, Microsoft did it wrong, as the format does not allow a > > > chain but they added more than one anyway. So if anything, we DO NOT > > > want to see more pkcs7 in IKEv2. > > > > We do support PKCS#7 too, but officially it's not specified for IKEv2 and > > thus must not be specified in the profile. > > Ok. Great. I read this as you think this requirement is necessary > to ensure peers can interoperate in exchaning their cert chains > during IKEv2. No, we just inherited this support from IKEv1 and didn't removed it from IKEv2 code, thus slightly violating IKEv2 spec. It's just an implementation feature and I object if any IKEv2 based profile will allow it. > > > > and including the locally provisioned trust anchor certificate MUST > > > > be signaled. See Section 6.10.7 for the sub-CA example in which > > > > certificate chains are used. > > > > > > > > This is confusing. I read this text as the ???MUST??? is imposed only if > > > > ???certificate chains are used???. Does it mean that implementations > > > > may skip this ???MUST??? if EE certificate is directly signed by CA certificate > > > > and there is no intermediate certificates? Or is it still a chain > > > > and ???if??? is relevant to the case when there is no CA and there is a direct trust to EE certificates > > > > (in which case PKI is not needed at all and you can use RAW public keys)? > > > > > > I agree it should not try to dictate how certificate based IKE > > > certification works, but just reference to IKEv2 and its updates for > > > that. > > > > That was my point :-) > > There are two things here: > > -> Originally i wrote the text without need to include TA in the > signaled cert chain. Reason: I worked with IPsc implementations > that did not signal/verify cert chains, and i also think to remember > that i discussed and was told that the specs do not mandate this, > so that behavor was a valid option. If you can confirm, that > compliance with IKEv2 MANDATES the need to signal cert chain > (eg: through MUST in one of the MANDATORY normative PKI > references), then i could remove the text if we wanted just to > have "standard behavior". > > -> Michael wanted the additional signaling of the TA for diagnostic > purposes. When this was added, the original text was not correctly > adjusted, so now it sounds as if this all only applies IF there is > more than the node cert and a root (no intermediate CA). That of > course is wrong. We would always want to signal the cert chain > including TA (remove "if..." condition). Again, as Paul and others have suggested, I'd remove all certificates-transfer-in-IKEv2 stuff from the profile and just reference RFC7296. This part of IKEv2 never caused interoperability problems (AFAIK), so I see no need to mandate IKEv2 behavior here. > > > > Another point: trust anchors certificates usually are not included in CERT payload in IKEv2. > > > > I see draft???s a reasoning that this inclusion would allow better network debugging, > > > > but I???m not sure I can buy this argument. Probably more detailed > > > > explanation is needed. > > > > > > They could suggest that for easier debuggint a CERTREQ payload is > > > included. That has the hash of the CA, which should be good enough. > > > But again, IKEv2 already specifies this. Why is this document trying > > > to change IKEv2 certificate processing? > > > > Agree. > > It seems to me as if standard cert processing is primarily concerned > with the minimum mandatory signaling for security. Maybe there > is even the thinking that its a possible security feature that if > you don't know the TA hash, you can not learn the TA cert. > > In the case of ACP, we do not care about such possible strange > TA cert hiding security feature. > > An ACP can potentially have a bunch of TAs, for example under > mergers & aquisitions. And especially if BRSKI is not used, these > may be provisioned by all type of flawed mechanisms, like broken > SDN controllers. Or incorrectly refreshed. Just think of the > simple local diagnostics when a peer fails to connect and it > for example has the correct TA, but unfortunately an expired > cert for it. TA cert hash mismatch, but easily diagnosed when the TA > cert iss signaled. Without having to go to a possible non-existant > archive of prior TE certs from a company just aquired 9 months ago, > where ACPs where merged. Well, the example you provided doesn't work. In IKEv2 first the responder sends a list of TA (hashes) he has in a CERTREQ payload. When the initiator receives it, he checks the list trying to find a corresponding TA that signed his certificate (or a chain) and if he finds one, then he sends back a bunch of his certificates starting from EE and up to (but not including) this TA. If the initiator fails to find a proper TA, then the SA fails and no more exchanges take place. If he finds one, then there is absolutely no point to send it back to the responder, as the responder has indicated already that he has it. The same happens in the opposite direction. So I still cannot buy this argument. More general thought: each side performs validation of peer's cert by his own, using his own trust assumptions. If peer sends you his TA that he will be using while validating your identity, then it sounds strange to me, because it's his trust anchor, not yours. You even cannot check whether it's expired, because peer's clock may skew from yours... Regards, Valery. > > > > 3. IKEv2 authentication MUST use authentication method 14 ("Digital > > > > Signature") for ACP certificates; this authentication method can be > > > > used with both RSA and ECDSA certificates, as indicated by a PKIX- > > > > style OID. > > > > > > > > I think it???s better to rephrase this more accurately: ???indicated by an ASN.1 object > > > > AlgorithmIdentifier??? > > > > > > Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo > > > (SPKI) ASN.1 object" ? > > > > No, as far as I understand the text, it tells that the particular > > signing algorithm is indicated in the AUTH payload by inclusion its OID. > > That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1 object > > (and not SubjectPublicKeyInfo or pure OID). > > > > It's probably better to just delete the text in the last sentence "as indicated by a PKIX-style OID". > > ;-) Going once, going twice ? ... If not, i'll follow this advice > > Thanks! > Toerless > > > Regards, > > Valery. > > > > > Paul > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Feb 28 14:38:03 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C333A1FA7; Fri, 28 Feb 2020 14:35:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292931646.19931.14477281028100220652@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:16 -0800 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 107 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:23 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30 requested) Tuesday, 24 March 2020, Afternoon Session II 1550-1720 Room Name: Georgia A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: i2nsf acme tls Technology Overlap: curdle lake cfrg saag tcpm Key Participant Conflict: uta 6lo 6tisch lwig ace People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: ---------------------------------------------------------