From nobody Tue May 1 12:28:35 2018 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 2DFF412EA7F for ; Tue, 1 May 2018 12:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 sTJhK5HGra1t for ; Tue, 1 May 2018 12:28:31 -0700 (PDT) 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 F344612EA7C for ; Tue, 1 May 2018 12:28:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40bBK91Fxdz34j; Tue, 1 May 2018 21:28:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1525202909; bh=vEYpFabdVNiV8fzsiSl64nmJbay4PLBkfp3uxRQfBHo=; h=Date:From:To:cc:Subject; b=JMie3+Sq/KIsyk7IUZdC0RuNlxGxGow4nFjLu+CambMY+/jn37ancAjYi781T1x7E tQC1UEZcB+WJdlO7Daltf3OiAsMGahOQIZOlzJ9D5qSCJls+rE7epiJzMslnaRYqMf 9v3TfmW0NidqQJyIJ2QJQcHzJcQ83/YFnEkQbWXQ= 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 u02Gui4ZEpMo; Tue, 1 May 2018 21:28:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 1 May 2018 21:28:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4F7B24AB8F2; Tue, 1 May 2018 15:28:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4F7B24AB8F2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 46EAD4095AB3; Tue, 1 May 2018 15:28:25 -0400 (EDT) Date: Tue, 1 May 2018 15:28:25 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" cc: Sahana Prasad Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 19:28:34 -0000 So during the last meeting when we discussed Labeled IPsec, a few interesting items came up: 1) Is this actually a traffic selector ? Or is it a notify? 2) Is there a use case for "narrowing" on a security label ? 3) Can or should there be different labels in different directions ? 4) Can or should there be different labels for different address families? I think whether to use a TS as part of the TSi/TSr's should follow the answers to these questions. I don't think anyone has seen a plausaible security label narrowing. It was pointed out that my example in the draft was actually incorrect. (also that things like "top secret" really should not include "secret", just like "secret" does not include "top secret"). And SElinux based labeles don't work with these kind of hierachies anyway. While there could be different labels in different directions, it hardly makes sense, for example a TCP connection. And where it might be possible, I think such an IPsec SA really conflates two different IPsec SA's. For example, a service on a port where the IPsec SA is both for incoming and outgoing connections are really two security contexts that can be split into two IPsec SAs one for client (any to port X) and one for server (port Y to any) So in a way, a NOTIFY might make sense. But then we do run the risk of an IPsec SA being installed with the notify ignored using a default security context instead of the security context required. Having it as part of the TSi/TSr payloads makes that a lot more clear. Thoughts? Paul From nobody Tue May 1 12:36:05 2018 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 ED29312EA94 for ; Tue, 1 May 2018 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 4zdPLrsYYM4u for ; Tue, 1 May 2018 12:36:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACF712EA8F for ; Tue, 1 May 2018 12:36:00 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4A3A220090 for ; Tue, 1 May 2018 15:47:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B405DBBF; Tue, 1 May 2018 15:35:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B1E86B5D for ; Tue, 1 May 2018 15:35:48 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 19:36:04 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > I think such an IPsec SA really conflates two different IPsec SA's. F= or > example, a service on a port where the IPsec SA is both for incoming = and > outgoing connections are really two security contexts that can be spl= it > into two IPsec SAs one for client (any to port X) and one for server > (port Y to any) > So in a way, a NOTIFY might make sense. But then we do run the risk of > an IPsec SA being installed with the notify ignored using a default > security context instead of the security context required. Having it > as part of the TSi/TSr payloads makes that a lot more clear. > Thoughts? It has to be a traffic selector. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWujBlICLcPvd0N1lAQJeggf/aqYxHzYyM0lavaLwLt+4AhP1B5b8Dskx Lq+KPjtopwvWmv7y9iQP2krtUediKfCD8dCxoja5MrHTOyK1ekr3VVXYaQ3CXmiX yDvLy6/hBI8kmfVeWqj9ULWPmQb61aiKZPCsP1N/sV75d8kHJGuSXepTTvevaCNk Di8s8CBvjpASgpPaydg1HtPBX+k7wJfE40fjkOm6hpHkdBulddqlq+YuasNGCxyb z/sELVtlLt6ZnnQ/nxCuYRvspf7xV12iM6Iz2NZMBRjZ/ZsIi91AxYlr5loj5Q7d oNqiVuvgbmQ9rg5i9ag3/cBuMI4W7dWIBpa3Pcz/yO3Tr0/BAFiSwg== =+d5k -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 1 13:48:53 2018 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 360F5126D0C for ; Tue, 1 May 2018 13:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 yWSEaFNyKhpU for ; Tue, 1 May 2018 13:48:50 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A101200B9 for ; Tue, 1 May 2018 13:48:50 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 1F6D9140B247; Tue, 1 May 2018 13:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=i41sorywTy872L ss7yhwGgjauLU=; b=Pl308KMaouWwE4otXfaF/iUNFxER3pAsZHO6EZTnNRRMnn gPzA6c1XTy9uVjjoJDrkNOoDr+Icaam2HxP9JthpPlYehOM2jk/ZhWkkMSZ8ipvR ebnDFlXy7WOXoVUlfQLPVpwHhHw4mU8HYO2GE0gNZLZTwrDwUbHBV+kxqKHUY= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 86157140B245; Tue, 1 May 2018 13:48:48 -0700 (PDT) Date: Tue, 1 May 2018 15:47:16 -0500 From: Nico Williams To: Paul Wouters Cc: "ipsec@ietf.org WG" , Sahana Prasad Message-ID: <20180501204714.GQ25259@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:48:52 -0000 On Tue, May 01, 2018 at 03:28:25PM -0400, Paul Wouters wrote: > Thoughts? The following apply only to transport mode. However, a lot of this generalizes to gateway uses as well. - IPsec "state" should be more tightly bound to ULP state (PCBs) See RFC 5660 (by yours truly). For a TCP connection (or a BSD-style "connected" UDP socket) the IPsec state that should be bound with/into the PCB: - local name (from the IKE credentials) - peer name (from its IKE credentials) - protection level (transforms) - labeling For an outgoing packet the ULP should ensure that ESP will pick a suitable IPsec SA. For an incoming packet the ULP should discard any where the SA used to protect it does not satisfy the bindings listed above. The bindings need to be established in some way. Basically they should be taken from: - optional socket options - parameters of the first IKE SA to yield the child SAs needed to protect the flow's packets - Given this, labels can be carried in any of the following places: - IKE credentials (e.g., certificate extensions, side lookups, ...) - transported as IKE traffic selectors (these could only carry narrow labels than those of the credentials used to negotiate the IKE SAs, if any) - transported as TCP options in a SYN or SYN+ACK (these could only carry narrow labels than those of the SAs used to protect the flow, if any) All three should be supported. If some ULP cannot support label assertions, then when it needs a narrower label it should use narrowed SA pairs. - There's two kinds of labeling: - assertions of label by the sender for some packet / packet flow Such an assertion carried as a TCP option, for example, would be dominated by the labels (if any) from the IKE negotiation, but could still further constrain what can be sent on a specific connection. - labels limiting what will be accepted for some packet / packet flow Socket options should support: - setting acceptable transforms (ciphers, ...) - setting acceptable label ranges for the peer (for clients and servers) - setting a label for a connect() (client-only) - setting credentials to be used for the local side - setting the expected name of a peer - retrieving the actually bound IPsec parameters for a connection: - the local and peer names, including, preferably, all public parts of their credentials (e.g., certificates) - transforms - effective label We should also construct a way to agree on and compute unique channel bindings data for a connection. But this is not related to labeling. And we should construct end-point channel bindings from the local and peer names. Also not related to labeling. Nico -- From nobody Tue May 1 21:00:37 2018 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 DF4A0126CBF for ; Tue, 1 May 2018 21:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 TqFmVKd8oEuv for ; Tue, 1 May 2018 21:00:33 -0700 (PDT) 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 9C0A1120727 for ; Tue, 1 May 2018 21:00:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40bPgz0433z366; Wed, 2 May 2018 06:00:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1525233631; bh=vytdrMHdAT1N+DnOjsZahaeyjAgGzdireELwaWBORyI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jCgCw33jOVvUxvRmHjQZsrGBo4lIDWs73eblDRYGq9z5JjGkUKeMOvAXNHopz+D1q Juyz0oZ9v32uKzkYlL33GlU2jUrs8QnEhngh0y1gHvMrIV5KBQBKzTU51Zltvnvtfv trOZr7UVJsQDHTDjlvbBld1fHjMtNgAFjILtKhgU= 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 nsQ04Jn1wJVj; Wed, 2 May 2018 06:00:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 May 2018 06:00:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DA6C84AB8F3; Wed, 2 May 2018 00:00:26 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DA6C84AB8F3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CE01940C1038; Wed, 2 May 2018 00:00:26 -0400 (EDT) Date: Wed, 2 May 2018 00:00:26 -0400 (EDT) From: Paul Wouters To: Nico Williams cc: "ipsec@ietf.org WG" , Sahana Prasad In-Reply-To: <20180501204714.GQ25259@localhost> Message-ID: References: <20180501204714.GQ25259@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 04:00:36 -0000 On Tue, 1 May 2018, Nico Williams wrote: > The following apply only to transport mode. However, a lot of this > generalizes to gateway uses as well. > > - IPsec "state" should be more tightly bound to ULP state (PCBs) For the implementation I'm working with (Linux with SElinux) we already have the selinux label as part of the ACQUIRE message. So I don't think there is a problem there. The input to the IKE daemon is the trigger packet including its security context/label. Also, the security context/label is part of the SAD/SPD as a selector item as well. > - There's two kinds of labeling: > > - assertions of label by the sender for some packet / packet flow > > Such an assertion carried as a TCP option, for example, would be > dominated by the labels (if any) from the IKE negotiation, but > could still further constrain what can be sent on a specific > connection. > > - labels limiting what will be accepted for some packet / packet > flow I'm not sure how this relates here. There is of course a relationship between the packet being created with the proper security context on decryption, and there is the SPD entry that requires a packet to have a certain security context/label before it matches to get encrypted. These are all simple entries in tables with exact matching on the security context/label. These are usually (always?) the same label in both directions. > Socket options should support: I don't think I need to be at the socket level for this. Whatever userland does to give or not give a packet a security context/label is up to the system or application. To me it only becomes interesting once it reaches an SPD in the kernel where it generates an ACQUIRE or is (or is not) selected for encryption. The question that I still don't feel your email answered is, should this be a traffic selector kind or a notify message? I have heard arguments both ways but I don't yet the WG having a clear preference for one or the other based on some technical aspect. Paul From nobody Tue May 1 23:16:00 2018 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 B463E12D86A for ; Tue, 1 May 2018 23:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 y7aLFq6rFZPr for ; Tue, 1 May 2018 23:15:58 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CB7127698 for ; Tue, 1 May 2018 23:15:58 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 4FA6DC002835; Tue, 1 May 2018 23:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=p7nRAbTbL70ye1 XLtRYl2ERpO3k=; b=dOejGWSq2FJir06UtWH365gfw8kptDi71zgiSlVbg3dcDI n8g3gydAClKQm6u86Hy5pj3cYavbdcTjCQ+OsEhtMrCQIC73dqVXPLxoZPxJtfuG //+XyLCtbxxKnwMdKjZo8+irq8voE4Rh/Xpdp/+zoGAa96I1qQs7vU6FEzFsE= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id DF415C002833; Tue, 1 May 2018 23:15:29 -0700 (PDT) Date: Wed, 2 May 2018 01:07:20 -0500 From: Nico Williams To: Paul Wouters Cc: "ipsec@ietf.org WG" , Sahana Prasad Message-ID: <20180502060639.GR25259@localhost> References: <20180501204714.GQ25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 06:16:00 -0000 On Wed, May 02, 2018 at 12:00:26AM -0400, Paul Wouters wrote: > On Tue, 1 May 2018, Nico Williams wrote: > > >The following apply only to transport mode. However, a lot of this > >generalizes to gateway uses as well. > > > >- IPsec "state" should be more tightly bound to ULP state (PCBs) > > For the implementation I'm working with (Linux with SElinux) we already > have the selinux label as part of the ACQUIRE message. So I don't think > there is a problem there. The input to the IKE daemon is the trigger > packet including its security context/label. > > Also, the security context/label is part of the SAD/SPD as a selector > item as well. If you're not doing transport mode, then.. you can keep doing what everyone always does: rely entirely on IPsec configuration. It's tricky though. If you have PAD entries that allow a range of IDs to claim addresses from the same address ranges, then any one of those peers can take over any of the others' flows with you if then can DoS the victims off the network and then claim their addresses. In practice this is a very common configuration. > >- There's two kinds of labeling: > > > > - assertions of label by the sender for some packet / packet flow > > > > Such an assertion carried as a TCP option, for example, would be > > dominated by the labels (if any) from the IKE negotiation, but > > could still further constrain what can be sent on a specific > > connection. > > > > - labels limiting what will be accepted for some packet / packet > > flow > > I'm not sure how this relates here. There is of course a relationship > between the packet being created with the proper security context on > decryption, and there is the SPD entry that requires a packet to have > a certain security context/label before it matches to get encrypted. > These are all simple entries in tables with exact matching on the > security context/label. Without connection latching you're stuck with the labels from the credentials and the IKE child SA creations. If you need to narrow a label for some flow, you also need to narrow the related SAs. > These are usually (always?) the same label in both directions. I imagine so for the child SAs of one IKE SA. But not necessarily for different child SAs of different IKE SAs that are used to protect the same flows. Your policy has to be sane to prevent that. > >Socket options should support: > > I don't think I need to be at the socket level for this. Whatever > userland does to give or not give a packet a security context/label > is up to the system or application. To me it only becomes interesting > once it reaches an SPD in the kernel where it generates an ACQUIRE > or is (or is not) selected for encryption. Q: How does an application do that without socket options? A: It edits the IPsec configuration. nuts! :) But OK, that's not for _this_ thread, so I'll shut up about it now. I mentioned connection latching in the hopes of getting implementors interested :) > The question that I still don't feel your email answered is, should > this be a traffic selector kind or a notify message? I have heard > arguments both ways but I don't yet the WG having a clear preference > for one or the other based on some technical aspect. It has to be a TS. You need to be able to specify that the labels on the SAs must dominate the labels on the flows. To do this you must treat the labels as traffic selectors. A label assertion carried in an ULP, on the other hand, wouldn't be a TS at all. That's why I mentioned them. Nico -- From nobody Wed May 2 08:31:20 2018 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 E3C5B1243F6 for ; Wed, 2 May 2018 08:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 l6-g-bhNhAtG for ; Wed, 2 May 2018 08:31:16 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189F51267BB for ; Wed, 2 May 2018 08:31:16 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 64EDF30001A23 for ; Wed, 2 May 2018 08:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= resent-from:resent-date:resent-message-id:resent-to:date:from:to :cc:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=p7nRAbTbL70ye1XLtRYl2ERpO3k =; b=KQNIHSjhCN8ftiiAr+JF8jxAHhafCBCuwX8kGJk23Ijo1WKf+rdQLvdyNfH Cif4UDtJhiSgX2Cm8mWHjIZu8rR+YmvUkNJJW9juFq9z+qOJ6dJ5AtJB/yCT/9XW nMhxCD2WO3h2Kvk8F0f9FksTCLCgBkVfUzacV2u8j2ZInLGs= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPSA id 3804830001A22 for ; Wed, 2 May 2018 08:31:15 -0700 (PDT) Resent-From: Nico Williams Resent-Date: Wed, 2 May 2018 10:14:49 -0500 Resent-Message-ID: <20180502151449.GA4242@localhost> Resent-To: ipsec@ietf.org Date: Wed, 2 May 2018 01:07:20 -0500 From: Nico Williams To: Paul Wouters Cc: "ipsec@ietf.org WG" , Sahana Prasad Message-ID: <20180502060639.GR25259@localhost> References: <20180501204714.GQ25259@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 15:31:19 -0000 On Wed, May 02, 2018 at 12:00:26AM -0400, Paul Wouters wrote: > On Tue, 1 May 2018, Nico Williams wrote: > > >The following apply only to transport mode. However, a lot of this > >generalizes to gateway uses as well. > > > >- IPsec "state" should be more tightly bound to ULP state (PCBs) > > For the implementation I'm working with (Linux with SElinux) we already > have the selinux label as part of the ACQUIRE message. So I don't think > there is a problem there. The input to the IKE daemon is the trigger > packet including its security context/label. > > Also, the security context/label is part of the SAD/SPD as a selector > item as well. If you're not doing transport mode, then.. you can keep doing what everyone always does: rely entirely on IPsec configuration. It's tricky though. If you have PAD entries that allow a range of IDs to claim addresses from the same address ranges, then any one of those peers can take over any of the others' flows with you if then can DoS the victims off the network and then claim their addresses. In practice this is a very common configuration. > >- There's two kinds of labeling: > > > > - assertions of label by the sender for some packet / packet flow > > > > Such an assertion carried as a TCP option, for example, would be > > dominated by the labels (if any) from the IKE negotiation, but > > could still further constrain what can be sent on a specific > > connection. > > > > - labels limiting what will be accepted for some packet / packet > > flow > > I'm not sure how this relates here. There is of course a relationship > between the packet being created with the proper security context on > decryption, and there is the SPD entry that requires a packet to have > a certain security context/label before it matches to get encrypted. > These are all simple entries in tables with exact matching on the > security context/label. Without connection latching you're stuck with the labels from the credentials and the IKE child SA creations. If you need to narrow a label for some flow, you also need to narrow the related SAs. > These are usually (always?) the same label in both directions. I imagine so for the child SAs of one IKE SA. But not necessarily for different child SAs of different IKE SAs that are used to protect the same flows. Your policy has to be sane to prevent that. > >Socket options should support: > > I don't think I need to be at the socket level for this. Whatever > userland does to give or not give a packet a security context/label > is up to the system or application. To me it only becomes interesting > once it reaches an SPD in the kernel where it generates an ACQUIRE > or is (or is not) selected for encryption. Q: How does an application do that without socket options? A: It edits the IPsec configuration. nuts! :) But OK, that's not for _this_ thread, so I'll shut up about it now. I mentioned connection latching in the hopes of getting implementors interested :) > The question that I still don't feel your email answered is, should > this be a traffic selector kind or a notify message? I have heard > arguments both ways but I don't yet the WG having a clear preference > for one or the other based on some technical aspect. It has to be a TS. You need to be able to specify that the labels on the SAs must dominate the labels on the flows. To do this you must treat the labels as traffic selectors. A label assertion carried in an ULP, on the other hand, wouldn't be a TS at all. That's why I mentioned them. Nico -- From nobody Thu May 3 06:19:29 2018 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 2ECF712DA41 for ; Thu, 3 May 2018 06:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-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 wE9W7Cs4CX3r for ; Thu, 3 May 2018 06:19:26 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 E5C9412DA25 for ; Thu, 3 May 2018 06:19:18 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id v85-v6so25900398lfa.13 for ; Thu, 03 May 2018 06:19:18 -0700 (PDT) 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:content-language :thread-index; bh=ReRR0/2ujK1x0gk6dx20GGT5AKVKDBKCSKrlRCirl3E=; b=NWm9QOn/Y4ur2gVa3TtotA6cmsfIVtvyN6+I5qALKa1Pjz2sgUGTDShnA/n1j3REaz VKgeFI93QwMmFUJOCOXQwJM1XG1mheP/soi57rK6eDTX4FA97rExk7cKSzlIopSF6QKy IlB91tuFNKMPhTP8yXm4lUTxm489bwICir6uHvTexDjMuJHT5XikeyiDOu+7BHmwZLu6 XqIy9v6fLPhcaH/Kg9UgpBoEgX+kXn5J/P8NFI2vr4XAdlgTGP3rSs7OYevmJpEqA/51 QgrEi1c0Hj8XqoTrRBXc/oZvtWcXDPw1I9UV6Nwe+7ORXyyFgoM0s+02oRgdA7xsNfYv uWEA== 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:content-language :thread-index; bh=ReRR0/2ujK1x0gk6dx20GGT5AKVKDBKCSKrlRCirl3E=; b=tvuHdErAo/t9P2XPv1d0Yc0N+aZ5cO+k7ZrJX02GJDOH1oKaCCcR0EomU/PQsF+Lvl +ee+Iqjr9DlgdyIazY+9BS22bCvLzNuJK8WpzcCCZS4d6UJOr+o6gIuAy6fjExiC0Q0R CLn7cWkJbt1sAg4wr1THVBgiREZnD8KxFr0xqu2G0y0dec6u0an/Sk7MQAdcoN9mj/n0 SBThFFXDwWOLPCIIvcQA/kjGEJlm63HOW63lPSmNniFzMby4RmNRGIcOfvNmQwK9ML99 3E4o31Xbhax2UY9K+zUCF83EPuE2BYKzg8h975Z1jezCbYbKRa6VVgsetuXnZIcNshKT R13w== X-Gm-Message-State: ALQs6tDoeeAd6kbLxmCups0FgHqNxf553nA0T0SiBMhx7pao1uQ4k/8w 6cmTrAVI6fvKCx6RDExPi1ILNQ== X-Google-Smtp-Source: AB8JxZr2UOwoyaLI1JxB+dGGqSAYHsbmADFhDxz/8tdvA0YoQTfhOF+HDZqwQt/w60aWVE9Z3ojk5A== X-Received: by 2002:a2e:7d1a:: with SMTP id y26-v6mr13003589ljc.135.1525353556256; Thu, 03 May 2018 06:19:16 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a21-v6sm2775089ljf.35.2018.05.03.06.19.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 May 2018 06:19:15 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: "'Michael Richardson'" References: <18031.1525203348@obiwan.sandelman.ca> In-Reply-To: <18031.1525203348@obiwan.sandelman.ca> Date: Thu, 3 May 2018 16:19:07 +0300 Message-ID: <002101d3e2e1$517d9520$f478bf60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJpyXnTx432lunpoNOtv86jp9mYXQMm6jFootjfk+A= Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 13:19:28 -0000 Hi, > > So in a way, a NOTIFY might make sense. But then we do run the risk of > > an IPsec SA being installed with the notify ignored using a default > > security context instead of the security context required. Having it > > as part of the TSi/TSr payloads makes that a lot more clear. > > > Thoughts? > > It has to be a traffic selector. I agree that it must be a traffic selector. However, in my opinion the way it is currently defined in the draft is wrong. According to RFC7296 the individual TSs in TS payload are combined using logical OR for the purpose of deciding whether given packet matches the selector. In particular, Section 3.13 of RFC7296 says: ... a packet matches a given TSi/TSr if it matches at least one of the individual selectors in TSi, and at least one of the individual selectors in TSr. The draft currently defines a new TS, that contains only security label and no IP address, protocol and port information. Thus, it is impossible with the current definition to express policy, that if packet is going from IP1 to IP2 AND has a security label S, it must be protected using the negotiated SA. If you put IP1 and S in TSi and IP2 and S in TSr it will mean that packet EITHER going from IP1 to IP2 (regardless of its security label) or ANY packet having security label S (regardless of its IP addresses) is protected using the negotiated SA. To fix this issue the draft should instead define two new traffic selectors - TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL, that would contain IP range, protocol and ports range (as RFC7296 selectors), as well as the security label. This way the presence of the security label will be an additional criteria for packet matching. Regards, Valery. From nobody Thu May 3 10:18:53 2018 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 601A312EA55 for ; Thu, 3 May 2018 10:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 0sav-8CFV8pV for ; Thu, 3 May 2018 10:18:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C53B12E9A1 for ; Thu, 3 May 2018 10:18:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 965D420090 for ; Thu, 3 May 2018 13:30:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0B6C416B6; Thu, 3 May 2018 13:18:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 092D7169D for ; Thu, 3 May 2018 13:18:38 -0400 (EDT) From: Michael Richardson to: "ipsec\@ietf.org WG" In-Reply-To: <18031.1525203348@obiwan.sandelman.ca> References: <18031.1525203348@obiwan.sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 17:18:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: >> I think such an IPsec SA really conflates two different IPsec SA's. = For >> example, a service on a port where the IPsec SA is both for incoming= and >> outgoing connections are really two security contexts that can be sp= lit >> into two IPsec SAs one for client (any to port X) and one for server >> (port Y to any) >> So in a way, a NOTIFY might make sense. But then we do run the risk = of >> an IPsec SA being installed with the notify ignored using a default >> security context instead of the security context required. Having it >> as part of the TSi/TSr payloads makes that a lot more clear. >> Thoughts? > It has to be a traffic selector. It has to be a traffic selector so that it can be selected (so do labeled IPsec SA), or not selected (do not do it). Any other mechanism (notification) can not be unambiguously rejected by a responder. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWutEbYCLcPvd0N1lAQJRhAf/UdaihbE+qpMDjjSTnRQO17jIkqNNwQU6 +d6xJtOoT2AWyOvqo5rDGlImyqJrWEdedPwbsFlL2SQGBck6Wwe4nQ/HJ6Re8Era j4884sgwZKE9i5UDK3Ki4u5vM3j/6buqqBb95XnrdKJ8dluiP6iOGTAL49bLDtDg ulhUPOnnZ2SqmaHPBV690fjaWXyiFpkxyVdTk36/aJiud8hEecXKe/V28B56/FYY AMAy8dAdNprDgjcT/hfFPrpNrNnD7o4ZYXkqdDUREsQpGOasIyORQqfiYh60VcZ8 e7D9tQ3BaEIBwcgAgJ27GgnLuswD5RF1AD5Yu5Uv5fNEKjVrMrSSoA== =MA99 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 3 12:05:22 2018 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 89BC112DA02 for ; Thu, 3 May 2018 12:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 zV1JvuGWMQmN for ; Thu, 3 May 2018 12:05:19 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1137412DA00 for ; Thu, 3 May 2018 12:05:18 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 56F5F70BF116; Thu, 3 May 2018 12:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nTtRj9wZeV9xO4 R78DMBdGiYP9o=; b=wsJ3loFFsdwg0RdWGedKLVA+TFatOFnw7ohsm7XcPGjwaW A1CZyLNAm/fcO/TKJ9fCjRTiOSYpbaMfdZXtRgi0Q4oyheAMaZLYStDryapqApMN wmniQlyHfvAAPhhIDKijusDfqz3wfa0aY/Uay1t7q2sCG81j/ECYBc6lx9+dI= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id B17CD70BF115; Thu, 3 May 2018 12:05:17 -0700 (PDT) Date: Thu, 3 May 2018 13:57:07 -0500 From: Nico Williams To: Valery Smyslov Cc: 'Paul Wouters' , ipsec@ietf.org, 'Michael Richardson' Message-ID: <20180503185705.GB4242@localhost> References: <18031.1525203348@obiwan.sandelman.ca> <002101d3e2e1$517d9520$f478bf60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002101d3e2e1$517d9520$f478bf60$@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 19:05:21 -0000 On Thu, May 03, 2018 at 04:19:07PM +0300, Valery Smyslov wrote: > > It has to be a traffic selector. > > I agree that it must be a traffic selector. However, in my opinion the > way it is currently defined in the draft is wrong. > > According to RFC7296 the individual TSs in TS payload are combined > using logical OR for the purpose of deciding whether given packet > matches the selector. In particular, Section 3.13 of RFC7296 says: > > ... a packet matches a given TSi/TSr if it matches at least one of the > individual selectors in TSi, and at least one of the individual > selectors in TSr. > > The draft currently defines a new TS, that contains only security > label and no IP address, protocol and port information. Thus, it is > impossible with the current definition to express policy, that if > packet is going from IP1 to IP2 AND has a security label S, it must be > protected using the negotiated SA. If you put IP1 and S in TSi and IP2 > and S in TSr it will mean that packet EITHER going from IP1 to IP2 > (regardless of its security label) or ANY packet having security label > S (regardless of its IP addresses) is protected using the negotiated > SA. I wish RFC4306 carried multiple TS payloads, one for each type, and that there were multiple types of them. Of course, that is one possible approach here: extend IKEv2 to allow multiple TS payloads (which would have to be treated as a conjunction). But if that route is not chosen, then you're correct that we'd need new TS payload types: > To fix this issue the draft should instead define two new traffic selectors - > TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL, > that would contain IP range, protocol and ports range (as RFC7296 > selectors), as well as the security label. This way the presence of > the security label will be an additional criteria for packet matching. Cheers, Nico -- From nobody Thu May 3 16:44:54 2018 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 82D3F12EB29 for ; Thu, 3 May 2018 16:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lcRsl7UMksoz for ; Thu, 3 May 2018 16:44:51 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3E112E034 for ; Thu, 3 May 2018 16:44:50 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w43NileH014663 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 May 2018 02:44:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w43NilII006108; Fri, 4 May 2018 02:44:47 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23275.40687.119581.370767@fireball.acr.fi> Date: Fri, 4 May 2018 02:44:47 +0300 From: Tero Kivinen To: Michael Richardson Cc: "ipsec\@ietf.org WG" In-Reply-To: <26213.1525367918@localhost> References: <18031.1525203348@obiwan.sandelman.ca> <26213.1525367918@localhost> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 16 min Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 23:44:53 -0000 Michael Richardson writes: > > It has to be a traffic selector. > > It has to be a traffic selector so that it can be selected (so do labeled > IPsec SA), or not selected (do not do it). Any other mechanism > (notification) can not be unambiguously rejected by a responder. Not true. Traffic selectors in IKEv2 do have very strict processing rules, and for most of the cases I do not think security labels will follow those rules, or trying to force the security labels to follow those rules will just cause confusion. This includes ORing the different selectors together, narrowing any traffic selectors to include any subset of the original selectors, combining traffic selectors as long as the combined selectors are not wider than what was originally proposed etc. All of these will not really make traffic selectors suitable for the security label use. My understanding is that security labels are something that is dictated by the one end, and other end must agree on that and then both ends will be matching and marking the packets with suitable security labels when it goes to the SA and comes out from the SA. I.e., when kernel has packet going out to some IPsec SA tunnel, it will check the security label associated with the packet (or socket, or interface or whatever), and finds one IPsec SA which matches both the security label and also allows the packet to be sent to that SA (i.e., matches both traffic selector and the security label). When the other end gets packet from the IPsec SA which is tied to certain security label, it will do normal exit tunnel checks by checking the traffic selectors, and then it will MARK the packet with security label associated with the IPsec SA, so that when it is going forward it will have correct security label associated to it. To allow that is is completely possible to do this negotiation using notify payloads. I.e., initiator sends SECURITY_LABEL status notification to the other end which includes the security label to be associated to this Child SA. If the other end agrees on the proposal, it will reply with the SECURITY_LABEL notify payload containing exactly same security label than what was proposed by the other end (or simply empty data as actually the label does not matter here as only thing that matters is that both ends agree on same security label). If other end does not understand SECURITY_LABEL notify at all, it will ignore it and initiator will see this and can tear down the Child SA, and indicate that other end does not support security labels. If other end do support the security labels, but do not accept this policy, it can either return NO_PROPOSAL_CHOSEN if it does not want to indicate why proposal was unacceptable, or we might add new error notification INVALID_SECURITY_LABEL which indicates that proposal was otherwise ok, but security label was not unacceptable. This is similar to how we negotiate transport mode in IKEv2, i.e., initiator includes USE_TRANSPORT_MODE notify, and responder confirms it by sending it too. NON_FIRST_FRAGMENTS_ALSO does about same thing. IPCOMP_SUPORTED does bit more complicated negotiation inside the notify payloads, initiator proposes list, and responder picks one. SIGNATURE_HASH_ALGORITHMS negotiation for RFC7427 does yet another different type of negotiation inside notify payloads. -- kivinen@iki.fi From nobody Thu May 3 17:45:26 2018 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 EB9401271FD for ; Thu, 3 May 2018 17:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 fqDz9_gaeIts for ; Thu, 3 May 2018 17:45:23 -0700 (PDT) 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 A5DB4127058 for ; Thu, 3 May 2018 17:45:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40cYFp6qlTz37r for ; Fri, 4 May 2018 02:45:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1525394719; bh=67gsq5Koz/NKpYrB8CQmyKVS76qN1gykgEgUhg4UUpI=; h=Date:From:To:Subject:In-Reply-To:References; b=P0y7HGN3yNoTOxQjCpUCKhKpQOlh+JeY65ooUR6V2zmNgcbT3q/GhoYTSDcgIIEv5 FCcnlJvqSXzZ4XZYMW6S79j/8uax0yDX3ToIt22Xs9XGMYsoXH66RZt4WpZW4ruAKd 7EqvSGQyfCqr/VsiehWQCotX4PNyRrZ4clssAAkk= 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 gfE1Uh3nkxPj for ; Fri, 4 May 2018 02:45:17 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 4 May 2018 02:45:16 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 57EB14AB8F8; Thu, 3 May 2018 20:45:15 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 57EB14AB8F8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4C8FA40C89F1 for ; Thu, 3 May 2018 20:45:15 -0400 (EDT) Date: Thu, 3 May 2018 20:45:15 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <23275.40687.119581.370767@fireball.acr.fi> Message-ID: References: <18031.1525203348@obiwan.sandelman.ca> <26213.1525367918@localhost> <23275.40687.119581.370767@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 00:45:26 -0000 On Fri, 4 May 2018, Tero Kivinen wrote: > Traffic selectors in IKEv2 do have very strict processing rules, and > for most of the cases I do not think security labels will follow those > rules, or trying to force the security labels to follow those rules > will just cause confusion. > > This includes ORing the different selectors together, narrowing any > traffic selectors to include any subset of the original selectors, > combining traffic selectors as long as the combined selectors are not > wider than what was originally proposed etc. > > All of these will not really make traffic selectors suitable for the > security label use. I think this is true. Especially now it seems there is no narrowing to be done from one security label to another one. > My understanding is that security labels are something that is > dictated by the one end, and other end must agree on that and then > both ends will be matching and marking the packets with suitable > security labels when it goes to the SA and comes out from the SA. I would say "dictated by both ends", but yes :) > I.e., when kernel has packet going out to some IPsec SA tunnel, it > will check the security label associated with the packet (or socket, > or interface or whatever), and finds one IPsec SA which matches both > the security label and also allows the packet to be sent to that SA > (i.e., matches both traffic selector and the security label). When the > other end gets packet from the IPsec SA which is tied to certain > security label, it will do normal exit tunnel checks by checking the > traffic selectors, and then it will MARK the packet with security > label associated with the IPsec SA, so that when it is going forward > it will have correct security label associated to it. Exactly, except s/MARK/label because MARKing of packets is another functionality of the (linux) kernel. > If other end does not understand SECURITY_LABEL notify at all, it will > ignore it and initiator will see this and can tear down the Child SA, > and indicate that other end does not support security labels. This I don't like as much. I'd rather see a failure on the responder on some critical flag payload it does not understand. But also, the initiator should not yet have Child SA's ? (but that might be implementation specific) > If other > end do support the security labels, but do not accept this policy, it > can either return NO_PROPOSAL_CHOSEN if it does not want to indicate > why proposal was unacceptable, or we might add new error notification > INVALID_SECURITY_LABEL which indicates that proposal was otherwise ok, > but security label was not unacceptable. That would work for me. > This is similar to how we negotiate transport mode in IKEv2, i.e., > initiator includes USE_TRANSPORT_MODE notify, and responder confirms > it by sending it too. Right. Paul From nobody Thu May 3 21:03:31 2018 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 D8591127333 for ; Thu, 3 May 2018 21:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 vpS_-yQoezSK for ; Thu, 3 May 2018 21:03:27 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0CC126C0F for ; Thu, 3 May 2018 21:03:27 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id CDCE020131E46; Thu, 3 May 2018 21:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iTgWJn/HZXh2aE ndfiU+uANbndo=; b=tZ0LGxHG1lhuzIWN7900MzAsSM8WvtL7lbkNePORlYTiPW OyYKp57Bw1CX+Ss7K8bpFNb0K6Be8DT8EWyHRQF+cWYJOcHF2zr+5BwivHfUabrn KII7//tnoFKeYL0wlNoJ9oTZiixphEhy9JnE04FuvXO2mFvAkDUncrmPMYxxg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 8667D20131E45; Thu, 3 May 2018 21:03:26 -0700 (PDT) Date: Thu, 3 May 2018 22:46:11 -0500 From: Nico Williams To: Paul Wouters Cc: "ipsec@ietf.org WG" Message-ID: <20180504034610.GC4242@localhost> References: <18031.1525203348@obiwan.sandelman.ca> <26213.1525367918@localhost> <23275.40687.119581.370767@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 04:03:30 -0000 On Thu, May 03, 2018 at 08:45:15PM -0400, Paul Wouters wrote: > On Fri, 4 May 2018, Tero Kivinen wrote: > > Traffic selectors in IKEv2 do have very strict processing rules, and > > for most of the cases I do not think security labels will follow those > > rules, or trying to force the security labels to follow those rules > > will just cause confusion. > > > > This includes ORing the different selectors together, narrowing any > > traffic selectors to include any subset of the original selectors, > > combining traffic selectors as long as the combined selectors are not > > wider than what was originally proposed etc. > > > > All of these will not really make traffic selectors suitable for the > > security label use. > > I think this is true. Especially now it seems there is no narrowing to > be done from one security label to another one. It depends on the label system. For something like MLS you can narrow a label since labels actually represent label sets or ranges, the label being a bitmask of compartments and a classification level: you can always remove bits from the mask and reduce the classification level. That is, for some systems the labels can be narrowed (but not broadened). I expect that typically the maximal label ranges for each node will be carried by their credentials (e.g., certificates) or be looked up in directories. In this case, a TS or NOTIFY would only be usedo to narrow the label range for an SA further than the two nodes' maximal label ranges. When there is no need to do this, then there is no need for a TS or NOTIFY payload to carry a label [range]. I mentioned socket options before because, really, without them, it's just too hard for applications to drive narrowing of SAs. And I mentioned connection latching because without that socket options don't make much sense either. Incidentally, Solaris/Illumos have a socket option by which an application can request a narrowed SA... Solaris/Illumos also have a sort of minimal connection latching. Without APIs, there's almost no point to narrowing the label ranges of SAs as applications then have to resort to modifying IPsec policy, and often that's just ETOOHARD. Connection latching is essentially a way of delegating IPsec configuration changes to the ULP. > >My understanding is that security labels are something that is > >dictated by the one end, and other end must agree on that and then > >both ends will be matching and marking the packets with suitable > >security labels when it goes to the SA and comes out from the SA. > > I would say "dictated by both ends", but yes :) Two nodes would have some label range/set each and a credential each asserting the node's label range. The data that can be sent from one to the other has to be labeled with a label that is in the recipient's label range. A node could send more-classified data than its local labels to another node that can accept it. Think of a military officer classifying a memo at a higher level than they can read. In general communication will be within the intersection of the two nodes' label ranges, but it can be asymmetric. The nodes might also be running processes with reduced label ranges. This should be a source of desire to narrow child SAs' label ranges. If narrowed SAs are used for some flow, then the label of the flow is informative. If there is no need to deliver that information from IPsec to the application, then there is not much point to labeling narrowed SAs in transport mode, except that SA lifetimes and flow (connection) lifetimes are not bound to each other... ...If a connection ends and its 5-tuple is reused later and a packet floating about is finally delivered, but with a now-incorrect label. My spidey sense says that you want to narrow and label the SAs, but maybe it's just a waste of resources. But if an application needs to know the label of a flow, and without the ULP or application protocol being able to carry it, then the only way to get at it is from the SAs used to protect the flow (see my comments about connection latching and socket options), in which case narrowing the SAs would help. In this case, too, APIs would be rather handy. And what about SG use cases? Here, I think an SG needs to see narrowed label choices for specific flows if it has multiple outbound routes for a given destination at different label ranges. That seems a bit unlikely to me, but I wouldn't know. Another possibility is that the SG's route to some node has a different label range than another node traversing the SA to the first node, in which case the SA needs to know the individual traffic flows' labels, and we should assume that there's no way to send those at the ULP, in which case we need narrowed SAs. (I'll note that SGs are the sort of application that can be expected to modify IPsec configuration on the fly as needed.) > >I.e., when kernel has packet going out to some IPsec SA tunnel, it > >will check the security label associated with the packet (or socket, > >or interface or whatever), and finds one IPsec SA which matches both > >the security label and also allows the packet to be sent to that SA > >(i.e., matches both traffic selector and the security label). When the > >other end gets packet from the IPsec SA which is tied to certain > >security label, it will do normal exit tunnel checks by checking the > >traffic selectors, and then it will MARK the packet with security > >label associated with the IPsec SA, so that when it is going forward > >it will have correct security label associated to it. If there are multiple SAs whose traffic selectors match the 5-tuple, but at different labels, then a sender has to pick carefully. If we never narrow SAs, then it's probably safe to assume this just doesn't happen (why would it?), but narrowing SAs does happen, and is supported. If there is no matching SA, then one will have to be negotiated that matches the 5-tuple, including the flow's label. This all sounds to me a lot like labels are traffic selectors. Whether they are represented as such on the wire in IKE is another story, but their function really looks to me a lot like traffic selectors. > >If other end does not understand SECURITY_LABEL notify at all, it will > >ignore it and initiator will see this and can tear down the Child SA, > >and indicate that other end does not support security labels. > > This I don't like as much. I'd rather see a failure on the responder on > some critical flag payload it does not understand. Yeah, but it's not that big a deal to not have that failure on the responder. Presumably the initiator will just delete the then-useless SA, else the responder will hold that resource for a while. > But also, the initiator should not yet have Child SA's ? (but that might > be implementation specific) In that case the parent IKE SA may have a broader label range/set than the child SAs. If the responder can't handle the label the particular packet flow needs and the initiator knows it, then the initiator should not even bother creating a child SA pair for that flow. Again, this could only happen if the application somehow conveyed the narrowed label range to the IPsec layer... > >If other > >end do support the security labels, but do not accept this policy, it > >can either return NO_PROPOSAL_CHOSEN if it does not want to indicate > >why proposal was unacceptable, or we might add new error notification > >INVALID_SECURITY_LABEL which indicates that proposal was otherwise ok, > >but security label was not unacceptable. Assuming the label ranges/sets are carried by the nodes' credentials, then there is no need for a label proposal unless the nodes wish to narrow the resulting SAs' label ranges. An empty intersection of the two nodes' label ranges would be an error in a MAC system, and the IKE SA establishment will not complete, let alone the child SA establishments. > >This is similar to how we negotiate transport mode in IKEv2, i.e., > >initiator includes USE_TRANSPORT_MODE notify, and responder confirms > >it by sending it too. I mean, it can work fine. Notionally, ISTM that a pack flow's 5-tuple and label both are used to select SAs, therefore labels are -at least notionally- traffic selectors. Nico -- From nobody Sun May 6 21:40:22 2018 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 89F79126BF6 for ; Sun, 6 May 2018 21:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 hi0QYDsiWH63 for ; Sun, 6 May 2018 21:40:18 -0700 (PDT) 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 2F13A1200E5 for ; Sun, 6 May 2018 21:40:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40fVKV2j5Kz1K1; Mon, 7 May 2018 06:40:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1525668014; bh=cRlkwHIMSWYTxzIUYXp5tFt1aT0t2G38y/CkcQ8z0Ig=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UePtmipoLvexDfP1S5eVysN+gj5bP9l2+bKhR0xRV492Rehg9H6iOlHjLe1HciJd0 GNWZgkYwed7GZmHG04PCGslb0oisUHRR1nSttpMD7XYN0MKLZGyDsIHo9dafeSZ7mq nSzo/SrhPg55OetZXbBlY61L1bUan3nZUkHRAIfg= 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 0DXRUsPA3oTY; Mon, 7 May 2018 06:40:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 7 May 2018 06:40:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9E6264AB8F1; Mon, 7 May 2018 00:40:08 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9E6264AB8F1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 905A74023301; Mon, 7 May 2018 00:40:08 -0400 (EDT) Date: Mon, 7 May 2018 00:40:08 -0400 (EDT) From: Paul Wouters To: Nico Williams cc: "ipsec@ietf.org WG" In-Reply-To: <20180504034610.GC4242@localhost> Message-ID: References: <18031.1525203348@obiwan.sandelman.ca> <26213.1525367918@localhost> <23275.40687.119581.370767@fireball.acr.fi> <20180504034610.GC4242@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 04:40:21 -0000 On Thu, 3 May 2018, Nico Williams wrote: >> I think this is true. Especially now it seems there is no narrowing to >> be done from one security label to another one. > > It depends on the label system. > > For something like MLS you can narrow a label since labels actually > represent label sets or ranges, the label being a bitmask of > compartments and a classification level: you can always remove bits > from the mask and reduce the classification level. > > That is, for some systems the labels can be narrowed (but not broadened). This might be technically possible, but seems to not be the case on how MLS with the USG works. Which kind of makes sense, overclassification is a problem as well as underclassification (although only the latter one is punishable through the legal system) > In this case, a TS or NOTIFY would only be usedo to narrow the label > range for an SA further than the two nodes' maximal label ranges. When > there is no need to do this, then there is no need for a TS or NOTIFY > payload to carry a label [range]. I don't understand why ou say that. Two nodes can still want to make sure that any traffic for a specificly configured IPsec SA MUST only happen with one single security context and you want both ends to reveal to each other what security context it will set on decrypted packets. > I mentioned socket options before because, really, without them, it's > just too hard for applications to drive narrowing of SAs. I'm really trying to stay away any of these concepts related to BTNS and connection latching and sockets. We are really just talking about SPDs that have another item in their ACQUIRE beyond the 5 tuple and how to deal with that. > Two nodes would have some label range/set each and a credential each > asserting the node's label range. > > The data that can be sent from one to the other has to be labeled with a > label that is in the recipient's label range. > A node could send more-classified data than its local labels to another > node that can accept it. Think of a military officer classifying a > memo at a higher level than they can read. I don't think the IPsec labeling system should be a system where you can modify the classification. This is all about applications using the (encrypted) network while retaining the same classification. So this is definately not in scope. > The nodes might also be running processes with reduced label ranges. > This should be a source of desire to narrow child SAs' label ranges. Again, in the MLS system I'm aware of, this is not possible, as you don't narrow in this way. The entire label is what you have and the goal is to transport that traffic with the same label onto the other host, so applications there can receive the traffic at the correct label. > If narrowed SAs are used for some flow, then the label of the flow is > informative. If there is no need to deliver that information from IPsec > to the application, then there is not much point to labeling narrowed > SAs in transport mode, except that SA lifetimes and flow (connection) > lifetimes are not bound to each other... Also note how I'm not making any differences for transport or tunnel mode as I'm not binding this to any other layer. I'm not sure what lifetimes have to do with labels either and would like to not talk about those too :) > ....If a connection ends and its 5-tuple is reused later and a packet > floating about is finally delivered, but with a now-incorrect label. My > spidey sense says that you want to narrow and label the SAs, but maybe > it's just a waste of resources. The entire IPsec SA has the same label, regardless of 5-tuple. If you need different security contexts for different tuples, you need to negotiate those as separate IPsec SA's. > But if an application needs to know the label of a flow Some might but most won't. For most, with the wrong label the application will be prevented from ever seeing the packet by the kernel. Those applications who will be able to do this will also be able to read the label and act on it. > And what about SG use cases? Here, I think an SG needs to see narrowed > label choices for specific flows if it has multiple outbound routes for > a given destination at different label ranges. I don't see why this is related to "narrowed labels". I do see you can have multiple IPsec SA's installed with the same 5 tuple but with different labels. > That seems a bit > unlikely to me, but I wouldn't know. Another possibility is that the > SG's route to some node has a different label range than another node > traversing the SA to the first node, in which case the SA needs to know > the individual traffic flows' labels, and we should assume that there's > no way to send those at the ULP, in which case we need narrowed SAs. Again I don't see how this relates to narrowing at all. If there is a chain from A <-> B <-> C then B better be allowed to install two IPsec Sa's with that identical label that A and C are expecting. You wouldn't want anyone in the middle changing that, although from a protocol level, nothing stops B from NATing the packets to the same 5 tupple but with a different label. It might be a feature. > If there are multiple SAs whose traffic selectors match the 5-tuple, but > at different labels, then a sender has to pick carefully. If we never > narrow SAs, then it's probably safe to assume this just doesn't happen > (why would it?), but narrowing SAs does happen, and is supported. Narrowing happens on the 5 tuple. The question is, can a label narrow. AFAIK, with the SElinux based MLS of the USG, this is not how the label works. The question for this RFC is, should we specify it such that another labelin system could use it? Even if the RFC allows narrowing, the current USG MLS could simple not allow this and always require exact matching. And if we allow this narrowing, then how much does IKE need to know about this? Since if we design for this in general, we could have wildly different systems. Eg one could be a label based on DN's where "C=CA" could be narrows to "C=CA, S=ON, L=Toronto" or we could have one where "slkd" could be narrows to "slkdhsalglfgds". Presumbly therefor, we cannot specify generic narrowing in the document. > This all sounds to me a lot like labels are traffic selectors. Whether > they are represented as such on the wire in IKE is another story, but > their function really looks to me a lot like traffic selectors. I agree. But see Tero's post on why he prefers NOTIFY. >> This I don't like as much. I'd rather see a failure on the responder on >> some critical flag payload it does not understand. > > Yeah, but it's not that big a deal to not have that failure on the > responder. Presumably the initiator will just delete the then-useless > SA, else the responder will hold that resource for a while. That's true. >> But also, the initiator should not yet have Child SA's ? (but that might >> be implementation specific) > > In that case the parent IKE SA may have a broader label range/set than > the child SAs. The labels we are talking about are for traffic flowing through IPsec SA's. I don't understand why you now talk about IKE SA labels. In general, all IKE traffic is holed specifically from any IPsec SA as to ensure IKE can flow even in case of lost IPsec SA's. So there is no need to consider the label of UDP (4)500 packets. > Assuming the label ranges/sets are carried by the nodes' credentials, > then there is no need for a label proposal unless the nodes wish to > narrow the resulting SAs' label ranges. I think what you are saying here is that if both ends require a specific label for traffic, it is defacto preconfigured and doesn't need to be negotiated. But that limits things to preconfigured on a peer to peer basic, and might not work well for Opportunistic IPsec, eg a mesh crypto network. Peers might still want to 'announce' the label they will give to the received decrypted traffic and nodes might accept multiple labels so in that case there might be some kind of negotiation happening. But even if the nodes just confirm the label configured to each other, that would likely be useful for debugging - even if it is technically not a negotiation of label. > I mean, it can work fine. Notionally, ISTM that a pack flow's 5-tuple > and label both are used to select SAs, therefore labels are -at least > notionally- traffic selectors. Again, agreed. The question though, is whether it is worth doing it as a traffic selector or should we use a notify? Paul From nobody Wed May 9 13:10:00 2018 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 903CF127863; Wed, 9 May 2018 13:09:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152589659854.3921.2410806894660111145@ietfa.amsl.com> Date: Wed, 09 May 2018 13:09:58 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 20:09:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-03.txt Pages : 8 Date : 2018-05-09 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 9 13:11:27 2018 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 E1F38127909; Wed, 9 May 2018 13:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mAUswtlCH8m; Wed, 9 May 2018 13:11:22 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 55AC3127863; Wed, 9 May 2018 13:11:19 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id o123-v6so52740943lfe.8; Wed, 09 May 2018 13:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2KDp3cZgh0ICP2cLm9nunO2gzf1Z9BDm3JBqTdjtBqM=; b=YELDHBu1qGk7NVjKvBbZ8wPm9ClK/Z5zyvbvVXYAVI5684zVMfoKJllHVxxj7XYFBD e2Ddv9+fdCLld//Cq1D1kMvVqZCYlvxQFcyVdKKS0Lc8Ui7PV+yCuzrXp/tiEJtX6llE N0UdtUB9ATZ9MtXpc98/BR0iSetmtFOIwBHQ58hwFouvX4t9TbWTUb963Pt3LRP23h/L cI3uRUsGQcsE3a3Js0kL6/3XdTRgOZoZrsgHsNUPDI+mJ4iD1he+sljTrtO7bk19cVkR 3pg1VWOii3I1pu+x1WwcrU6U50rSE7TqIImG5cdbLx4P9JNaV2VzotHfch4JmSQ42xLj X3OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2KDp3cZgh0ICP2cLm9nunO2gzf1Z9BDm3JBqTdjtBqM=; b=SCpSWTwG1t3p3uUuhedSH742BomjxHN5fHnydFKspzfjRTNXpP9CaLcCQWVjQBBUY0 gh12/Zqohi9TSfYSjKpZGIlG5BkBGExBNWHHIyciuEzu1jrrWwofFMzUdArva9oxHx/P QVjUmYLcgYGoRFj8hN/EBANcnI7wiazWdRpd8rJzAisAjklxywbtDPh/ZFmO5mrlqLc5 YMhR+crea0wDXaeU61/5At4HuMBYfO8egVzciT7cV+4V1JDvwSA+XHbPXf3q23QvD1G9 d+NhGEBlfqpslambbwpec0upsX14bpw/KyY00tJivijn6MCIWXFJFe5PYqvpkBZWSeox od0Q== X-Gm-Message-State: ALQs6tAe/dnWzQGdaN6YUDmQ1Ivq9O1mLaF/QKFWd7TbvgU+8vxvhkTO nOzjFMPl/ZFlJht/yix+9qtoxSU/Xdob4GMK+Ls= X-Google-Smtp-Source: AB8JxZpOIo7M79EtVMGHnhf6csuigbLtkXitfNxKsL/9XXk02dSxmTMCzDYneF9VOkY8O+YTYV0eMK6P7WB5ZsyNYP0= X-Received: by 2002:a19:2bc6:: with SMTP id r189-v6mr28975367lfr.24.1525896677510; Wed, 09 May 2018 13:11:17 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.5.146 with HTTP; Wed, 9 May 2018 13:11:16 -0700 (PDT) In-Reply-To: <23239.54227.814560.228778@fireball.acr.fi> References: <23239.54227.814560.228778@fireball.acr.fi> From: Daniel Migault Date: Wed, 9 May 2018 16:11:16 -0400 X-Google-Sender-Auth: qQJw6AO982iJZMQqrZZauQKHOlc Message-ID: To: Tero Kivinen Cc: IPsecME WG , draft-ietf-ipsecme-implicit-iv@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d5504056bcb8176" Archived-At: Subject: Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 20:11:26 -0000 --0000000000006d5504056bcb8176 Content-Type: text/plain; charset="UTF-8" Hi, Thank you Tero for the review. Please find in line my responses in line. version 02 of the draft has been updated accordingly to your review. Yours, Daniel On Fri, Apr 6, 2018 at 4:08 PM, Tero Kivinen wrote: > While doing my IANA review on the document I found some small nits > about it. Here are my comments to the document: > > -- > > Typo in abstract: > > This avoids > sending the nonce itself, and savec in the case of AES-GCM, AES-CCM, > ^^^^^ > > I assume it should be "saves". This has been changed to 'saves'. > -- > > In section 2 missing closing parenthesis and period: > > ... The same applies for > ChaCha20-Poly1305 ([RFC7634]. Currently this nonce is sent in each > ^ > > add missing ")". > > The missing ")" has been added > -- > > In section 4, I think SA is better word than SPI to describe the IPsec > security association. SPI is just the number identifying the SA, SA is > the actual security association which includes sequence number, key, > direction, algorithms etc. > > So change: > > As the IV MUST NOT repeat for one SPI when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one SPI. > Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > one secret and thus one SPI. > > with > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > used, Implicit IV as described in this document MUST NOT be used in > setups with the chance that the Sequence Number overlaps for one > SA. Multicast as described in [RFC5374], [RFC6407] and > [I-D.yeung-g-ikev2] is a prominent example, where many senders > share one secret and thus one SA. > > The three occurrences of SPI have been changed to SA. > -- > > This text is bit misleading > > A similar mechanism could be used by associating the most > significant byte of the Sequence Number to a sender, while the 3 > remaining bytes will be used to carry the counter value. Such > mechanism prevents the use of Extended Sequence Number and limits > the number of packet to be sent to 2** 24 = 16777216, that is 16 M. > > To solve the issue you could of course move the sender byte as the > least significant byte in the sequence number, i.e., in that case the > system could use extended sequence numbers, and the limit of the > packet would not be that bad. Of course this still has the issue that > normal replay window processing does not work with cases where > sequence numbers are not used in numeric order (this same issue is in > the normal RFC6407 cases). > > On the other hand, I think it might be better to just forbid the > implicit IV on multicast cases, and we do not need to explain all the > issues there. > > I propose to add your comment and mention that Implicit IV is not recommended with multicast so the reader interested in multicast understands the motivation for not using it. As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. Section 3.5 of [RFC6407] provides a mechanism that MAY be used to prevent IV collisions when the same key is used by multiple users. The mechanism consists in partitioning the IV space between users by assigning the most significant byte to a user. When implicit IV transforms are used, such mechanism cannot be applied as the IV is not sent, but instead it is derived from the Sequence Number. A similar mechanism could be used by associating the most significant byte of the Sequence Number to a sender, while the 3 remaining bytes will be used to carry the counter value. Such mechanism prevents the use of Extended Sequence Number and limits the number of packet to be sent to 2** 24 = 16777216, that is 16 M. Note that associating instead the least significant byte of the Sequence Number to the sender, would enable the system to use Extended Sequence Number and as such extend the limit of packet to be sent to 2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P. Note also that in both cases the Sequence Number are not interpreted as numeric values which impacts the replay window processing defined in [RFC4302] and [RFC4302]. Unless some mechanism are provided to avoid collision between Sequence Number, ( and so IV ), Implicit IV MUST NOT be used. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. another alternative could be: As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are used, Implicit IV as described in this document MUST NOT be used in setups with the chance that the Sequence Number overlaps for one SA. Multicast as described in [RFC5374], [RFC6407] and [I-D.yeung-g-ikev2] is a prominent example, where many senders share one secret and thus one SA. As such, it is NOT RECOMMENDED to use Implicit IV with Multicast. -- > > Section 5 and 6 need more text. > > I.e., you do not actually describe how the Implicit IV is negotiated > in the IKE. You just tell that yes, it is negotiated, and there is no > issues. > > So I suggest rewriting them as follows: > > ---------------------------------------------------------------------- > 5. Initiator Behavior > > An initiator supporting this feature SHOULD propose implicit IV > algorithms in the Transform Type 1 (Encryption Algorithm) > Substructure of the Proposal Substructure inside the SA Payload. To > facilitate backward compatibility with non-supporting peers the > initiator SHOULD also include those same algorithms without > Implicit IV (IIV) as separate transforms. > > 6. Responder Behavior > > The rules of SA Payload processing require that responder picks its > algorithms from the proposal sent by the initiator, thus this will > ensure that the responder will never send an SA payload containing > the IIV transform to an initiator that did not propose it. > > The proposed text replaces section 5 and 6. > -- > > In section 8 I do not understand what the first sentence is trying to > say. I think it should be better to rewrite the 1st paragraph in IANA > fConsiderations section as follows: > > This section assigns new code points to the recommended AEAD suites > provided in [RFC8221], thus the new Transform Type 1 - Encryption > Algorithm Transform IDs [IANA] are as defined below: > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000006d5504056bcb8176 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you Tero for the re= view. Please find in line my responses in line. version 02 of the draft has= been updated accordingly to your review.

Yours,
Da= niel

On Fri, A= pr 6, 2018 at 4:08 PM, Tero Kivinen <kivinen@iki.fi> wrote:
=
While doing my IANA revie= w on the document I found some small nits
about it. Here are my comments to the document:

--

Typo in abstract:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This avo= ids
=C2=A0 =C2=A0sending the nonce itself, and savec in the case of AES-GCM, AE= S-CCM,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^

I assume it should be "saves".=C2=A0

<= div>This has been changed to 'saves'.
=C2=A0
--

In section 2 missing closing parenthesis and period:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... The same applies for
=C2=A0 =C2=A0ChaCha20-Poly1305 ([RFC7634].=C2=A0 Currently this nonce is se= nt in each
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^

add missing ")".

The missing ")" has been added
--

In section 4, I think SA is better word than SPI to describe the IPsec
security association. SPI is just the number identifying the SA, SA is
the actual security association which includes sequence number, key,
direction, algorithms etc.

So change:

=C2=A0 =C2=A0As the IV MUST NOT repeat for one SPI when Counter-Mode cipher= s are
=C2=A0 =C2=A0used, Implicit IV as described in this document MUST NOT be us= ed in
=C2=A0 =C2=A0setups with the chance that the Sequence Number overlaps for o= ne SPI.
=C2=A0 =C2=A0Multicast as described in [RFC5374], [RFC6407] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where many senders= share
=C2=A0 =C2=A0one secret and thus one SPI.

with

=C2=A0 =C2=A0As the IV MUST NOT repeat for one SA when Counter-Mode ciphers= are
=C2=A0 =C2=A0used, Implicit IV as described in this document MUST NOT be us= ed in
=C2=A0 =C2=A0setups with the chance that the Sequence Number overlaps for o= ne
=C2=A0 =C2=A0SA. Multicast as described in [RFC5374], [RFC6407] and
=C2=A0 =C2=A0[I-D.yeung-g-ikev2] is a prominent example, where many senders=
=C2=A0 =C2=A0share one secret and thus one SA.

The three occurrences of SPI have been changed to SA.=
=C2=A0
--

This text is bit misleading

=C2=A0 =C2=A0A similar mechanism could be used by associating the most
=C2=A0 =C2=A0significant byte of the Sequence Number to a sender, while the= 3
=C2=A0 =C2=A0remaining bytes will be used to carry the counter value. Such<= br> =C2=A0 =C2=A0mechanism prevents the use of Extended Sequence Number and lim= its
=C2=A0 =C2=A0the number of packet to be sent to 2** 24 =3D 16777216, that i= s 16 M.

To solve the issue you could of course move the sender byte as the
least significant byte in the sequence number, i.e., in that case the
system could use extended sequence numbers, and the limit of the
packet would not be that bad. Of course this still has the issue that
normal replay window processing does not work with cases where
sequence numbers are not used in numeric order (this same issue is in
the normal RFC6407 cases).

On the other hand, I think it might be better to just forbid the
implicit IV on multicast cases, and we do not need to explain all the
issues there.


I propose to add your comment and ment= ion that Implicit IV is not recommended with multicast so the reader intere= sted in multicast understands the motivation for not using it.


A= s the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
=C2=A0= =C2=A0 used, Implicit IV as described in this document MUST NOT be used in<= br>=C2=A0=C2=A0 setups with the chance that the Sequence Number overlaps fo= r one SA.
=C2=A0=C2=A0 Multicast as described in [RFC5374], [RFC6407] an= d
=C2=A0=C2=A0 [I-D.yeung-g-ikev2] is a prominent example, where many se= nders share
=C2=A0=C2=A0 one secret and thus one SA.=C2=A0 Section 3.5 o= f [RFC6407] provides a
=C2=A0=C2=A0 mechanism that MAY be used to preven= t IV collisions when the same key
=C2=A0=C2=A0 is used by multiple users= .=C2=A0 The mechanism consists in partitioning
=C2=A0=C2=A0 the IV space= between users by assigning the most significant byte to
=C2=A0=C2=A0 a = user.=C2=A0 When implicit IV transforms are used, such mechanism cannot
= =C2=A0=C2=A0 be applied as the IV is not sent, but instead it is derived fr= om the
=C2=A0=C2=A0 Sequence Number.=C2=A0 A similar mechanism could be = used by associating
=C2=A0=C2=A0 the most significant byte of the Sequen= ce Number to a sender, while
=C2=A0=C2=A0 the 3 remaining bytes will be = used to carry the counter value.=C2=A0 Such
=C2=A0=C2=A0 mechanism preve= nts the use of Extended Sequence Number and limits the
=C2=A0=C2=A0 numb= er of packet to be sent to 2** 24 =3D 16777216, that is 16 M.=C2=A0 Note=C2=A0=C2=A0 that associating instead the least significant byte of the Se= quence
=C2=A0=C2=A0 Number to the sender, would enable the system to use= Extended
=C2=A0=C2=A0 Sequence Number and as such extend the limit of p= acket to be sent to
=C2=A0=C2=A0 2 ** ( 24 + 32 ) =3D 72057594037927936,= that is 72 P.=C2=A0 Note also that
=C2=A0=C2=A0 in both cases the Seque= nce Number are not interpreted as numeric
=C2=A0=C2=A0 values which impa= cts the replay window processing defined in
=C2=A0=C2=A0 [RFC4302] and [= RFC4302].

=C2=A0=C2=A0 Unless some mechanism are provided to avoid c= ollision between
=C2=A0=C2=A0 Sequence Number, ( and so IV ), Implicit I= V MUST NOT be used.=C2=A0 As
=C2=A0=C2=A0 such, it is NOT RECOMMENDED to= use Implicit IV with Multicast.

another alternative coul= d be:


As the IV MUST NOT repeat for one SA when Counter-Mode cip= hers are
=C2=A0=C2=A0 used, Implicit IV as described in this document MU= ST NOT be used in
=C2=A0=C2=A0 setups with the chance that the Sequence = Number overlaps for one SA.
=C2=A0=C2=A0 Multicast as described in [RFC5= 374], [RFC6407] and
=C2=A0=C2=A0 [I-D.yeung-g-ikev2] is a prominent exam= ple, where many senders share
=C2=A0=C2=A0 one secret and thus one SA.= =C2=A0 As
=C2=A0=C2=A0 such, it is NOT RECOMMENDED to use Implicit IV w= ith Multicast.


--

Section 5 and 6 need more text.

I.e., you do not actually describe how the Implicit IV is negotiated
in the IKE. You just tell that yes, it is negotiated, and there is no
issues.

So I suggest rewriting them as follows:

-----------------------------------------------------------------= -----
5.=C2=A0 Initiator Behavior

=C2=A0 =C2=A0An initiator supporting this feature SHOULD propose implicit I= V
=C2=A0 =C2=A0algorithms in the Transform Type 1 (Encryption Algorithm)
=C2=A0 =C2=A0Substructure of the Proposal Substructure inside the SA Payloa= d. To
=C2=A0 =C2=A0facilitate backward compatibility with non-supporting peers th= e
=C2=A0 =C2=A0initiator SHOULD also include those same algorithms without =C2=A0 =C2=A0Implicit IV (IIV) as separate transforms.

6.=C2=A0 Responder Behavior

=C2=A0 =C2=A0The rules of SA Payload processing require that responder pick= s its
=C2=A0 =C2=A0algorithms from the proposal sent by the initiator, thus this = will
=C2=A0 =C2=A0ensure that the responder will never send an SA payload contai= ning
=C2=A0 =C2=A0the IIV transform to an initiator that did not propose it.

The proposed text replaces section 5 and 6.=C2=A0
--

In section 8 I do not understand what the first sentence is trying to
say. I think it should be better to rewrite the 1st paragraph in IANA
fConsiderations section as follows:

=C2=A0 =C2=A0This section assigns new code points to the recommended AEAD s= uites
=C2=A0 =C2=A0provided in [RFC8221], thus the new Transform Type 1 - Encrypt= ion
=C2=A0 =C2=A0Algorithm Transform IDs [IANA] are as defined below:
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--0000000000006d5504056bcb8176-- From nobody Wed May 9 15:35:11 2018 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 DE0E312D7E2 for ; Wed, 9 May 2018 15:35:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mVnYuUW1StOh for ; Wed, 9 May 2018 15:35:07 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (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 B6FAA129C5D for ; Wed, 9 May 2018 15:35:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1525905307; x=2389818907; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vx782/qpJZC53RHha+88VtcmLPWX2IlT2QDeisep6Sk=; b=Fb0FhylUcOtu1x9IEAuif7uxw2UVQDspGSVJbndDLeC6bZOTDKL0lf+b/LWdnh82 N/M+mVkvhUXtuVGcCQMRakKmQIMJY+aP75jkgP7mVTyuzxSytRJk5PhiIlVcC/DK WYUwXFAl6OvbrAJ7Yx/OxKH+W7cTU90CInASP9OXr2wIhVvDeFA0Eopb9u7jdnh6 FhVmXIhdB1AMRpt5UZ8/SpMhtuXlSkuc96cJ0pLlmZTrgoNHC0qDYqxf/MXbwzO/ 78xavPoDRuXlRu5/ec/VH7HmDEFlXE//T8WFvOxv6LTjw3rnedtODgNBaP4gW4+F rsBCZ/Wf3eX4fCi+kcY+SQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id CF.C9.10828.A9773FA5; Wed, 9 May 2018 15:35:07 -0700 (PDT) X-AuditID: 11ab0218-260a89e000002a4c-c8-5af3779ab39b Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id E4.07.18185.A9773FA5; Wed, 9 May 2018 15:35:06 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.234.2.147] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0P8H00HJ2G2HPA10@nwk-mmpp-sz11.apple.com> for ipsec@ietf.org; Wed, 09 May 2018 15:35:06 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Date: Wed, 09 May 2018 15:35:04 -0700 References: <152589659854.3921.2410806894660111145@ietfa.amsl.com> To: "ipsec@ietf.org WG" In-reply-to: <152589659854.3921.2410806894660111145@ietfa.amsl.com> Message-id: <108C7E85-C321-4946-8C17-A59FB443C4C6@apple.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUi2FAYrDu7/HOUwcHVTBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsf9DYwFpwUrVm28xNjAeJ63i5GTQ0LAROJd/zKmLkYuDiGB NUwSTfdmMMEknq6Zyw6R2MAk0dc4mxEkwSsgKPFj8j2WLkYODmYBeYmD52VBwswCWhLfH7Wy QNS3M0m8PbgdrF5YQFqi68JdVpB6NqCiA2uMIMJuEk2n97KA2CwCqhI/f20A2ysk4CSxad45 sFYRAQ2JcwtvsoG0cgo4S2w+kgZxgY3EmZtLWCDOVJKY/v02G8haCYGnrBJLe/tYJzAKzUJy 6SyES2chuXQBI/MqRuHcxMwc3cw8IxO9xIKCnFS95PzcTYygYF3NJLGD8ctrw0OMAhyMSjy8 H3g+RwmxJpYVV+YeYpTmYFES5/3M9ihKSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+NySft9 B4odLRK67oVsWbfd9mG/b9uFK9r/0xK7c99+P3r4oOM3tSK/B2dSItlftnXGGz+LDBCOdJHQ c/W+wsuYdelm03E3w7fTZe97PQmIqr/Y2z5X5XP0qRiRjVPZbiTtV7D5vqPv82thSROmTb8P 7FMKlmXtezGt2vKT1qH7BbMFt6zyVVdiKc5INNRiLipOBACum8y3NwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FA8W3dW+ecog787DCz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI/7GxgLTgtWrNp4ibGB8TxvFyMnh4SAicTTNXPZuxi5OIQE NjBJ9DXOZgRJ8AoISvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPXtTBJvD24HqxcWkJbo unCXFaSeDajowBojiLCbRNPpvSwgNouAqsTPXxuYQGwhASeJTfPOgbWKCGhInFt4kw2klVPA WWLzkTSIC2wkztxcwgJxppLE9O+32SYw8s9CctwshONmITluASPzKkaBotScxEpjvcSCgpxU veT83E2M4NAqDN7B+GeZ1SFGAQ5GJR7eGVyfo4RYE8uKK3MPMUpwMCuJ8D6OBwrxpiRWVqUW 5ccXleakFh9ilOZgURLn1b/7IUpIID2xJDU7NbUgtQgmy8TBKdXAqG/5qdeP0ev6Y+Ei2w/p HPOP6xRfzN/eKnQj7oSjR5yu1Hu/y3+2WyaHnVTs37IveD7r0c1mVR1bUs4v/rHvtXBW2dx5 n3WdTn70UYosXXFGRfUDr+U50X2CXF49B+1qnl1Kt161PL35dcOjnkWRtYuO7pb94Fypsu2L cO6/Ql9Gidl2jq+mKbEUZyQaajEXFScCAC25YGUpAgAA Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 22:35:10 -0000 Thanks for the update, authors! I've reviewed -03 and it looks great to me. David > On May 9, 2018, at 13:09, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) > Authors : Daniel Migault > Tobias Guggemos > Yoav Nir > Filename : draft-ietf-ipsecme-implicit-iv-03.txt > Pages : 8 > Date : 2018-05-09 > > Abstract: > Encapsulating Security Payload (ESP) sends an initialization vector > (IV) or nonce in each packet. The size of IV depends on the applied > transform, being usually 8 or 16 octets for the transforms defined by > the time this document is written. Some algorithms such as AES-GCM, > AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do > not require an unpredictable nonce. When using such algorithms the > packet counter value can be used to generate a nonce. This avoids > sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, > AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document > describes how to do this. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-03 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu May 10 07:53:42 2018 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 962C5124205; Thu, 10 May 2018 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 a71waFGun4NB; Thu, 10 May 2018 07:53:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56FB1241FC; Thu, 10 May 2018 07:53:37 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w4AErW7I008929 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 17:53:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w4AErVkf012952; Thu, 10 May 2018 17:53:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23284.23787.935682.175733@fireball.acr.fi> Date: Thu, 10 May 2018 17:53:31 +0300 From: Tero Kivinen To: Daniel Migault Cc: IPsecME WG , draft-ietf-ipsecme-implicit-iv@ietf.org In-Reply-To: References: <23239.54227.814560.228778@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 14:53:41 -0000 Daniel Migault writes: > another alternative could be: >=20 > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > =A0=A0 used, Implicit IV as described in this document MUST NOT be us= ed in > =A0=A0 setups with the chance that the Sequence Number overlaps for o= ne SA. > =A0=A0 Multicast as described in [RFC5374], [RFC6407] and > =A0=A0 [I-D.yeung-g-ikev2] is a prominent example, where many senders= share > =A0=A0 one secret and thus one SA.=A0 As > =A0=A0 such, it is NOT RECOMMENDED to use Implicit IV with Multicast.= I would actually prefer to this. I think it is better to say don't do it, than provide ways it could be done before saying don't do it.... I.e., if someone is interested in this then we need to write new specification that will specify how it is done, so there is no point of speculating here what it could be. --=20 kivinen@iki.fi From nobody Thu May 10 09:36:51 2018 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 EDDFB12D885 for ; Thu, 10 May 2018 09:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 cUYp3rmAmkl3 for ; Thu, 10 May 2018 09:36:47 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 AFA6012D881 for ; Thu, 10 May 2018 09:36:47 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id h19-v6so2040728qkj.10 for ; Thu, 10 May 2018 09:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aDAbsJ3t8YCKSSxpsaRiwK4G+pNkPpAVBvaogFo6YNM=; b=VMNHf1MzI/uPnCe5do9V4xM1PA8AlFWXK2QDhCsgGkzcle9W23lJHdjjrcxnjTccR+ q2brPs2qF8Jna2vnecasTa6X34ajFtge+xRULzzCAxOo2IcruwjzI/i+cDWi1f2cWkhD FlY29zwhOPh+84CFrrQ85CO6c9FHt5IHa9ywLXy5DeIb288v9tYG5QK5Edn1gttUSQrB NOPNJZK3xY641wV8TlA+376JNSCB7C4CG6AMRIUy5apkwxb8O/p45Fu46YLl2j+1im4z bln81ezr1GI1PUChIZtISvFqAxNJDxm4jHgxak9iSrm2sN2W2sNBScWT4wqhV21vvbIR XV/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aDAbsJ3t8YCKSSxpsaRiwK4G+pNkPpAVBvaogFo6YNM=; b=tb9OaFtN2KQqNT62nIlQ6W7v12N9KoTe00RCMh+BiMDECDPOFENlRy6jqfMTSnzn5Z cfggRbL/gGUuf8GcgVfCa2d5fPfy6n0CCVJL9TuLCX2y1evvH5klNuGV67nrskax8FPP NZK7h7n7SeHEIvP/1jpWKl3eTCc89l9yuJZ4NtFRXiQy5+v86lGCtoLrbhzMgUmAK5qV 9le18cKeYI3xwwKKUElYLP6ywR/CdvEeWe+aN74ygNu/l7/CCHQaAWQbHZhPvxhBcnW6 CdQcSUZ3BXNtOiHopznCHWEwnyc+RgYt/Ne2AT2yEfG0Wa/S05NajSBYh1ygkH0gmZED tCmQ== X-Gm-Message-State: ALKqPwe9OYsHfaE4MCR4oh80huzSm4xWlbOQrcoALLdwFe+y3lL6m9RX BV0pOBki0/SwmvlKx6FmisniLEh0ZrB68A4MXQ0= X-Google-Smtp-Source: AB8JxZqRThXM7LXogWKByGfzEvWYI95RTtUli5BoqIdyljkBL9Hewjqv9dHrbZyqaQt/4ml+szRTl2WgP0hA8HEs/lw= X-Received: by 2002:a37:7943:: with SMTP id u64-v6mr1885415qkc.13.1525970206853; Thu, 10 May 2018 09:36:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.212.13 with HTTP; Thu, 10 May 2018 09:36:46 -0700 (PDT) In-Reply-To: <23248.26552.790605.595114@fireball.acr.fi> References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> <23248.26552.790605.595114@fireball.acr.fi> From: Shibu Date: Thu, 10 May 2018 22:06:46 +0530 Message-ID: To: Tero Kivinen Cc: Ron Bonica , "ipsec@ietf.org" , Michael Richardson , Valery Smyslov Content-Type: multipart/alternative; boundary="0000000000001e1021056bdca0e5" Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:36:50 -0000 --0000000000001e1021056bdca0e5 Content-Type: text/plain; charset="UTF-8" Hello Tero and all, We discussed internally among the authors and it looks there exist 3 choices - to do PMTUD over IKE, or ESP or both. (Many reviewers have already pointed out these at various stages, just collating them here). PMTUD over IKE is needed anyways for large IKE cert payloads, so if we do PMTUD over IKE, we could depend upon the same discovered MTU value for ESP paths as well as a guidance value. This seems to work for most of the cases, and there seems to be interest in the group towards this option. So this looks to be a good option overall, if we tackle IKEv2 window nuances effectively. However, one caveat with above approach is that there is an implicit assumption that paths for control and data traffic are same (i.e. IP based, 3 tupple paths). With SDWAN use cases (wherein paths could be orchestrated based on proto, port, QoS, App ID etc), would it be a precise assumption to make? How would we handle these cases when the paths are build for ESP and IKE differently? Thanks, Shibu. On Fri, Apr 13, 2018 at 1:48 PM, Tero Kivinen wrote: > Ron Bonica writes: > > In 99.9% of cases you are probably correct. If there is an ECMP > > between the encrypting node and the decrypting node, all ECMPs have > > the same PMTU. > > Is it 99.9%, or 99.9999%? > > > And because this is true in such a vast majority of cases, none of > > us have seen a situation where one ECMP has a larger PMTU than then > > next. > > If none has not yet been seen it is much closer to 100% than 99.9%. > Depending of course how many setups people have seen... > > > However, we still need to be prepared for that rare situation where > > one ECMP does have a greater PMTU that the next. Although black > > swans are rare, they bite very hard! > > There is also option to say that network is so broken that we fall > back to IPsec over TCP, and in that case both ESP and IKE packets go > inside same TCP stream and MTU discovery is done simlarly for both, so > things work. I.e., that might be acceptable solution for those rare > really broken cases. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0000000000001e1021056bdca0e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Tero and all,

We discussed internally am= ong the authors and it looks there exist 3 choices - to do PMTUD=C2=A0 over= IKE, or ESP or both. (Many reviewers have already pointed out these at var= ious stages, just collating them here).

PMTUD over IKE is needed any= ways for large IKE cert payloads, so if we do PMTUD over IKE,=C2=A0 we coul= d depend upon the same discovered MTU value for ESP paths as well as a guid= ance value. This seems to work for most of the cases, and there seems to be= interest in the group towards this option. So this looks to be a good opti= on overall, if we tackle IKEv2 window nuances effectively.

However, = one caveat with above approach is that there is an implicit assumption that= paths for control and data traffic=C2=A0 are same (i.e. IP based, 3 tupple= paths).
With SDWAN use cases (wherein paths could be orchestrated based= on proto, port, QoS, App ID etc), would it be a precise=C2=A0 assumption t= o make? How would we handle these cases when the paths are build for ESP an= d IKE differently?

Thanks,
Shibu.


On Fri,= Apr 13, 2018 at 1:48 PM, Tero Kivinen <kivinen@iki.fi> wrote:<= br>
Ron Bonica writes:
> In 99.9% of cases you are probably correct. If there is an ECMP
> between the encrypting node and the decrypting node, all ECMPs have > the same PMTU.

Is it 99.9%, or 99.9999%?

> And because this is true in such a vast majority of cases, none of
> us have seen a situation where one ECMP has a larger PMTU than then > next.

If none has not yet been seen it is much closer to 100% than 99.9%.
Depending of course how many setups people have seen...

> However, we still need to be prepared for that rare situation where > one ECMP does have a greater PMTU that the next. Although black
> swans are rare, they bite very hard!

There is also option to say that network is so broken that we fall
back to IPsec over TCP, and in that case both ESP and IKE packets go
inside same TCP stream and MTU discovery is done simlarly for both, so
things work. I.e., that might be acceptable solution for those rare
really broken cases.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--0000000000001e1021056bdca0e5-- From nobody Thu May 10 09:46:09 2018 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 1B888126DFB for ; Thu, 10 May 2018 09:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EB6_VQBfOsYg for ; Thu, 10 May 2018 09:46:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3776A126C2F for ; Thu, 10 May 2018 09:46:04 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w4AGk0bp017547 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 19:46:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w4AGk0Bp022886; Thu, 10 May 2018 19:46:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23284.30535.955547.284990@fireball.acr.fi> Date: Thu, 10 May 2018 19:45:59 +0300 From: Tero Kivinen To: Shibu Cc: Ron Bonica , "ipsec\@ietf.org" , Michael Richardson , Valery Smyslov In-Reply-To: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> <23248.26552.790605.595114@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:46:07 -0000 Shibu writes: > With SDWAN use cases (wherein paths could be orchestrated based on pr= oto, > port, QoS, App ID etc), would it be a precise=A0 assumption to make=3F= How would > we handle these cases when the paths are build for ESP and IKE differ= ently=3F If the ESP and IKEv2 packates do not follow the same path, then it is possible that the ESP path is broken, and when we run the test over IKEv2 path to see whether connection is broken or not, we do get result that it works, even when ESP does not. Because of this I would say that every SDWAN implementation should try to make sure that all ESP and IKEv2 packets do use the same path as otherwise there might be black holes, or repeated tearing down SAs and recreating them (i.e., if ESP works but IKEv2 does not). In case someone still makes implementation which does that, then IKEv2 can use UDP encapsulation and then both IKEv2 and ESP packets do follow same path. I.e., try to avoid those, or if you make them, make sure they have same PMTU, and if you cannot ensure that, enable UDP encapsulation in IPsec...=20 --=20 kivinen@iki.fi From nobody Thu May 10 09:47:07 2018 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 5F08712EB50 for ; Thu, 10 May 2018 09:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 itQQfFmikZ38 for ; Thu, 10 May 2018 09:46:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D57126C2F for ; Thu, 10 May 2018 09:46:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8BEF720090; Thu, 10 May 2018 12:58:47 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id AF3772E37; Thu, 10 May 2018 12:46:36 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id ACD8D2E05; Thu, 10 May 2018 12:46:36 -0400 (EDT) From: Michael Richardson To: Shibu , "ipsec\@ietf.org" In-Reply-To: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> <23248.26552.790605.595114@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:47:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Shibu wrote: > PMTUD over IKE is needed anyways for large IKE cert payloads, so if w= e do > PMTUD over IKE, we could depend upon the same discovered MTU value f= or ESP > paths as well as a guidance value. This seems to work for most of the > cases, and there seems to be interest in the group towards this optio= n. So > this looks to be a good option overall, if we tackle IKEv2 window nua= nces > effectively. I agree. This handles 90% of the cases, except for bigger more nuanced env= ironments. > However, one caveat with above approach is that there is an implicit > assumption that paths for control and data traffic are same (i.e. IP > based, 3 tupple paths). > With SDWAN use cases (wherein paths could be orchestrated based on pr= oto, > port, QoS, App ID etc), would it be a precise assumption to make? How > would we handle these cases when the paths are build for ESP and IKE > differently? I suggest that in such a situation, that *IKE* negotiate (probably just Notify's to announce actually) the existence of a TCP endpoint that is with= in the tunnel, and do PLMUTD over TCP across that to test things. In some situations the IKE daemon would be able to do the connection attempt itself, but in other situations, some other entity might have to do this. Much of this is a local implementation problem only the Notify needs to be standarized. There might be IPv6 sockets API extensions that might be desired to get TCP MTU information out the kernel, but that's not ipsecme's problem :-) The IKE then needs to update the ESP machinery to know what the MTU of the inside of the tunnel appears to be, and it should generate ICMPs if it's bigger. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWvR3aYCLcPvd0N1lAQI8ngf9EnMdt0hec5ib5Y4Ln39fNJ9w3FeqysCI DZSqEkXECQRdJwDmB13S99bxlbo6sCEMzr/smkCwkhp9zjKqW85xXenBc5rknfNz Fms8IT/++M6nlRrzxM4kmrEImnZqZ/bmmFPT/xjVeo5mcBCXtrOL0Ikh9Zq0hXBy j/1BsHMFIhV0kGBl47+5Bg5KAMw9OnqFx46RQPnFa0gBWdKS80fpnTmldWo7LLCQ 8Kb75oIBlR/WoioBvoL5quSrprNCRVAelGSMd2lI5XDD/wH5DlY6/acw4hoTylWx mU/CtC5qwFhOsDZIZlga3CaZhlEfaIiqQcPxv9EF5CfiPupXSSk/aw== =ncwO -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 10 09:52:24 2018 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 78B8C12EB73; Thu, 10 May 2018 09:52:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152597112644.10319.8129331031620563095@ietfa.amsl.com> Date: Thu, 10 May 2018 09:52:06 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-implicit-iv-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:52:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP) Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-ietf-ipsecme-implicit-iv-04.txt Pages : 7 Date : 2018-05-10 Abstract: Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-implicit-iv-04 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-implicit-iv-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-implicit-iv-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 10 09:52:29 2018 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 0933F12EB8B for ; Thu, 10 May 2018 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 CE_iOvz2jDm7 for ; Thu, 10 May 2018 09:52:05 -0700 (PDT) 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 E2F8312D941 for ; Thu, 10 May 2018 09:52:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 40hfQS40H0z35G; Thu, 10 May 2018 18:52:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1525971120; bh=FsMA8yZYq6k++qUKfW1xJUFdnBXUer4nbETj7mYnaQw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XV8S0rDuLTnDUteIihYh4JLRkuaoNawuYx0Ppm2TgKngc8vXJI4fTH/p66PeRT5Ql NBGeQEQeI+H9P8upPMc95IbK+dMYszVOjZWMY0Kx/i84Du325JBO8VoFgi7SXwI8qt yHCNi8LxfKGnoXNms0RoEI+li9DgS0zVmckVe/EI= 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 D1ZC9dXGQqCB; Thu, 10 May 2018 18:51:58 +0200 (CEST) Received: from bofh.nohats.ca (vpn.nohats.ca [193.110.157.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 10 May 2018 18:51:58 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3F65E4AB8E8; Thu, 10 May 2018 12:51:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3F65E4AB8E8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 372264000C7F; Thu, 10 May 2018 12:51:57 -0400 (EDT) Date: Thu, 10 May 2018 12:51:57 -0400 (EDT) From: Paul Wouters To: Shibu cc: "ipsec@ietf.org" In-Reply-To: Message-ID: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> <23248.26552.790605.595114@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:52:18 -0000 On Thu, 10 May 2018, Shibu wrote: > PMTUD over IKE is needed anyways for large IKE cert payloads I don't agree. We can handle these with fragmentation now just fine. > However, one caveat with above approach is that there is an implicit assumption that paths for control and data traffic  > are same (i.e. IP based, 3 tupple paths). > With SDWAN use cases (wherein paths could be orchestrated based on proto, port, QoS, App ID etc), would it be a precise  > assumption to make? How would we handle these cases when the paths are build for ESP and IKE differently? Right. UDP 4500 packets not starting with 4 zero bytes could be handled differently. Paul From nobody Thu May 10 09:53:23 2018 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 97562126B72; Thu, 10 May 2018 09:53:21 -0700 (PDT) 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, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Vlci0wi_blRB; Thu, 10 May 2018 09:53:19 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090D412D88A; Thu, 10 May 2018 09:53:09 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id b18-v6so3241679lfa.9; Thu, 10 May 2018 09:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=REI5Eu2trYIGpk7wMQf5Llcsp7xIapUk0dSXUojjBtc=; b=pSisYvQUDMkTZq457Lago8G0gF0GDuwVXH3BNE93XZuJspFYLkFvR/tm/mgetJ39rc JaUw1atbLoiaxO7yAKjEQsCxk7hsxeNI0u1Uqxgm+aFS7JX2hqaCwEKyn+Pv8WJFaXPE hAdeuzBLf1MPEVquRO87hfGANLfFpxg3RmaBik8C6ddpxXNpmHLusBkO1l/OTbFmyW8K gmCtJ+G03i+ofry/D8AOINfve68k7P1j1vT68hKZX+L65iqBKvxZOv2PEEIofRBeAvyA 5P1riLFPkDTPniBnucYDskCkVy/ef6HMgRkTRN2LmLFb8+R9S7g/OA2BO2cQx05wb57/ nyRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=REI5Eu2trYIGpk7wMQf5Llcsp7xIapUk0dSXUojjBtc=; b=sy0PZvrNtAtmXKFk407VR5hq2l9LhkFD7HMqYjD6dbL2B77gcqKzqeHe7kGQXRw93f 8kmqInO5gxXA3sB9yNOGyGHxn3TsX7qyUVI1593lb53GY9s925wCICAFVLATvGrd5QL2 txiAXUXij/IdGpwgh5N5mLhEamTvubr916/OmaVvcwD/HQRXOTPF+EHnbP0A7ylATete S95gEazTF34ZAbpZfQuz/cm/at0KPw5sr34mkCZBnsldfWRMmPTZGjXDlHHJLuocZ08f bCIoaEctREODd2VN4DAOSbOkXa7BuwzhaGimKil3VvwYj2DYu9snkc7HuxGkkV/ezizD LkCg== X-Gm-Message-State: ALKqPwf1Ut+9viCbVGA3hz1povPj+QOhtrvLb/EhPJYd+yVGNcoyf1aT xx+3crDveMUJfMDp7RF/fkQorIIpQcJRakBDSTo= X-Google-Smtp-Source: AB8JxZpIVUE0Sar7eLngnqfGMi6ceahfpdF5lWt/XEPqPptStVQaAX1aDbIR2ry6UhbgQgYm3zeNeeg2LLzjZKFbWFI= X-Received: by 2002:a19:c6c1:: with SMTP id w184-v6mr1508659lff.126.1525971185930; Thu, 10 May 2018 09:53:05 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.20.73 with HTTP; Thu, 10 May 2018 09:53:05 -0700 (PDT) In-Reply-To: <23284.23787.935682.175733@fireball.acr.fi> References: <23239.54227.814560.228778@fireball.acr.fi> <23284.23787.935682.175733@fireball.acr.fi> From: Daniel Migault Date: Thu, 10 May 2018 12:53:05 -0400 X-Google-Sender-Auth: NRbBCs2qWPPQZzIyfpSXDQ_iMZI Message-ID: To: Tero Kivinen Cc: IPsecME WG , draft-ietf-ipsecme-implicit-iv@ietf.org Content-Type: multipart/alternative; boundary="00000000000079950d056bdcda7c" Archived-At: Subject: Re: [IPsec] Comments about draft-ietf-ipsecme-implicit-iv-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 16:53:21 -0000 --00000000000079950d056bdcda7c Content-Type: text/plain; charset="UTF-8" Hi Tero, Thanks for the response. Version 4 of the draft has been updated with this alternative. Yours, Daniel On Thu, May 10, 2018 at 10:53 AM, Tero Kivinen wrote: > Daniel Migault writes: > > another alternative could be: > > > > As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are > > used, Implicit IV as described in this document MUST NOT be used in > > setups with the chance that the Sequence Number overlaps for one SA. > > Multicast as described in [RFC5374], [RFC6407] and > > [I-D.yeung-g-ikev2] is a prominent example, where many senders share > > one secret and thus one SA. As > > such, it is NOT RECOMMENDED to use Implicit IV with Multicast. > > I would actually prefer to this. I think it is better to say don't do > it, than provide ways it could be done before saying don't do it.... > > I.e., if someone is interested in this then we need to write new > specification that will specify how it is done, so there is no point > of speculating here what it could be. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --00000000000079950d056bdcda7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tero,

Thanks for the respo= nse. Version 4 of the draft has been updated with this alternative.

=
Yours,
Daniel

On Thu, May 10, 2018 at 10:53 AM, Tero Kivinen <kivinen= @iki.fi> wrote:
Daniel Migault writes:
> another alternative could be:
>
> As the IV MUST NOT repeat for one SA when Counter-Mode ciphers are
> =C2=A0=C2=A0 used, Implicit IV as described in this document MUST NOT = be used in
> =C2=A0=C2=A0 setups with the chance that the Sequence Number overlaps = for one SA.
> =C2=A0=C2=A0 Multicast as described in [RFC5374], [RFC6407] and
> =C2=A0=C2=A0 [I-D.yeung-g-ikev2] is a prominent example, where many se= nders share
> =C2=A0=C2=A0 one secret and thus one SA.=C2=A0 As
> =C2=A0=C2=A0 such, it is NOT RECOMMENDED to use Implicit IV with Multi= cast.

I would actually prefer to this. I think it is better to say don'= ;t do
it, than provide ways it could be done before saying don't do it....
I.e., if someone is interested in this then we need to write new
specification that will specify how it is done, so there is no point
of speculating here what it could be.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--00000000000079950d056bdcda7c-- From nobody Fri May 11 01:55:24 2018 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 1010312785F for ; Fri, 11 May 2018 01:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.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 uIPf3HW_1Uk0 for ; Fri, 11 May 2018 01:55:16 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 044561270A0 for ; Fri, 11 May 2018 01:55:15 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id y10-v6so5408390otg.10 for ; Fri, 11 May 2018 01:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=BuKKwIUI0o9nq2jdcO02NgF5mpJdrz45X61ZizVy16M=; b=pJoulJqN3hygwcQYuEaXbxi/xGc3CGdCdaSqlts0um/KAZLmwZc/8mOMi40g8/zBFf UJcdZIgQCz+NPWIXvorP7bwHoCDGtQ+TSuSdv02JkANQJP6b2zainBoOod/0tGUbFGjP TqTzdse5cdcTh8k4fcYtgyW1SExf/Iu74TgkCiez9Xr+6OOWQ5UTEANvP4ikMv7Q8I88 Q+diDcniWOloH2Zpd3FQ2O/yJkAAMMO1hDIoVsuYtfO4Kutr4U/vp85pkttWKd2rI6h0 5bpq4+pSDX85kmriqUY6vbFJ8DMz854VTe+CPMKD4L4ZpbX19OKUIwZI+Nx4aTQR1hLe VaQw== 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=BuKKwIUI0o9nq2jdcO02NgF5mpJdrz45X61ZizVy16M=; b=mcSk6JOOaMssae9rOJbIHJo20NpCWBYyzd3igWy9hcL9etlGeOXLeOvM9/k+7OPxUj sTphIf8qHYafmz6rwA/A+q+aIAyx+kezUfXiWrt+AoEjcbXR/YQTjh5sHQVJ3LC0agak cB5niOD7CvA00/XO8uXwfjneAQJnmvVN23UyEvNCortRQMlz2xXcucy9Y6QBc+1URSbc pc88w7V8QsI6erOl7mLN8hwZh4ftmsmyyXRS0U4+ftgHam+cNjmu/SnO8WJ10pRR54JX kQIPFTWKH3J4a2uZ0G3eB60aDWs9LTStMJyO9rDSIdM20MkqNXqa4VP/oWiknqVtnnTS /Sig== X-Gm-Message-State: ALKqPweHt3KhRG0/IJvaamvW6fumWvJLeUsMfyIUJohsX918/eYlSzVs Xi4qt0Qkqw16/8XRSzDVjFRCwWaOHfew8zQQ/zkLePpWNX8= X-Google-Smtp-Source: AB8JxZpyl3wZ1NYMh/fodkiMDBzOU6ss35XsJVF0sGpCLknany+DVjpITfJl4+h3g91M8RsTsswfwVqXhcUerVflU/Y= X-Received: by 2002:a9d:282d:: with SMTP id m42-v6mr3400360otb.64.1526028915021; Fri, 11 May 2018 01:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1bae:0:0:0:0:0 with HTTP; Fri, 11 May 2018 01:55:14 -0700 (PDT) From: CJ Tjhai Date: Fri, 11 May 2018 09:55:14 +0100 Message-ID: To: ipsec@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [IPsec] Direction for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 08:55:17 -0000 Hi all, Following the last IETF meeting, we would like to take the following direction for our draft: 1. Negotiation: use KE payload as described in draft-tjhai-ipsecme-hybrid-qske-ikev2-01. The main reason is backward compatibility. Not all IKEv2 implementations out there are RFC7296-compliant, while it is theoretically possible to upgrade them, but we cannot guarantee that all of them would be upgraded. With the approach described in draft-tjhai-ipsecme-hybrid-qske-ikev2-01, there won't be any issues with backward compatibility. 2. There appeared to be a consensus in using an intermediary stage, i.e. IKE_AUX, to transport the post-quantum key exchange payload. 3. There was also a suggestion in using a new payload type, e.g. PQKE or QSKE, to carry the post-quantum key exchange payload. What do people of think of this approach? Thanks, CJ From nobody Tue May 15 07:48:33 2018 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 C5E30124D37 for ; Tue, 15 May 2018 07:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, 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 5z_ZBHXSlKJi for ; Tue, 15 May 2018 07:48:31 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (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 B6BEE12D80F for ; Tue, 15 May 2018 07:48:30 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id j193-v6so635394lfg.6 for ; Tue, 15 May 2018 07:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=NINuvqZgs2X2QyGGwVbtDgLNb1sgi+4IYSBAlZzp9CY=; b=iTjbVAADVe2ffNJdrpmvB1HpqwyWpedxZI6fk/YB/eZBtMsg2snBGDrKRsJaCIZeHJ cGrvkAyz47oBL5s1XjkFY1JJQdFrVIDj1cufBKvUEdDyN0MAC3+JsuhVlWOCtz2rSr51 8WGBhgSrURKMQhVbDai+k4gRDmahOHY7zrIH+t/M0HQTlGGPQae3sXIdJcb4F3hmHBQj t2jiem9GU7l0g/vc+5oyDcf0wlg1Qi9l/kCXCOQ8zZRj0VxO2GwhstJgdSSZUEQRvbZ/ 7yISCK+bg/v+8ymdhqZaI6rDS5OAoXiNf40roEeH1LtbOQhuDPK3eEisQuCVihh8HvxZ DhuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NINuvqZgs2X2QyGGwVbtDgLNb1sgi+4IYSBAlZzp9CY=; b=mjY6YH3y+XkcYNNi6+lWiOGRVNwxRxd8wr9V+LP/eSm+oEwP024oqgkQbGa23fhDa2 Tnfda6aAlv/5bzkC+sFquDYT1u91OYaaUAETDNcYJWy2mwLdWrMOuffncwWFOgPxRebM pFHgHoHshn+hzfTHpXFakta7gOoYnHpMg4jfidJgjPDiD6/tmMfy1NINYQ3Oz8jXsYRv 9eBbrEZ+RLZIQDmE/nVoXzgKOgVLv0q5fEltX23/wDfZK0e9LEL5rxviEHLcyHZAuyOi g9gIrYNSdDlDVOnJJvA5gS0bN2sv2jiqPWZNAlNg0WP76Lg95mx7xmziZ9JqN6+PaoCR t5Og== X-Gm-Message-State: ALKqPwf1jdLHmAhHgcMG423G+bDdLiU3q3hSIBAqzTPRhqRLrXM2Gpm6 co3H++yRcImoKuhYxTNoCMmfnA== X-Google-Smtp-Source: AB8JxZobTEC1OYMb7jFhGFHVm/bnruysGxWUX8bmXEex3jIpOyRgBjg/JhTP7HIjzXn26DJVgsz1/w== X-Received: by 2002:a2e:9e57:: with SMTP id g23-v6mr7199350ljk.37.1526395708991; Tue, 15 May 2018 07:48:28 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o11-v6sm31276ljc.77.2018.05.15.07.48.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 May 2018 07:48:28 -0700 (PDT) From: "Valery Smyslov" To: "'CJ Tjhai'" , References: In-Reply-To: Date: Tue, 15 May 2018 17:48:24 +0300 Message-ID: <019701d3ec5b$c73625b0$55a27110$@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: AQKtWWpLlUaT+pZmye5MmUhxn6bb3KJ8Ev+A Content-Language: ru Archived-At: Subject: Re: [IPsec] Direction for draft-tjhai-ipsecme-hybrid-qske-ikev2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 14:48:33 -0000 Hi, > Hi all, > > Following the last IETF meeting, we would like to take the following > direction for our draft: > > 1. Negotiation: use KE payload as described in > draft-tjhai-ipsecme-hybrid-qske-ikev2-01. The main reason is backward > compatibility. Not all IKEv2 implementations out there are > RFC7296-compliant, while it is theoretically possible to upgrade them, > but we cannot guarantee that all of them would be upgraded. With the > approach described in draft-tjhai-ipsecme-hybrid-qske-ikev2-01, there > won't be any issues with backward compatibility. Well, this was discussed on the list and it is my impression, that those who expressed their opinion (Tero [1], PaulW [2], myself [3]) prefer to re-use existing mechanism. I cannot recall that anybody on the list or in London argued for using KE payload for negotiation. Have I missed something? I understand your concern about existence of non-compliant implementations, but in my opinion adding QSKE into IKEv2 is not an immediate task, so there must be plenty of time for vendors to fix their implementations. I don't want to introduce new negotiation mechanism when we already have one that was specially designed for this purpose. > 2. There appeared to be a consensus in using an intermediary stage, > i.e. IKE_AUX, to transport the post-quantum key exchange payload. Agree. > 3. There was also a suggestion in using a new payload type, e.g. PQKE > or QSKE, to carry the post-quantum key exchange payload. I believe there will be no need for new payload if existing negotiation mechanism is re-used. What is the reason for introduction of new payload? > What do people of think of this approach? > > Thanks, > CJ Regards, Valery. [1] https://mailarchive.ietf.org/arch/msg/ipsec/lW4cFBLagNMdAx2VOSrz1z8VJF0 [2] https://mailarchive.ietf.org/arch/msg/ipsec/XqhkCN4u5vpRugE_Bg_TkP-hDGs [3] https://mailarchive.ietf.org/arch/msg/ipsec/jahWqh_dvPkqAXnA4-C9LndtWWk From nobody Thu May 24 08:07:19 2018 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 E529812E873 for ; Thu, 24 May 2018 08:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-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=ericsson.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 O1gPY8UZiVGg for ; Thu, 24 May 2018 08:07:15 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 74FE5127023 for ; Thu, 24 May 2018 08:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1527174433; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xpjA4odq45dR9y8rsQ3tmOaSkIInNlI6OfjbR+E3vMk=; b=URrL1y4oRi5Y9o5vm9Ls8OW+kClOwl1/BBqsGzHGQlSdKoBZbpPjaRpGd52UZY9k mGFNhiHUE5Y9o5iAD8MlUqxUsWhmwdPdIpjIDk+PWpQDvA3hwxS/zDaJiWD3Nqr/ aABUOP8TP2rUkGMR6wmBph5w9LbIv9GkoLhOdCTrb4A=; X-AuditID: c6180641-3cdff70000005966-6a-5b06d521d019 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id E4.F1.22886.125D60B5; Thu, 24 May 2018 17:07:13 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0382.000; Thu, 24 May 2018 11:07:12 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: Linux networking conference @Montreal July 11-13 Thread-Index: AdPzcHLdxcxHPBXCQ7usWPECj6g1yA== Date: Thu, 24 May 2018 15:07:12 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118E623A4@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.221] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118E623A4eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPoK7iVbZog+/XTS32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA1XtrMU7FaseHpUrYHxjWwXIyeHhICJxNp5naxdjFwcQgJH GSXu7GtngXCWM0osvf2EHaSKTcBIou1QP5DNwSEiIC8x80YmSFhYwEpi/9+5bCC2iIC9xMb5 R1khbD2Jwz+WMIHYLAKqEmcvLAMbwyvgK3GmuwOsnlFATOL7qTVgNcwC4hK3nsxngjhIQGLJ nvPMELaoxMvH/1ghbGWJ66uusEDU50vcP9HMCjFTUOLkzCcsExgFZyEZNQtJ2SwkZRBxHYkF uz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcUFObrqR4SZGYHgfk2Bz3MG4t9fzEKMAB6MS D+/aPWzRQqyJZcWVuYcYJTiYlUR4FyQBhXhTEiurUovy44tKc1KLDzFKc7AoifOe8+SNEhJI TyxJzU5NLUgtgskycXBKNTBKZa3jaUn+nWm6ZNGMg1vceyUXnZE1fX0yoHb99pgf6nsO1jU3 L822mvLDPGA2V1nt+oZb4l8dbjZF2pdZFc20mfZkzWM/6ULmNYf/fT2iz/VS+s6llzZd8W4v irmvzhfLed2b4W942+Mm4wZRlourLwaabr7c92Ry42aets0pDlF9FX7r1nspsRRnJBpqMRcV JwIAZy0sR2sCAAA= Archived-At: Subject: [IPsec] Linux networking conference @Montreal July 11-13 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 15:07:18 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118E623A4eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The Linux networking conference July 11-13 is happening in Montreal right b= efore the IETF July 14 - 20. I thought it might be interesting for some of= you to combine these two network related events. https://www.netdevconf.org/0x12/ Accepted sessions are announced on the flow. Some sessions accepted alread= y: https://www.netdevconf.org/0x12/accepted-sessions.html More exciting stuff coming. Registration is still in early bird mode (20% off) until June 1st. https://www.netdevconf.org/0x12/registration.html Yours, Daniel --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118E623A4eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, 

 

The Linux networking conference July 11-13 is happen= ing in Montreal right before the IETF  July 14 – 20. I thought i= t might be interesting for some of you to combine these two network related= events.

https://www.netdevconf.org/0x12/

 

Accepted sessions are announced on the flow.  S= ome sessions accepted already:

https://www.netdevconf.org/0x1= 2/accepted-sessions.html

More exciting stuff coming.

 

Registration is still in early bird mode (20% off) u= ntil June 1st.

https://www.netdevconf.org/0x12/reg= istration.html

 

 

Yours, 

Daniel

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118E623A4eusaamb107erics_-- From nobody Mon May 28 12:48:49 2018 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 7F36712D946; Mon, 28 May 2018 12:48:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ekr@rtfm.com, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152753692745.4855.2127423357151865732.idtracker@ietfa.amsl.com> Date: Mon, 28 May 2018 12:48:47 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 102 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 19:48:48 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- 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: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue May 29 13:04:30 2018 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 D13A712F4E4 for ; Tue, 29 May 2018 13:04:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152762425985.29731.4355943492063088576.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2018 13:04:19 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:04:28 -0000 Changed milestone "IETF Last Call on Split-DNS Configuration for IKEv2", set due date to June 2018 from April 2018. Changed milestone "IETF Last Call on Implicit IV in IPsec", set due date to June 2018 from April 2018. Changed milestone "IETF Last Call on partially quantum resistant IKEv2", set due date to August 2018 from May 2018. URL: https://datatracker.ietf.org/wg/ipsecme/about/ From nobody Wed May 30 07:49:16 2018 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 DC5221272E1 for ; Wed, 30 May 2018 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meGkaLHerpq8 for ; Wed, 30 May 2018 07:49:13 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 A538A12D77C for ; Wed, 30 May 2018 07:49:12 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id 185-v6so14538075qkk.11 for ; Wed, 30 May 2018 07:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ScB54pK81BwKcng+N2QxjkhThZ5UXUFpS6XACpTHI5E=; b=kvCLZss4z9jX1sTalkDoUA+pBLAAIo4pKPrvsNazZcXsLEoeoH3OhZmqW5W5cIc5ee MfG/wkETWrDlnDeFTz8dzuy8FxYoWvaqL770U/wGfAYiU15CXwUhGfR9z5ZRk500NlV9 offp7LkCxvQOEYk8B4gbL/jEPBK2wowYUUM+mDtHOn4hnMY4gS53QgR/5tKLumh9S7sX xzlbWiXchYE1WvPPLusZ7Twu/qg12DLR+OysAbymbp6em+ACRRpyrVZ+4NGaSoJC39Of 4/uThFaCifcEb5bjumUNY98DV/SaQUaFWCdvo65DTpigUu/l8EA6SuOHil640UVn1QRu gmDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ScB54pK81BwKcng+N2QxjkhThZ5UXUFpS6XACpTHI5E=; b=FuFwqra5czzuR8NCZ0w0IrqlIX3vJDQ8s3MniV3FLOgT8WrbpCd9hc8SDVe9Hx5Q85 5ZyDJ5UgSlFavw1O7gBk5XP+CDspyJq8FO2owbJmwOODbd9+HN6KwnaVjteVSOZ+4UiF gKPZpIfcEITi0/4jlnSJ9guuwLgZFz8Hy/LXcwEVV+lkklAhDz+ppAwky+zZKdZFLIE4 k0/CoSiyRHegKNLpBmPg822AT/o96MWlcBLW1bZfHV7xkFuumq7XZad5pqQdZ57l/TkX 69uEcxOLp8nlQEKSoPrERuEI1+4VinLzIxJ5SFW+DR+uZeOIh8cZQ64LTeJ1RpWjtyQ3 regw== X-Gm-Message-State: APt69E1Yc7YmUcUjwzjDpmuh0E5GtXQPs+XiHGzOoFsUAFAyTlmKnE5X uVOCydWqwz0rEVNSLo2Oy+Fe7EEsvVgo04iItcdDGg== X-Google-Smtp-Source: ADUXVKLfGA2ULa4Dhxexh2Pcd2Rn5L+tqzzkkRmChvzFsPwB2jaRT2zmwVLfbiX6SCVNoOpJRK2oGEirx7Ttp/zSeyE= X-Received: by 2002:a37:d1d0:: with SMTP id o77-v6mr1620393qkl.185.1527691751805; Wed, 30 May 2018 07:49:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:d40d:0:0:0:0:0 with HTTP; Wed, 30 May 2018 07:49:11 -0700 (PDT) In-Reply-To: References: <11057.1522877721@obiwan.sandelman.ca> <003c01d3ccd2$db7c20e0$927462a0$@gmail.com> <1172.1522940927@obiwan.sandelman.ca> <012601d3cd78$343cdd50$9cb697f0$@gmail.com> <02e401d3d099$281d2a10$78577e30$@gmail.com> <23244.38734.270422.683057@fireball.acr.fi> <23248.26552.790605.595114@fireball.acr.fi> From: Shibu Date: Wed, 30 May 2018 20:19:11 +0530 Message-ID: To: Paul Wouters Cc: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary="000000000000315600056d6d74ee" Archived-At: Subject: Re: [IPsec] PLMTUD probes for IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:49:15 -0000 --000000000000315600056d6d74ee Content-Type: text/plain; charset="UTF-8" On Thu, May 10, 2018 at 10:21 PM, Paul Wouters wrote: > On Thu, 10 May 2018, Shibu wrote: > > PMTUD over IKE is needed anyways for large IKE cert payloads >> > > I don't agree. We can handle these with fragmentation now just fine. > > IKE Fragmentation internally utilize an MTU value - either the lowest MTU or the one discovered via PMTUD. If we use the lowest value of 1280 (say for v6) most of the link capacity (9k jumbo frames) is under utilized. This will have adverse effect on tunnel setup rate also. I think, PMTUD complements the IKE fragmentation use case, not the other way around, Isn't it ? However, one caveat with above approach is that there is an implicit >> assumption that paths for control and data traffic >> are same (i.e. IP based, 3 tupple paths). >> With SDWAN use cases (wherein paths could be orchestrated based on proto, >> port, QoS, App ID etc), would it be a precise >> assumption to make? How would we handle these cases when the paths are >> build for ESP and IKE differently? >> > > Right. UDP 4500 packets not starting with 4 zero bytes could be handled > differently. > > Thanks, Shibu. --000000000000315600056d6d74ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, May 10, 2018 at 10:21 PM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 10 May 2018, Shibu wr= ote:

PMTUD over IKE is needed anyways for large IKE cert payloads

I don't agree. We can handle these with fragmentation now just fine.
=C2=A0
IKE Fragmentation=C2=A0 internally u= tilize an MTU value - either the lowest MTU or the one discovered via PMTUD= .
If we use the lowest value of 1280=C2=A0 (say for v6) most = of the link capacity (9k jumbo frames) is under utilized. This will have ad= verse effect on tunnel setup rate also. I think, PMTUD complements the IKE = fragmentation use case, not the other way around, Isn't it ?
<= div>
However, one caveat with above approach is that there is an implicit assump= tion that paths for control and data traffic=C2=A0
are same (i.e. IP based, 3 tupple paths).
With SDWAN use cases (wherein paths could be orchestrated based on proto, p= ort, QoS, App ID etc), would it be a precise=C2=A0
assumption to make? How would we handle these cases when the paths are buil= d for ESP and IKE differently?

Right. UDP 4500 packets not starting with 4 zero bytes could be handled
differently.


Thanks,
Shibu.
--000000000000315600056d6d74ee-- From nobody Wed May 30 12:05:58 2018 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 E95DF12D87E for ; Wed, 30 May 2018 12:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 EkE7X92zzCBv for ; Wed, 30 May 2018 12:05:53 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF53412E8C7 for ; Wed, 30 May 2018 12:05:53 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 56EF5A00920B; Wed, 30 May 2018 12:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=dh5UJDwwG8wT1X yTfuskLUzEg2o=; b=FZZw5jURRKkpX2ppLLbhb9exu5jojQN1CouBNpUBX8KdH5 CKWW6+jrh++WGEUqskNyQB0XRtbWDHLG6Dsjo1d8dZ8ohwlEUTXzNfwwUr/qqXcO M8RTZRVnlMURfuxq91kdPJgdCxLBSELOAA65y5kcYtHzM4Cg6AHlPpKBRo3i8= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 0B136A009206; Wed, 30 May 2018 12:05:51 -0700 (PDT) Date: Wed, 30 May 2018 14:05:50 -0500 From: Nico Williams To: Paul Wouters Cc: "ipsec@ietf.org WG" Message-ID: <20180530190548.GE14446@localhost> References: <18031.1525203348@obiwan.sandelman.ca> <26213.1525367918@localhost> <23275.40687.119581.370767@fireball.acr.fi> <20180504034610.GC4242@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [IPsec] Labeled IPsec questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 19:05:56 -0000 On Mon, May 07, 2018 at 12:40:08AM -0400, Paul Wouters wrote: > On Thu, 3 May 2018, Nico Williams wrote: > I agree. But see Tero's post on why he prefers NOTIFY. I mean, as long as it works, that's fine. > >>This I don't like as much. I'd rather see a failure on the responder on > >>some critical flag payload it does not understand. > > > >Yeah, but it's not that big a deal to not have that failure on the > >responder. Presumably the initiator will just delete the then-useless > >SA, else the responder will hold that resource for a while. > > That's true. So, NOTIFY works. But notionally, to me, it's a traffic selector. The specific details of how it's carried in IKE are not as interesting. > >>But also, the initiator should not yet have Child SA's ? (but that might > >>be implementation specific) > > > >In that case the parent IKE SA may have a broader label range/set than > >the child SAs. > > The labels we are talking about are for traffic flowing through IPsec > SA's. I don't understand why you now talk about IKE SA labels. In > general, all IKE traffic is holed specifically from any IPsec SA as to > ensure IKE can flow even in case of lost IPsec SA's. So there is no need > to consider the label of UDP (4)500 packets. I'd expect labeled IKE SAs to be a use case too (where the labels/label sets are obtained from credentials such as PKIX certificates or from the local PAD). > >Assuming the label ranges/sets are carried by the nodes' credentials, > >then there is no need for a label proposal unless the nodes wish to > >narrow the resulting SAs' label ranges. > > I think what you are saying here is that if both ends require a specific > label for traffic, it is defacto preconfigured and doesn't need to be > negotiated. But that limits things to preconfigured on a peer to peer No, that's just one use case. You could create child SA pairs with different labels from the parent IKE SAs, provided the parent label range dominates the child labels. > basic, and might not work well for Opportunistic IPsec, eg a mesh crypto > network. Peers might still want to 'announce' the label they will give Yes, absolutely. I don't want to preclude that! I hope that's clear. > to the received decrypted traffic and nodes might accept multiple labels > so in that case there might be some kind of negotiation happening. But > even if the nodes just confirm the label configured to each other, that > would likely be useful for debugging - even if it is technically not a > negotiation of label. > > >I mean, it can work fine. Notionally, ISTM that a pack flow's 5-tuple > >and label both are used to select SAs, therefore labels are -at least > >notionally- traffic selectors. > > Again, agreed. The question though, is whether it is worth doing it as a > traffic selector or should we use a notify? As long as a) the protocol (IKE) can carry the labels, b) IKE SAs can be labeled, c) child/manual SAs can be labeled, I'm OK with it. I would mostly leave label dominance semantics out of the spec, but some security considerations text should discuss that. Nico --