From nobody Fri Oct 12 17:04:25 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 89A23130E5F; Fri, 12 Oct 2018 17:04:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.86.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153938906356.29209.4378572412701760763.idtracker@ietfa.amsl.com> Date: Fri, 12 Oct 2018 17:04:23 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-boucadair-ipsecme-ipv6-ipv4-codes in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:04:24 -0000 The IPSECME WG has placed draft-boucadair-ipsecme-ipv6-ipv4-codes in state Call For Adoption By WG Issued (entered by Tero Kivinen) The document is available at https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ From nobody Fri Oct 12 17:09: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 0ED8F12D4E6 for ; Fri, 12 Oct 2018 17:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 EbJEC2B_52Da for ; Fri, 12 Oct 2018 17:09:23 -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 20D811294D7 for ; Fri, 12 Oct 2018 17:09:22 -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 w9D09JPj003201 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 13 Oct 2018 03:09:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w9D09J8n001101; Sat, 13 Oct 2018 03:09:19 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23489.14255.823837.581954@fireball.acr.fi> Date: Sat, 13 Oct 2018 03:09:19 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:09:27 -0000 Our new charter has been approved and that includes item: RFC7296 defines a generic notification code that is related to a failure to handle an internal address failure. That code does not explicitly allow an initiator to determine why a given address family is not assigned, nor whether it should try using another address family. The Working Group will specify a set of more specific notification codes that will provide sufficient information to the IKEv2 initiator about the encountered failure. A possible starting pointing is draft-boucadair-ipsecme-ipv6-ipv4-codes. So this email will start one week long WG adoptation call for that document [1] for WG adoptation. Send your comments to this list before the 2018-10-21. [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ -- kivinen@iki.fi From nobody Fri Oct 12 17:12:36 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 451CB12D4E6 for ; Fri, 12 Oct 2018 17:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 WlBo_LwFvz6V for ; Fri, 12 Oct 2018 17:12:34 -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 A512F128CF2 for ; Fri, 12 Oct 2018 17:12:33 -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 w9D0CVSn015194 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 13 Oct 2018 03:12:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w9D0CVh2023409; Sat, 13 Oct 2018 03:12:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23489.14447.509572.939300@fireball.acr.fi> Date: Sat, 13 Oct 2018 03:12:31 +0300 From: Tero Kivinen To: ipsec@ietf.org Reply-to: ipsecme-chairs@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] Call for presentations in Bangkok IPsecME meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 00:12:35 -0000 Bangkok meeting will be starting in few weeks. If you would like to present anything in the IPsecME meeting (Wednesday afternoon I session 13:50-15:20 2018-11-07), please send request to us at before end of next week (i.e., before 2018-10-21). -- kivinen@iki.fi From nobody Sat Oct 13 06:48: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 EEEDB130EB9 for ; Sat, 13 Oct 2018 06:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 ZN3XMFcVeS8V for ; Sat, 13 Oct 2018 06:48:15 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 9E45B130E55 for ; Sat, 13 Oct 2018 06:48:14 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id 189-v6so14757037wmw.2 for ; Sat, 13 Oct 2018 06:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4sEsJS0TD18rwBQDcZVDRHZfvFkpsL/W71FfeYPXb2s=; b=XxMqKpXmy09E5tn+VHzhytdKialo0bQm2ruoY08nelmNi8OLmjBZVkZsi9I1WTVVqa eHSe7sMeENbg1NGuNKZoDXNAZ2p6Il8WIww3wNPEH0+0X/VpPN7n8tFuruO5FahHbaFF 2bcRZ0/Ecz7JagwOmWf7zTb+EKxuzR/z4geHnk+9LHKdyJW/OHXhUWI0sB9VNUkL7Gxh RZwgepFdjYJSBv4ZEb27/HfoHmQxRF9Ua8JB1E5VHnFWrTeKqKoXZfJzbTSG1d9nrVn9 5+XnXk8LSOfwuzTyZoDf9KPMESu6wRDYp0aTNjZWxIgZnqOMruxIrCi1Y3qkqIYdbKmN TKhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4sEsJS0TD18rwBQDcZVDRHZfvFkpsL/W71FfeYPXb2s=; b=WEqEXgbLpiEDwqPU9jqS/10sV8J7w9b3VX3nck/6Mnefjp+Ymcx10HUkY4G4T4O4Dv fM0BpcDwCvgMA/IuhVxxl4jMFVy831KqixG0GL/BGQwgMomBGhUEUdZnIlM5e+37sS9Y CglwLIl7uQllwdUY2+hiUJ2OnFvA/XEE1WTZLulxqV5xqy9eAEHbsn6zPd9UC8lsNydT Qbwpg+u3Gs41QU1sEaaYxn92ONcm8TheZI7G43z/AzXL79rIsq0hXmPZLBI8kCkVaPNY 4rwCEO9uHXbbOpzgHmUXGmQmRfR6gEfp2OzcVNa7uVD3pmEJCg8AZBvQFNd1d3+AhwUt 5THw== X-Gm-Message-State: ABuFfojvVNNTMyrY6z4qo7uFUVqgfibslFc2pHtG1ggauM1Cwbs6RVwH 9l8RZxs9HCjW5zwOcen9r3Q= X-Google-Smtp-Source: ACcGV61sdBN7hOPnhK/IMiKQD5WJwChHSPD3a1kymj4b54LZRd8juXwT1iNYgrcCBFTyvgvOoyPGIw== X-Received: by 2002:a1c:13c4:: with SMTP id 187-v6mr8265295wmt.66.1539438493055; Sat, 13 Oct 2018 06:48:13 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e14-v6sm4929619wrs.69.2018.10.13.06.48.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Oct 2018 06:48:11 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Yoav Nir In-Reply-To: <23489.14255.823837.581954@fireball.acr.fi> Date: Sat, 13 Oct 2018 16:48:08 +0300 Cc: ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4F393E79-D95C-4B06-B616-BA4F8FB0AE2A@gmail.com> References: <23489.14255.823837.581954@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2018 13:48:17 -0000 I believe the final document should address the stuff in RFC 5739. Also, = I=E2=80=99m not sure you need to update 7296 to add some new code = points. Neither of these is a barrier for adoption. I have read the draft and support its adoption. Yoav > On 13 Oct 2018, at 3:09, Tero Kivinen wrote: >=20 > Our new charter has been approved and that includes item: >=20 > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address > family is not assigned, nor whether it should try using another > address family. The Working Group will specify a set of more > specific notification codes that will provide sufficient > information to the IKEv2 initiator about the encountered failure. > A possible starting pointing is > draft-boucadair-ipsecme-ipv6-ipv4-codes. >=20 > So this email will start one week long WG adoptation call for that > document [1] for WG adoptation. >=20 > Send your comments to this list before the 2018-10-21. >=20 > [1] = https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Oct 14 23:05: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 6AEA9130E06 for ; Sun, 14 Oct 2018 23:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 B72xAOmV9KU7 for ; Sun, 14 Oct 2018 23:05:03 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CA16127333 for ; Sun, 14 Oct 2018 23:05:03 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 42YSb14S4Gz10GP; Mon, 15 Oct 2018 08:05:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 42YSb13mrwz1xpF; Mon, 15 Oct 2018 08:05:01 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0415.000; Mon, 15 Oct 2018 08:05:01 +0200 From: To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes Thread-Index: AQHUYokNxoHhRXGhw0e+W0r1RAC0zaUf1CLA Date: Mon, 15 Oct 2018 06:05:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFF1AA7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <23489.14255.823837.581954@fireball.acr.fi> In-Reply-To: <23489.14255.823837.581954@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 06:05:06 -0000 Hi all,=20 I support adoption, obviously.=20 FWIW, I have no IPR related to this draft.=20 Cheers, Med > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Tero Kivinen > Envoy=E9=A0: samedi 13 octobre 2018 02:09 > =C0=A0: ipsec@ietf.org > Objet=A0: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6= -ipv4- > codes >=20 > Our new charter has been approved and that includes item: >=20 > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address > family is not assigned, nor whether it should try using another > address family. The Working Group will specify a set of more > specific notification codes that will provide sufficient > information to the IKEv2 initiator about the encountered failure. > A possible starting pointing is > draft-boucadair-ipsecme-ipv6-ipv4-codes. >=20 > So this email will start one week long WG adoptation call for that > document [1] for WG adoptation. >=20 > Send your comments to this list before the 2018-10-21. >=20 > [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-co= des/ > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Oct 16 23:59:18 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 2CBCE130E6D for ; Tue, 16 Oct 2018 23:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_NONE=-0.0001, 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 R4rbIXVG-kWS for ; Tue, 16 Oct 2018 23:59:14 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 4BE891277D2 for ; Tue, 16 Oct 2018 23:59:14 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id r83-v6so23253519ljr.7 for ; Tue, 16 Oct 2018 23:59:14 -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=9ugOhSOgIpANdWGHX0DwJGuFtkvQ4EwPjWHcvuS8qqY=; b=tiCmpixEQQccj7xwYqMcFwD0kezKs8pVHyW6R8BtscDVpZ/P+bbRt6PI4zKUdgNOVY jXTcv3rnvA36mTnVy8GV1qI7ix6VZuP9mw/zKvSTHxAh2KqbUludDskYGjU5JJGFCTmH mxLSw6HBCx8Ecp9KJnVsRs9rgyRX5oXCrgfjQqrEM2wj2428+pXMwuk4WUFgki0aaOIg N53e9VB2GyhOi8xn4mWBbGCvRsaRJdTnjWEBAv+fNcthOtMnC1ZinorSG9O744aWIhFO pnREsb0Tqqfk+kYmD3D3v73lVzIZVSVllwVRRBm2DfzNplClNbcChCOejDObcCzd/KxL 2hbw== 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=9ugOhSOgIpANdWGHX0DwJGuFtkvQ4EwPjWHcvuS8qqY=; b=I1ixPGz2DudV6qvo0+seohwhm1UcGMPwEKLNghYLz+4G/rezc86hBEpH5Jr+K+5udZ EsXI6LbXonQX7oWTm+baxuUp0QXSeQTBFo+KRw5W+azjJOJWEx0U+I6jJpQ9nTiBBIkL pxGjPN891p4kVaivcqs25rwGHQLmYnnlYFTVkmofMzB2Zpvvx0n5z3jb6W0lMJmoEGOq 0D0IfZ6Nv/yAddkH4ES59cMRjYc2BrEqoTOdsQufAHCvTeEXPg+SqCP27OS4/cIda8qQ MXIkpXswSrjlFFe4XIaDNp4vJrhl5u6hdndEILuC7DZtiy0e9eXb0EZBuAtFeslb0uFG IX2Q== X-Gm-Message-State: ABuFfohlmwlg2SJAUYfgZ/ofDL/AQoJtWB1m/WO4SA2Di/60awSOUbjt elNiogg5BaBJrUk99YlgrWJ/SUQd X-Google-Smtp-Source: ACcGV60G9ENVlpun/cKgBPMcn4ud9hcNiv0DJG5EYTH67cOmu38ki8ZDLm3N5DgpjVM645phz5szdA== X-Received: by 2002:a2e:3006:: with SMTP id w6-v6mr13227343ljw.146.1539759551892; Tue, 16 Oct 2018 23:59:11 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h9-v6sm3794381ljg.8.2018.10.16.23.59.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Oct 2018 23:59:11 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <23489.14255.823837.581954@fireball.acr.fi> In-Reply-To: <23489.14255.823837.581954@fireball.acr.fi> Date: Wed, 17 Oct 2018 09:59:10 +0300 Message-ID: <030f01d465e6$e850cd40$b8f267c0$@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: AQHA30D9Y79mwkXkdoCEJXze024jCKVKDktg Content-Language: ru Archived-At: Subject: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 06:59:16 -0000 Hi, after reading the draft's introduction, I think the problem described is real. So I support adoption of this draft. That said, it seems that the current draft solves the problem in suboptimal way (too many new notifications defined), but that can be definitely discussed in the WG. And yes, I'm ready to review the draft. Regards, Valery. > Our new charter has been approved and that includes item: > > RFC7296 defines a generic notification code that is related to a > failure to handle an internal address failure. That code does not > explicitly allow an initiator to determine why a given address > family is not assigned, nor whether it should try using another > address family. The Working Group will specify a set of more > specific notification codes that will provide sufficient > information to the IKEv2 initiator about the encountered failure. > A possible starting pointing is > draft-boucadair-ipsecme-ipv6-ipv4-codes. > > So this email will start one week long WG adoptation call for that > document [1] for WG adoptation. > > Send your comments to this list before the 2018-10-21. > > [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Oct 17 06:26:47 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 E40BD130DC0 for ; Wed, 17 Oct 2018 06:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 69x7GKz8WMcr for ; Wed, 17 Oct 2018 06:26:44 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.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 0737B12D4E8 for ; Wed, 17 Oct 2018 06:26:43 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9HDMOWa038377; Wed, 17 Oct 2018 06:26:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-transfer-encoding : content-type : sender : subject : from : in-reply-to : date : cc : message-id : references : to; s=20180706; bh=Sp7Wx9Rjkw7omEy8kmSW9CbE36oIbZ5jqU0oqvpKXro=; b=IhXvXPzJQFA/NAyDC028iYk33xNC58Xi2iBLApIUWXwbo2UiKWUYmWPKgf4K+yKTjYVE dD6/sp8z5+fTNgu4wiqvZlUavQ8sJAJNwXq7+M5WJFmk/yNv3oFAzKo6R7jyQY4I4Tpe nWYXxJyQbjjx5IOEWUxWRzjs52iNgAYO+k3XZAEZ7uJ0bcG47SgYMcM1qSmIz55VRGNs d3e4FrKJp8xr0WsVf/n+4IeyJW9ZJKIFikeXQVd49ztrcuNjIY/uknqATICK6Hbkr56l 27n5IL29Vc6dDb+gItJylMqt8eM/eaG8dmjpEGQlZ4+6RCJNsiL/sJhH3Lwgw5Ws7e3c Ag== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2n3dd60k9a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 17 Oct 2018 06:26:42 -0700 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGQ00ITKW0FQK80@ma1-mtap-s01.corp.apple.com>; Wed, 17 Oct 2018 06:26:40 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGQ00500VTM4D00@nwk-mmpp-sz10.apple.com>; Wed, 17 Oct 2018 06:26:39 -0700 (PDT) X-Va-A: X-Va-T-CD: 4337a09a9b1b6735ef2a05a8efd2b8b5 X-Va-E-CD: 18cb574995d36f3c34b1938ac84825c0 X-Va-R-CD: 016a07309ee3c948be34a5c09d73c770 X-Va-CD: 0 X-Va-ID: 3c257980-915f-41ca-a452-64275d22fc34 X-V-A: X-V-T-CD: c32dbaa97f6cb839155684977103028d X-V-E-CD: 18cb574995d36f3c34b1938ac84825c0 X-V-R-CD: 016a07309ee3c948be34a5c09d73c770 X-V-CD: 0 X-V-ID: 6361283c-b1cc-4475-a504-30395c291436 Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGQ00J00V3ZS300@nwk-mmpp-sz10.apple.com>; Wed, 17 Oct 2018 06:26:36 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-16_14:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.234.97.89] (unknown [17.234.97.89]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGQ00H2CW0CVJ10@nwk-mmpp-sz10.apple.com>; Wed, 17 Oct 2018 06:26:36 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly X-Mailer: iPhone Mail (16B75) In-reply-to: <030f01d465e6$e850cd40$b8f267c0$@gmail.com> Date: Wed, 17 Oct 2018 06:26:35 -0700 Cc: Tero Kivinen , ipsec@ietf.org Message-id: References: <23489.14255.823837.581954@fireball.acr.fi> <030f01d465e6$e850cd40$b8f267c0$@gmail.com> To: Valery Smyslov X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_14:, , signatures=0 Archived-At: Subject: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 13:26:46 -0000 Agreed with Valery that this is a fine starting point to define the problem, but we will need to iterate on the details. I do support adoption. Thanks, Tommy > On Oct 16, 2018, at 11:59 PM, Valery Smyslov wrote: > > Hi, > > after reading the draft's introduction, I think the problem described > is real. So I support adoption of this draft. > > That said, it seems that the current draft solves the problem in > suboptimal way (too many new notifications defined), but that > can be definitely discussed in the WG. And yes, I'm ready to > review the draft. > > Regards, > Valery. > >> Our new charter has been approved and that includes item: >> >> RFC7296 defines a generic notification code that is related to a >> failure to handle an internal address failure. That code does not >> explicitly allow an initiator to determine why a given address >> family is not assigned, nor whether it should try using another >> address family. The Working Group will specify a set of more >> specific notification codes that will provide sufficient >> information to the IKEv2 initiator about the encountered failure. >> A possible starting pointing is >> draft-boucadair-ipsecme-ipv6-ipv4-codes. >> >> So this email will start one week long WG adoptation call for that >> document [1] for WG adoptation. >> >> Send your comments to this list before the 2018-10-21. >> >> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 18 03:05: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 7ADA4130DFC for ; Thu, 18 Oct 2018 03:05:17 -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, UNPARSEABLE_RELAY=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 Dd2Dv5E7XiJv for ; Thu, 18 Oct 2018 03:05:16 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925F0130E44 for ; Thu, 18 Oct 2018 03:05:15 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 42bPmn4sgdzFqpk; Thu, 18 Oct 2018 12:05:13 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 42bPmn3xq9zBrPV; Thu, 18 Oct 2018 12:05:13 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0415.000; Thu, 18 Oct 2018 12:04:34 +0200 From: To: Yoav Nir CC: "ipsec@ietf.org" Thread-Topic: Yoav's Comments (was RE: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) Thread-Index: AdRmx94SNANr8RJVTIm8SZkBT8u0mw== Date: Thu, 18 Oct 2018 09:49:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E000C1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [IPsec] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 10:05:18 -0000 SGkgWW9hdiwgDQoNCkNhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hpY2ggInN0dWZmIiBpbiA1NzM5 IHlvdSBhcmUgcmVmZXJyaW5nIHRvPyANCg0KVGhlIGRyYWZ0IHVwZGF0ZXMgUkZDNzI5NiBiZWNh dXNlIGl0IHVwZGF0ZXMgdGhlIGJlaGF2aW9yIHNwZWNpZmllZCBpbiBTZWN0aW9uIDMuMTUuNCBv ZiB0aGF0IFJGQy4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUt LS0tLQ0KPiBEZcKgOiBJUHNlYyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh IHBhcnQgZGUgWW9hdiBOaXINCj4gRW52b3nDqcKgOiBzYW1lZGkgMTMgb2N0b2JyZSAyMDE4IDE1 OjQ4DQo+IMOAwqA6IFRlcm8gS2l2aW5lbg0KPiBDY8KgOiBpcHNlY0BpZXRmLm9yZw0KPiBPYmpl dMKgOiBSZTogW0lQc2VjXSBDYWxsIGZvciBXRyBBZG9wdGF0aW9uIGZvciBkcmFmdC1ib3VjYWRh aXItaXBzZWNtZS1pcHY2LQ0KPiBpcHY0LWNvZGVzDQo+IA0KPiBJIGJlbGlldmUgdGhlIGZpbmFs IGRvY3VtZW50IHNob3VsZCBhZGRyZXNzIHRoZSBzdHVmZiBpbiBSRkMgNTczOS4gQWxzbywgSeKA mW0NCj4gbm90IHN1cmUgeW91IG5lZWQgdG8gdXBkYXRlIDcyOTYgdG8gYWRkIHNvbWUgbmV3IGNv ZGUgcG9pbnRzLg0KPiANCj4gTmVpdGhlciBvZiB0aGVzZSBpcyBhIGJhcnJpZXIgZm9yIGFkb3B0 aW9uLg0KPiANCj4gSSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBzdXBwb3J0IGl0cyBhZG9wdGlv bi4NCj4gDQo+IFlvYXYNCj4gDQo+ID4gT24gMTMgT2N0IDIwMTgsIGF0IDM6MDksIFRlcm8gS2l2 aW5lbiA8a2l2aW5lbkBpa2kuZmk+IHdyb3RlOg0KPiA+DQo+ID4gT3VyIG5ldyBjaGFydGVyIGhh cyBiZWVuIGFwcHJvdmVkIGFuZCB0aGF0IGluY2x1ZGVzIGl0ZW06DQo+ID4NCj4gPiAgICBSRkM3 Mjk2IGRlZmluZXMgYSBnZW5lcmljIG5vdGlmaWNhdGlvbiBjb2RlIHRoYXQgaXMgcmVsYXRlZCB0 byBhDQo+ID4gICAgZmFpbHVyZSB0byBoYW5kbGUgYW4gaW50ZXJuYWwgYWRkcmVzcyBmYWlsdXJl LiBUaGF0IGNvZGUgZG9lcyBub3QNCj4gPiAgICBleHBsaWNpdGx5IGFsbG93IGFuIGluaXRpYXRv ciB0byBkZXRlcm1pbmUgd2h5IGEgZ2l2ZW4gYWRkcmVzcw0KPiA+ICAgIGZhbWlseSBpcyBub3Qg YXNzaWduZWQsIG5vciB3aGV0aGVyIGl0IHNob3VsZCB0cnkgdXNpbmcgYW5vdGhlcg0KPiA+ICAg IGFkZHJlc3MgZmFtaWx5LiBUaGUgV29ya2luZyBHcm91cCB3aWxsIHNwZWNpZnkgYSBzZXQgb2Yg bW9yZQ0KPiA+ICAgIHNwZWNpZmljIG5vdGlmaWNhdGlvbiBjb2RlcyB0aGF0IHdpbGwgcHJvdmlk ZSBzdWZmaWNpZW50DQo+ID4gICAgaW5mb3JtYXRpb24gdG8gdGhlIElLRXYyIGluaXRpYXRvciBh Ym91dCB0aGUgZW5jb3VudGVyZWQgZmFpbHVyZS4NCj4gPiAgICBBIHBvc3NpYmxlIHN0YXJ0aW5n IHBvaW50aW5nIGlzDQo+ID4gICAgZHJhZnQtYm91Y2FkYWlyLWlwc2VjbWUtaXB2Ni1pcHY0LWNv ZGVzLg0KPiA+DQo+ID4gU28gdGhpcyBlbWFpbCB3aWxsIHN0YXJ0IG9uZSB3ZWVrIGxvbmcgV0cg YWRvcHRhdGlvbiBjYWxsIGZvciB0aGF0DQo+ID4gZG9jdW1lbnQgWzFdIGZvciBXRyBhZG9wdGF0 aW9uLg0KPiA+DQo+ID4gU2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgbGlzdCBiZWZvcmUgdGhl IDIwMTgtMTAtMjEuDQo+ID4NCj4gPiBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtYm91Y2FkYWlyLWlwc2VjbWUtaXB2Ni1pcHY0LQ0KPiBjb2Rlcy8NCj4gPiAtLQ0K PiA+IGtpdmluZW5AaWtpLmZpDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IElQc2VjIG1haWxpbmcgbGlzdA0KPiA+IElQc2VjQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g SVBzZWMgbWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From nobody Thu Oct 18 03:56:55 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 4550A12F1A6 for ; Thu, 18 Oct 2018 03:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 0dBi-2BHzBtw for ; Thu, 18 Oct 2018 03:56:50 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E318A12D4E9 for ; Thu, 18 Oct 2018 03:56:49 -0700 (PDT) Received: from DESKTOP58DFL8T (ObiWan2.nm.ifi.lmu.de [141.84.218.130]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id ED7E194AF79 for ; Thu, 18 Oct 2018 12:56:47 +0200 (CEST) From: "Tobias Guggemos" To: "IPsecME WG" Date: Thu, 18 Oct 2018 12:56:44 +0200 Keywords: GpgOL: Vertraute Absenderadresse MIME-Version: 1.0 Message-ID: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdRlbbE9N6OWrYbbQ/2iQK0xgl1pVQ== Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=NeZQh+pU6Ent/J=-=" Archived-At: Subject: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 10:56:54 -0000 This is a multipart message in MIME format. --=-=NeZQh+pU6Ent/J=-= Content-Type: multipart/alternative; boundary="=-=yaJ4liR8F9Kz+9=-=" --=-=yaJ4liR8F9Kz+9=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey all, =20 ESP Header Compression (EHC, [1]) defines a set of rules how to compress ES= P for specific scenarios, e.g. IoT and [2] describes how to negotiate this = rules with IKEv2. Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), whi= ch is necessary in order to prevent decompression failures in certain maybe= unforeseen situation (e.g. IP fragmentation, or the use UDP options). =20 With the new mode, the sender can decide to send certain packets =E2=80=9Cu= ncompressed=E2=80=9D if the receiver may not be able to decompress properly= . The sender notifies the receiver by using a different SA and thus a diffe= rent SPI. We believe this is more clean than defining something like a =E2=80=9Ccompr= essed=E2=80=9D bit in the ESP packet.=20 =20 That=E2=80=99s why we also thought about how to negotiate this new mode wit= h IKEv2. We believe that a clean way to negotiate this new mode is with a new Notify= Payload, namely =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D. The question is, do we need an explicit agreement of the COMPRESSED_MODE or= is the negotiation of using EHC [1] enough to figure out that the two peer= s have to use COMPRESSED_MODE anyways? =20 More specifically here are the following possibilities A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with USE_COM= PRESS_MODE the SA that compress payload (using EHC). The other SA *without*= USE_COMPRESS_ MODE will not proceed to compression. In other words, EHC is= activated if and only if USE_COMPRESS_MODE is active for the SA. B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes compre= ssion is requested and one without EHC in which case no compression is perf= ormed. =20 During the last IETF we had a brief discussion in the meeting which we woul= d like to bring to the list now. We=E2=80=99re looking forward to any opinions or suggestions. =20 Regards Tobias =20 [1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06=20 [2] https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension= -01 =20 =20 --=20 _ _ _ _ _ _ Tobias Guggemos M.Sc. |\/| |\ | |\/| Institut f=C3=BCr Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universit=C3=A4t M=C3= =BCnchen =3D=3D=3D=3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D Oettingenstr. = 67, 80538 Munich, Germany Room E 010, Phone +49-89-2180-9209=20 Munich Network Management Team Email: guggemos@nm.ifi.lmu.de =20 Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos=20 =20 --=-=yaJ4liR8F9Kz+9=-= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey all,

 

ESP= Header Compression (EHC, [1]) defines a set of rules how to compress ESP f= or specific scenarios, e.g. IoT and [2] describes how to negotiate this rul= es with IKEv2.

Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), wh= ich is necessary in order to prevent decompression failures in certain mayb= e unforeseen situation (e.g. IP fragmentation, or the use UDP options).

 =

With the new mode, the s= ender can decide to send certain packets “uncompressed” if the = receiver may not be able to decompress properly. The sender notifies the re= ceiver by using a different SA and thus a different SPI.<= /p>

We believe this is more clean th= an defining something like a “compressed” bit in the ESP packet= .

 =

That’s why w= e also thought about how to negotiate this new mode with IKEv2.<= /span>

We believe that a clean w= ay to negotiate this new mode is with a new Notify Payload, namely “U= SE_COMPRESSED_MODE”.

The question is, do we need an explicit agreement of the COMPR= ESSED_MODE or is the negotiation of using EHC [1] enough to figure out that= the two peers have to use COMPRESSED_MODE anyways?

 

More specifically here are the following po= ssibilities

A)= Negotiating 2 IPsec SAs with EHC parameters and specifying. with USE_COMPR= ESS_MODE the SA that compress payload (using EHC). The other SA *without= * USE_COMPRESS_ MODE will not proceed to compression. In other words, E= HC is activated if and only if USE_COMPRESS_MODE is active for the SA.=

B) Negotiation of = 2 IPsec SAs. One with EHC parameters which assumes compression is requested= and one without EHC in which case no compression is performed.<= /span>

 <= /p>

During the last IETF we had a br= ief discussion in the meeting which we would like to bring to the list now.=

We’re l= ooking forward to any opinions or suggestions.

 

Regards

Tobias

 

[1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 <= /o:p>

[2] htt= ps://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-01=

 

 

--

     =     _  _ _  _ _  _   &nbs= p;      Tobias Guggemos M.Sc.

  = ;       |\/| |\ | |\/|    = ;      Institut f=C3=BCr Informatik / Dept. of CS<= o:p>

         |  | | \| |&= nbsp; |          Ludwig-Maximi= lians-Universit=C3=A4t M=C3=BCnchen

     = =3D=3D=3D=3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D    &n= bsp;  Oettingenstr. 67, 80538 Munich, Germany

  &nb= sp;            =             &nb= sp;     Room E 010, Phone +49-89-2180-9209 <= /span>

Munich Network Management Team   Email: guggemos@nm.ifi.lmu.de 

Muenchner Netz-Ma= nagement Team   ht= tp://www.nm.ifi.lmu.de/~guggemos

 

--=-=yaJ4liR8F9Kz+9=-=-- --=-=NeZQh+pU6Ent/J=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlvIZtwACgkQyEcVbMgz VZ/I2Af+KgelWIDsW0h61Ef19p7uyWeGgy/cHapge1mMufp0YtnygEGpCdOAqyL2 9Jpr3guX51IgfFCW1vPuiFf6M/ekSDNC9hmVPK4xFN+Y6UyeGqXw7RsC6N3fCHeK hm3NN9gl6eQE79VgewZVxm/uQ5Dcpt3Xt+wn+qeCcU9sVBt/hU5V1aBXg57GHTHS BKMq8FgzTOA157PXMeJm1glS0EUTM1IUAeeJbb0WL5YOwD0WW0052GlNFp7ITwpD iGJ2SIskYrT7uapv6eY/97Hl8RNt/XrM6seLjrbSgLVWH9tI2d98UjWSHqGMQ4KR u6GktGGyKjbY4VQaJF/ryS+WrWvv9Q== =zv8/ -----END PGP SIGNATURE----- --=-=NeZQh+pU6Ent/J=-=-- From nobody Thu Oct 18 10:10:39 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 83B6112F1AC for ; Thu, 18 Oct 2018 10:10:37 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KSnWG6chUGcC for ; Thu, 18 Oct 2018 10:10:35 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 F0334128CE4 for ; Thu, 18 Oct 2018 10:10:34 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id 143-v6so1038130wmf.1 for ; Thu, 18 Oct 2018 10:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XA5UWPpXeaP4weXa3VlJWbZd66JuTcmXDk3eC9/0DcA=; b=RQIG3VF9d734LYUouJgAIROF4MyiA8E+QZyj+QIAojpAp7SAlgCxJbpYeTHMrjGzMd cGLUfytCqLrv4cYt+rjM4XHC+AllWxblW/IiTcimbx3HNALMQiC2lVGopKPT2POKcMFT M6BdQnnGRY8NhHySSKDvFyW53K1LjyOxNKiM9M7zrswIhZt0sUDySOj47BHh0ES6lRdh ZF661vjs+GrXTRvYdzGmAd4C6WADkVgevyn9as+W+xkXm15BaKTapqNU3mpwMFdW0SnZ oLnl0boDw5oS7mw+VkMVe8ykK2cAfE3gT8YSlY4jn+bNv/q66xDOw6qvT0n0QKtLlDC8 LOUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XA5UWPpXeaP4weXa3VlJWbZd66JuTcmXDk3eC9/0DcA=; b=C1AgAoU4KDDY4/zc5PGxXLZYffMIzEkVJY/hVsm87DQfutFGO3kwkJb+KAhr6JhpjG 3DoT480z/yIdZuRWOVWtS3RBW9FCzKSUcqzbrKkb5CBNSoMEoHpN3qwlEMc3rYr+ZIIf JFsjcmfKsn8nA2yAuXlPRQlPLqmT+czFmzzSqsV6TpQ2qW3UKL8AKuVhcRcit5Nyk9un 0vSSvZNaCpglSE51p5ClOvnwKwM4bMUJudRAIdSOOyQvsjr9s2pt9WPTZzvDZQwKT3wc RzanFIGQHqJ7HOPZ8u8oSCQC/GQ3dTbbX2S23f+TjtaGRx7OP1g9C1w+Mb3w8H3w1RFP /arg== X-Gm-Message-State: ABuFfogsM/nBu1SHorU56+QZKjp0t6/MrtCaJax9HMsTsHr0m3dWPWaO xP2Y9vPn0SEEub5SaoSo1Ws= X-Google-Smtp-Source: ACcGV60Db0NOFNTPmwXsOkM2EYecXDzI65nEt/9CMp+5TWQbS3eWKk66XXP6ELT6O9iL9specT1IjQ== X-Received: by 2002:a1c:8c46:: with SMTP id o67-v6mr1206858wmd.35.1539882633286; Thu, 18 Oct 2018 10:10:33 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 63-v6sm907789wmd.5.2018.10.18.10.10.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Oct 2018 10:10:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Yoav Nir In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E000C1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Thu, 18 Oct 2018 20:10:30 +0300 Cc: "ipsec@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5BF0C074-3611-47C4-9669-FC7464B4DECE@gmail.com> References: <787AE7BB302AE849A7480A190F8B93302E000C1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2018 17:10:38 -0000 Hi. RFC 7296 has the INTERNAL_ADDRESS_FAILURE notification as optional =E2=80=94= gateways are free to just ignore the requests. However, having read = 3.15.4 again, I see that the text does say =E2=80=9CIf the responder = encounters an error while attempting to assign an IP address to the = initiator during the processing of a Configuration payload, it responds = with an INTERNAL_ADDRESS_FAILURE notification.=E2=80=9D. So I=E2=80=99m = convinced. It does need to update 7296. About RFC 5739, at the top of page 3 (and other places) of your draft = you mention the initiator requesting IPv6 prefix(es). Requesting IPv6 = prefixes is defined in RFC 7539, which concludes that the way this is = defined in 3406 (the predecessor of 7296) doesn=E2=80=99t work. I think = 5739 should be referenced as informative. Yoav > On 18 Oct 2018, at 12:49, mohamed.boucadair@orange.com wrote: >=20 > Hi Yoav,=20 >=20 > Can you please clarify which "stuff" in 5739 you are referring to?=20 >=20 > The draft updates RFC7296 because it updates the behavior specified in = Section 3.15.4 of that RFC.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Yoav Nir >> Envoy=C3=A9 : samedi 13 octobre 2018 15:48 >> =C3=80 : Tero Kivinen >> Cc : ipsec@ietf.org >> Objet : Re: [IPsec] Call for WG Adoptation for = draft-boucadair-ipsecme-ipv6- >> ipv4-codes >>=20 >> I believe the final document should address the stuff in RFC 5739. = Also, I=E2=80=99m >> not sure you need to update 7296 to add some new code points. >>=20 >> Neither of these is a barrier for adoption. >>=20 >> I have read the draft and support its adoption. >>=20 >> Yoav >>=20 >>> On 13 Oct 2018, at 3:09, Tero Kivinen wrote: >>>=20 >>> Our new charter has been approved and that includes item: >>>=20 >>> RFC7296 defines a generic notification code that is related to a >>> failure to handle an internal address failure. That code does not >>> explicitly allow an initiator to determine why a given address >>> family is not assigned, nor whether it should try using another >>> address family. The Working Group will specify a set of more >>> specific notification codes that will provide sufficient >>> information to the IKEv2 initiator about the encountered failure. >>> A possible starting pointing is >>> draft-boucadair-ipsecme-ipv6-ipv4-codes. >>>=20 >>> So this email will start one week long WG adoptation call for that >>> document [1] for WG adoptation. >>>=20 >>> Send your comments to this list before the 2018-10-21. >>>=20 >>> [1] = https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4- >> codes/ >>> -- >>> kivinen@iki.fi >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 18 22:59: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 6612C12777C for ; Thu, 18 Oct 2018 22:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1Np5hWu_vb0T for ; Thu, 18 Oct 2018 22:59:20 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83A3A126CC7 for ; Thu, 18 Oct 2018 22:59:20 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 42bwGZ6fv9z5wHJ; Fri, 19 Oct 2018 07:59:18 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 42bwGZ5mfkz1xp5; Fri, 19 Oct 2018 07:59:18 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0415.000; Fri, 19 Oct 2018 07:59:18 +0200 From: To: Yoav Nir CC: "ipsec@ietf.org" Thread-Topic: Yoav's Comments (was RE: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) Thread-Index: AdRmx94SNANr8RJVTIm8SZkBT8u0mwALNc0AAB5bucA= Date: Fri, 19 Oct 2018 05:59:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E013693@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E000C1C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <5BF0C074-3611-47C4-9669-FC7464B4DECE@gmail.com> In-Reply-To: <5BF0C074-3611-47C4-9669-FC7464B4DECE@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Yoav's Comments (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 05:59:23 -0000 SGkgWW9hdiwgDQoNClRoYW5rIHlvdS4gDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpDaGVlcnMs DQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogWW9hdiBOaXIg W21haWx0bzp5bmlyLmlldGZAZ21haWwuY29tXQ0KPiBFbnZvecOpwqA6IGpldWRpIDE4IG9jdG9i cmUgMjAxOCAxOToxMQ0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xODQo+IENjwqA6 IGlwc2VjQGlldGYub3JnDQo+IE9iamV0wqA6IFJlOiBZb2F2J3MgQ29tbWVudHMgKHdhcyBSRTog W0lQc2VjXSBDYWxsIGZvciBXRyBBZG9wdGF0aW9uIGZvcg0KPiBkcmFmdC1ib3VjYWRhaXItaXBz ZWNtZS1pcHY2LWlwdjQtY29kZXMpDQo+IA0KPiBIaS4NCj4gDQo+IFJGQyA3Mjk2IGhhcyB0aGUg SU5URVJOQUxfQUREUkVTU19GQUlMVVJFIG5vdGlmaWNhdGlvbiBhcyBvcHRpb25hbCDigJQgZ2F0 ZXdheXMNCj4gYXJlIGZyZWUgdG8ganVzdCBpZ25vcmUgdGhlIHJlcXVlc3RzLiBIb3dldmVyLCBo YXZpbmcgcmVhZCAzLjE1LjQgYWdhaW4sIEkNCj4gc2VlIHRoYXQgdGhlIHRleHQgZG9lcyBzYXkg 4oCcSWYgdGhlIHJlc3BvbmRlciBlbmNvdW50ZXJzIGFuIGVycm9yIHdoaWxlDQo+IGF0dGVtcHRp bmcgdG8gYXNzaWduIGFuIElQIGFkZHJlc3MgdG8gdGhlIGluaXRpYXRvciBkdXJpbmcgdGhlIHBy b2Nlc3Npbmcgb2YNCj4gYSBDb25maWd1cmF0aW9uIHBheWxvYWQsIGl0IHJlc3BvbmRzIHdpdGgg YW4gSU5URVJOQUxfQUREUkVTU19GQUlMVVJFDQo+IG5vdGlmaWNhdGlvbi7igJ0uICBTbyBJ4oCZ bSBjb252aW5jZWQuIEl0IGRvZXMgbmVlZCB0byB1cGRhdGUgNzI5Ni4NCg0KW01lZF0gT0suDQoN Cj4gDQo+IEFib3V0IFJGQyA1NzM5LCBhdCB0aGUgdG9wIG9mIHBhZ2UgMyAoYW5kIG90aGVyIHBs YWNlcykgb2YgeW91ciBkcmFmdCB5b3UNCj4gbWVudGlvbiB0aGUgaW5pdGlhdG9yIHJlcXVlc3Rp bmcgSVB2NiBwcmVmaXgoZXMpLiBSZXF1ZXN0aW5nIElQdjYgcHJlZml4ZXMgaXMNCj4gZGVmaW5l ZCBpbiBSRkMgNzUzOSwgd2hpY2ggY29uY2x1ZGVzIHRoYXQgdGhlIHdheSB0aGlzIGlzIGRlZmlu ZWQgaW4gMzQwNg0KPiAodGhlIHByZWRlY2Vzc29yIG9mIDcyOTYpIGRvZXNu4oCZdCB3b3JrLiBJ IHRoaW5rIDU3Mzkgc2hvdWxkIGJlIHJlZmVyZW5jZWQgYXMNCj4gaW5mb3JtYXRpdmUuDQo+IA0K DQpbTWVkXSBSZXF1ZXN0aW5nIGFuIElQdjYgcHJlZml4IGlzIHBvc3NpYmxlIHdpdGggUkZDNzI5 Ni4gSXQgaXMgdHJ1ZSB0aGF0IGFuIGV4cGVyaW1lbnRhbCBSRkMgZGVmaW5lcyBhbm90aGVyIHdh eSB0byBwcm9jZWVkLCBidXQgUkZDNTczOSBpcyBhbHJlYWR5IGNpdGVkIGluIFJGQzcyOTYuIEFz IHN1Y2gsIHdlIGRvbuKAmXQgbmVlZCBJTU8gdG8gcmVwZWF0IGl0IGhlcmUgYmVjYXVzZSwgb3Ro ZXJ3aXNlLCB3ZSB3aWxsIG5lZWQgdG8gYWRkIGEgc2ltaWxhciBub3RlOg0KDQo9PQ0KICAgTm90 ZSB0aGF0IHRoZXJlIGlzIGFuIGFkZGl0aW9uYWwgZG9jdW1lbnQgdGhhdCBkaXNjdXNzZXMgSVB2 Ng0KICAgY29uZmlndXJhdGlvbiBpbiBJS0V2MiwgW0lQVjZDT05GSUddLiAgQXQgdGhlIHByZXNl bnQgdGltZSwgaXQgaXMgYW4NCiAgIGV4cGVyaW1lbnRhbCBkb2N1bWVudCwgYnV0IHRoZXJlIGlz IGEgaG9wZSB0aGF0IHdpdGggbW9yZQ0KICAgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSwgaXQg d2lsbCBnYWluIHRoZSBzYW1lIHN0YW5kYXJkcyB0cmVhdG1lbnQNCiAgIGFzIHRoaXMgZG9jdW1l bnQuDQo9PSANCg0KPiBZb2F2DQo+IA0KPiA+IE9uIDE4IE9jdCAyMDE4LCBhdCAxMjo0OSwgbW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gPg0KPiA+IEhpIFlvYXYsDQo+ID4N Cj4gPiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoaWNoICJzdHVmZiIgaW4gNTczOSB5b3UgYXJl IHJlZmVycmluZyB0bz8NCj4gPg0KPiA+IFRoZSBkcmFmdCB1cGRhdGVzIFJGQzcyOTYgYmVjYXVz ZSBpdCB1cGRhdGVzIHRoZSBiZWhhdmlvciBzcGVjaWZpZWQgaW4NCj4gU2VjdGlvbiAzLjE1LjQg b2YgdGhhdCBSRkMuDQo+ID4NCj4gPiBDaGVlcnMsDQo+ID4gTWVkDQo+ID4NCj4gPj4gLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4+IERlIDogSVBzZWMgW21haWx0bzppcHNlYy1ib3Vu Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFlvYXYgTmlyDQo+ID4+IEVudm95w6kgOiBzYW1l ZGkgMTMgb2N0b2JyZSAyMDE4IDE1OjQ4DQo+ID4+IMOAIDogVGVybyBLaXZpbmVuDQo+ID4+IENj IDogaXBzZWNAaWV0Zi5vcmcNCj4gPj4gT2JqZXQgOiBSZTogW0lQc2VjXSBDYWxsIGZvciBXRyBB ZG9wdGF0aW9uIGZvciBkcmFmdC1ib3VjYWRhaXItaXBzZWNtZS0NCj4gaXB2Ni0NCj4gPj4gaXB2 NC1jb2Rlcw0KPiA+Pg0KPiA+PiBJIGJlbGlldmUgdGhlIGZpbmFsIGRvY3VtZW50IHNob3VsZCBh ZGRyZXNzIHRoZSBzdHVmZiBpbiBSRkMgNTczOS4gQWxzbywNCj4gSeKAmW0NCj4gPj4gbm90IHN1 cmUgeW91IG5lZWQgdG8gdXBkYXRlIDcyOTYgdG8gYWRkIHNvbWUgbmV3IGNvZGUgcG9pbnRzLg0K PiA+Pg0KPiA+PiBOZWl0aGVyIG9mIHRoZXNlIGlzIGEgYmFycmllciBmb3IgYWRvcHRpb24uDQo+ ID4+DQo+ID4+IEkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgc3VwcG9ydCBpdHMgYWRvcHRpb24u DQo+ID4+DQo+ID4+IFlvYXYNCj4gPj4NCj4gPj4+IE9uIDEzIE9jdCAyMDE4LCBhdCAzOjA5LCBU ZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBPdXIgbmV3 IGNoYXJ0ZXIgaGFzIGJlZW4gYXBwcm92ZWQgYW5kIHRoYXQgaW5jbHVkZXMgaXRlbToNCj4gPj4+ DQo+ID4+PiAgIFJGQzcyOTYgZGVmaW5lcyBhIGdlbmVyaWMgbm90aWZpY2F0aW9uIGNvZGUgdGhh dCBpcyByZWxhdGVkIHRvIGENCj4gPj4+ICAgZmFpbHVyZSB0byBoYW5kbGUgYW4gaW50ZXJuYWwg YWRkcmVzcyBmYWlsdXJlLiBUaGF0IGNvZGUgZG9lcyBub3QNCj4gPj4+ICAgZXhwbGljaXRseSBh bGxvdyBhbiBpbml0aWF0b3IgdG8gZGV0ZXJtaW5lIHdoeSBhIGdpdmVuIGFkZHJlc3MNCj4gPj4+ ICAgZmFtaWx5IGlzIG5vdCBhc3NpZ25lZCwgbm9yIHdoZXRoZXIgaXQgc2hvdWxkIHRyeSB1c2lu ZyBhbm90aGVyDQo+ID4+PiAgIGFkZHJlc3MgZmFtaWx5LiBUaGUgV29ya2luZyBHcm91cCB3aWxs IHNwZWNpZnkgYSBzZXQgb2YgbW9yZQ0KPiA+Pj4gICBzcGVjaWZpYyBub3RpZmljYXRpb24gY29k ZXMgdGhhdCB3aWxsIHByb3ZpZGUgc3VmZmljaWVudA0KPiA+Pj4gICBpbmZvcm1hdGlvbiB0byB0 aGUgSUtFdjIgaW5pdGlhdG9yIGFib3V0IHRoZSBlbmNvdW50ZXJlZCBmYWlsdXJlLg0KPiA+Pj4g ICBBIHBvc3NpYmxlIHN0YXJ0aW5nIHBvaW50aW5nIGlzDQo+ID4+PiAgIGRyYWZ0LWJvdWNhZGFp ci1pcHNlY21lLWlwdjYtaXB2NC1jb2Rlcy4NCj4gPj4+DQo+ID4+PiBTbyB0aGlzIGVtYWlsIHdp bGwgc3RhcnQgb25lIHdlZWsgbG9uZyBXRyBhZG9wdGF0aW9uIGNhbGwgZm9yIHRoYXQNCj4gPj4+ IGRvY3VtZW50IFsxXSBmb3IgV0cgYWRvcHRhdGlvbi4NCj4gPj4+DQo+ID4+PiBTZW5kIHlvdXIg Y29tbWVudHMgdG8gdGhpcyBsaXN0IGJlZm9yZSB0aGUgMjAxOC0xMC0yMS4NCj4gPj4+DQo+ID4+ PiBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2FkYWlyLWlw c2VjbWUtaXB2Ni1pcHY0LQ0KPiA+PiBjb2Rlcy8NCj4gPj4+IC0tDQo+ID4+PiBraXZpbmVuQGlr aS5maQ0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+PiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPj4+IElQc2VjQGlldGYub3Jn DQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo+ID4+ DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+IElQc2VjIG1haWxpbmcgbGlzdA0KPiA+PiBJUHNlY0BpZXRmLm9yZw0KPiA+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg== From nobody Fri Oct 19 03:28:44 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 1A643130EC9 for ; Fri, 19 Oct 2018 03:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1ANOCjJ_TQo for ; Fri, 19 Oct 2018 03:28:41 -0700 (PDT) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 EA2A2130EBF for ; Fri, 19 Oct 2018 03:28:40 -0700 (PDT) Received: by mail-lf1-f44.google.com with SMTP id n26-v6so6167673lfl.1 for ; Fri, 19 Oct 2018 03:28:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Yh9RUlNMBKWwwAv2X62NzVdD3jntKJEhehj1AxRm6ik=; b=KkUan2pGhcl7UjR/Ncg4P2guqZuwlRsDJZsdEFX3T8iqlafUSjT6oYn4EFkiuTzSTr o6nsyg1rVpMovaQ8MsZKZCkoPnO0EglruYibJwlKSUt5YFRj+hnEji/IizgoxqNf7I+o b9sJsR6AonYht93eZ71YhBCp0AqaKM1s5U6PgWuIwxX3i6dak68FWHTsL2ppK5XVcvq2 JKAWz84hYSVyg/boahiB3xMxBoGPgW9eaEWiAia77Q3v04rwubczsIlzqFLokht9hqkH 7C5uCIIFVySMqHXvP3DQx8l90XhvWhUka1dyUhBGEzyddPznRr+OD5SJovJ+ICC4BI2C Kd6A== X-Gm-Message-State: ABuFfoiTJ1bRZMtrPBIyZZdI7blMdsWxRkKsfQnpzuNT9ShuQYML8jkd BdaptNsbVfnegdJ00xRDfJ85LTlUWI1Pzwxj2Zs= X-Google-Smtp-Source: ACcGV63CP+/hpSHfcT2eH8sWxCZeQcMVDCBJBKfRnHUXcxGS1YKvMIfr4oCX4aUeRz6MJLBttP7A3XEn6UxSNLT2/bA= X-Received: by 2002:a19:639b:: with SMTP id v27mr1795980lfi.95.1539944918856; Fri, 19 Oct 2018 03:28:38 -0700 (PDT) MIME-Version: 1.0 References: <23489.14255.823837.581954@fireball.acr.fi> <030f01d465e6$e850cd40$b8f267c0$@gmail.com> In-Reply-To: From: Daniel Migault Date: Fri, 19 Oct 2018 06:28:23 -0400 Message-ID: To: Tommy Pauly Cc: Valery Smyslov , IPsecME WG , Tero Kivinen Content-Type: multipart/alternative; boundary="000000000000dcbb780578925dbf" Archived-At: Subject: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 10:28:43 -0000 --000000000000dcbb780578925dbf Content-Type: text/plain; charset="UTF-8" +1, there seems a problem to solve, so I support the adoption. The question I would raise are: * Do we want to add code and update IKEv2 or do we want to define an extension with IP46_SUPPORTED. For interoperability, the latest may be preferred. * Looking at the code points, I have the impression that with the current signaling, only the case where a single af is supported could be ambiguous. A host sending a request for IP4 and IP6 addresses, can easily deduce is which are the supported AF, except when the a single AF is supported. In that case maybe the IP6 should be provided with the notification ,in case the host really wants a IP4 address. * While 3gpp use case is sufficient, I am wondering if we have use cases outside 3gpp where such extension is needed ? Of course these could be discussed after adoption. Yours, Daniel On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly wrote: > Agreed with Valery that this is a fine starting point to define the > problem, but we will need to iterate on the details. > > I do support adoption. > > Thanks, > Tommy > > > On Oct 16, 2018, at 11:59 PM, Valery Smyslov > wrote: > > > > Hi, > > > > after reading the draft's introduction, I think the problem described > > is real. So I support adoption of this draft. > > > > That said, it seems that the current draft solves the problem in > > suboptimal way (too many new notifications defined), but that > > can be definitely discussed in the WG. And yes, I'm ready to > > review the draft. > > > > Regards, > > Valery. > > > >> Our new charter has been approved and that includes item: > >> > >> RFC7296 defines a generic notification code that is related to a > >> failure to handle an internal address failure. That code does not > >> explicitly allow an initiator to determine why a given address > >> family is not assigned, nor whether it should try using another > >> address family. The Working Group will specify a set of more > >> specific notification codes that will provide sufficient > >> information to the IKEv2 initiator about the encountered failure. > >> A possible starting pointing is > >> draft-boucadair-ipsecme-ipv6-ipv4-codes. > >> > >> So this email will start one week long WG adoptation call for that > >> document [1] for WG adoptation. > >> > >> Send your comments to this list before the 2018-10-21. > >> > >> [1] > https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ > >> -- > >> kivinen@iki.fi > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000dcbb780578925dbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1, there seems a problem to solve, so I support the = adoption.

The question I would raise are:
* Do we want to add code and update IKEv2 or do we want to define an = extension with IP46_SUPPORTED. For interoperability, the latest may be pref= erred.
* Looking at the code points, I have the impression t= hat with the current signaling, only the case where a single af is supporte= d could be ambiguous. A host sending a request for IP4 and IP6 addresses, c= an easily deduce is which are the supported AF, except when the a single AF= is supported. In that case maybe the IP6 should be provided with the notif= ication ,in case the host really wants a IP4 address. =C2=A0
* While 3gpp use case is sufficient, I am wondering if we have use cases o= utside 3gpp where such extension is needed ?

Of co= urse these could be discussed after adoption.

You= rs,
Daniel

On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <tpauly@apple.com> wrote:
Agreed with Valery that this is a fine starting point t= o define the problem, but we will need to iterate on the details.

I do support adoption.

Thanks,
Tommy

> On Oct 16, 2018, at 11:59 PM, Valery Smyslov <smyslov.ietf@gmail.com> wrote= :
>
> Hi,
>
> after reading the draft's introduction, I think the problem descri= bed
> is real. So I support adoption of this draft.
>
> That said, it seems that the current draft solves the problem in
> suboptimal way (too many new notifications defined), but that
> can be definitely discussed in the WG. And yes, I'm ready to
> review the draft.
>
> Regards,
> Valery.
>
>> Our new charter has been approved and that includes item:
>>
>>=C2=A0 =C2=A0 RFC7296 defines a generic notification code that is r= elated to a
>>=C2=A0 =C2=A0 failure to handle an internal address failure. That c= ode does not
>>=C2=A0 =C2=A0 explicitly allow an initiator to determine why a give= n address
>>=C2=A0 =C2=A0 family is not assigned, nor whether it should try usi= ng another
>>=C2=A0 =C2=A0 address family. The Working Group will specify a set = of more
>>=C2=A0 =C2=A0 specific notification codes that will provide suffici= ent
>>=C2=A0 =C2=A0 information to the IKEv2 initiator about the encounte= red failure.
>>=C2=A0 =C2=A0 A possible starting pointing is
>>=C2=A0 =C2=A0 draft-boucadair-ipsecme-ipv6-ipv4-codes.
>>
>> So this email will start one week long WG adoptation call for that=
>> document [1] for WG adoptation.
>>
>> Send your comments to this list before the 2018-10-21.
>>
>> [1] https://datatr= acker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
>> --
>> kivinen@iki.fi=
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org=
>> https://www.ietf.org/mailman/listinfo/ipsec<= br> >
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000dcbb780578925dbf-- From nobody Fri Oct 19 05:48:36 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 7D65A129619 for ; Fri, 19 Oct 2018 05:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIwgTTBhlC4J for ; Fri, 19 Oct 2018 05:48:31 -0700 (PDT) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) (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 22FED126CB6 for ; Fri, 19 Oct 2018 05:48:31 -0700 (PDT) Received: by mail-lf1-f53.google.com with SMTP id x24-v6so9397143lfe.5 for ; Fri, 19 Oct 2018 05:48:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=plg1wFQCk5wfwUm4szPW7jeVLXTiSPExR60V40hyvyQ=; b=RgtWirXcDrCS6puDSgT6zIaT6+yC4e6XgDGQ++F5ej9dIqNEOFhX83SJ9k7ZDDNj0O nKajbZ1GQtVCN9nJrJT/XE0+PFJbiBOUG0vXl8cKZ4yNmQeLAflpkxlYO5NIA+FCERWz jao/KlzlDnBVhd0OTwzdOuTSOUbqzEs9YwH9BunHGudWB35MARhIvKJ1t/oFX/bQPf/R F11ZH0Fk9n6P9XM+CcTyCi8wis+FUVOQQw/olwv0+Ak5yyXkAJoGupnm8CrHVIbuUBId BxysqihgdaEhgDtqcyUvGCD8WAVmGrwDP8Yz3hmSfVkwNNap23rU2+ciIWgDJXTnjJvA 05nw== X-Gm-Message-State: ABuFfoi6Tc0+3c7mydt9X+GgPeXhBV4pvuvBzKgwo0IESBBjofxv53jL iRc//Gy1HVUhiJKp1AS3+cBY6oQV6WeLDqd+KLYgNGCf X-Google-Smtp-Source: ACcGV61Ux13zUQ8XwLTjjl8inI7cwY/KauS59PWTo8vT5/A9eT/vCetPM9lsR+oUQCvmZ9mcYTGKL2+0+jFsorzvT8U= X-Received: by 2002:a19:5513:: with SMTP id n19-v6mr2918539lfe.68.1539953309065; Fri, 19 Oct 2018 05:48:29 -0700 (PDT) MIME-Version: 1.0 References: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> In-Reply-To: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> From: Daniel Migault Date: Fri, 19 Oct 2018 08:48:16 -0400 Message-ID: To: guggemos@nm.ifi.lmu.de Cc: IPsecME WG Content-Type: multipart/alternative; boundary="000000000000f527cf05789451c5" Archived-At: Subject: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 12:48:34 -0000 --000000000000f527cf05789451c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Tobias for bringing this topic. I would rather go with option 2). As EHC is not guaranteed to work for every packets, when a SA using EHC is activated, the host may associate to that SA an alternate SA for traffic where EHC does not apply (SA*). In some case SA* will not be different from a standard SA and USE_COMPRESS could be seen as a way to indicate this is the alternate SA. If we want to specify that this is an alternate SA, maybe an explicit signalling such as a ALTERNATE_SA( SA_SPI ) notification may be considered. The drawbacks I see in using EHC parameters while not activating EHC is that it would prevent the Alternate SA to still benefit some compression. More specifically, the inner packet may not be compatible with the EHC defined in the initial SA. However, the Alternate SA may for example benefit from the compression of ESP parameters... Yours, Daniel On Thu, Oct 18, 2018 at 6:57 AM Tobias Guggemos wrote: > Hey all, > > > > ESP Header Compression (EHC, [1]) defines a set of rules how to compress > ESP for specific scenarios, e.g. IoT and [2] describes how to negotiate > this rules with IKEv2. > > Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), > which is necessary in order to prevent decompression failures in certain > maybe unforeseen situation (e.g. IP fragmentation, or the use UDP options= ). > > > > With the new mode, the sender can decide to send certain packets > =E2=80=9Cuncompressed=E2=80=9D if the receiver may not be able to decompr= ess properly. The > sender notifies the receiver by using a different SA and thus a different > SPI. > > We believe this is more clean than defining something like a =E2=80=9Ccom= pressed=E2=80=9D > bit in the ESP packet.. > > > > That=E2=80=99s why we also thought about how to negotiate this new mode w= ith IKEv2. > > We believe that a clean way to negotiate this new mode is with a new > Notify Payload, namely =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D. > > The question is, do we need an explicit agreement of the COMPRESSED_MODE > or is the negotiation of using EHC [1] enough to figure out that the two > peers have to use COMPRESSED_MODE anyways? > > > > More specifically here are the following possibilities > > A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with > USE_COMPRESS_MODE the SA that compress payload (using EHC). The other SA = * > *without** USE_COMPRESS_ MODE will not proceed to compression. In other > words, EHC is activated if and only if USE_COMPRESS_MODE is active for th= e > SA. > > B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes > compression is requested and one without EHC in which case no compression > is performed. > > > > During the last IETF we had a brief discussion in the meeting which we > would like to bring to the list now. > > We=E2=80=99re looking forward to any opinions or suggestions. > > > > Regards > > Tobias > > > > [1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 > > [2] > https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-0= 1 > > > > > > -- > > _ _ _ _ _ _ Tobias Guggemos M.Sc. > > |\/| |\ | |\/| Institut f=C3=BCr Informatik / Dept. of = CS > > | | | \| | | Ludwig-Maximilians-Universit=C3=A4t M=C3= =BCnchen > > =3D=3D=3D=3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D Oettingenstr= . 67, 80538 Munich, Germany > > Room E 010, Phone +49-89-2180-9209 > > Munich Network Management Team Email: guggemos@nm.ifi.lmu.de > > Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000f527cf05789451c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Tobias for bringing this topic. I would rather= go with option 2).

As EHC is not guaranteed = to work for every packets, when a SA using EHC is activated, the host may a= ssociate to that SA an alternate SA for traffic where EHC does not apply (S= A*). In some case SA* will not be different from a standard SA and USE_COMP= RESS could be seen as a way to indicate this is the alternate SA. If we wan= t to specify that this is an alternate SA, maybe an explicit signalling suc= h as a ALTERNATE_SA( SA_SPI ) notification may be considered.

The drawbacks I see in using EHC parameters while not acti= vating EHC is that it would prevent the Alternate SA to still benefit some = compression. More specifically, the inner packet may not be compatible with= the EHC=C2=A0 defined in the initial SA. However, the Alternate SA may for= example benefit from the compression of ESP parameters...

Yours,
Daniel=C2=A0

On Thu, Oct 18, 2018 at 6:57 AM Tobias Gu= ggemos <guggemos@nm.ifi.lmu.de= > wrote:

Hey all,

=C2=A0

ESP Header Compression= (EHC, [1]) defines a set of rules how to compress ESP for specific scenari= os, e.g. IoT and [2] describes how to negotiate this rules with IKEv2.

Due to some= suggestions we defined a new IPsec mode (COMPRESSION_MODE), which is neces= sary in order to prevent decompression failures in certain maybe unforeseen= situation (e.g. IP fragmentation, or the use UDP options).

=C2=A0

With the new mode, the= sender can decide to send certain packets =E2=80=9Cuncompressed=E2=80=9D i= f the receiver may not be able to decompress properly. The sender notifies = the receiver by using a different SA and thus a different SPI.

We believe this is = more clean than defining something like a =E2=80=9Ccompressed=E2=80=9D bit = in the ESP packet..

=C2=A0

That=E2=80=99s why we also thought about how to negotiate thi= s new mode with IKEv2.

We believe that a clean way to negotiate this new mode is w= ith a new Notify Payload, namely =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D.<= /u>

The questi= on is, do we need an explicit agreement of the COMPRESSED_MODE or is the ne= gotiation of using EHC [1] enough to figure out that the two peers have to = use COMPRESSED_MODE anyways?

=C2=A0

More specifically here are the following possibilitie= s

A) Ne= gotiating 2 IPsec SAs with EHC parameters and specifying. with USE_COMPRESS= _MODE the SA that compress payload (using EHC). The other SA *without* USE_COMPRESS_ MODE will not proceed to compression. In other words, EHC = is activated if and only if USE_COMPRESS_MODE is active for the SA.<= u>

B) Negotiation= of 2 IPsec SAs. One with EHC parameters which assumes compression is reque= sted and one without EHC in which case no compression is performed.<= u>

=C2=A0<= u>

During the las= t IETF we had a brief discussion in the meeting which we would like to brin= g to the list now.

We=E2=80=99re looking forward to any opinions or suggestions.

= =C2=A0

Regards=

Tobias=

=C2=A0

[1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 =

[2] https://tools.ietf.org/html/draft-mglt-ipsecme-= ikev2-diet-esp-extension-01

=C2=A0

<= /u>=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=C2=A0=C2=A0 Tobias Guggemos M.Sc.<= u>

=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 Institut f=C3= =BCr Informatik / Dept. of CS

=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 Ludwig-Maximilians-Universit=C3=A4t M=C3= =BCnchen

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D=3D=3D= =3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Oettingenstr. 67, 80538 Munich, Germany

=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=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Room E 010, Phone +49-89-2= 180-9209

Munich Network Management = Team=C2=A0=C2=A0 Email: guggemos@nm.ifi.lmu.de=C2=A0 <= /p>

Muenchner Netz-Management Team=C2=A0=C2=A0 http://www.nm.ifi.lmu.de/~guggemos =

=C2=A0

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000f527cf05789451c5-- From nobody Fri Oct 19 12:01:08 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 85161131105; Fri, 19 Oct 2018 11:56:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997539453.6592.15397887399477040895.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:34 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 103 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:43 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30 requested) Wednesday, 7 November 2018, Afternoon Session I 1350-1520 Room Name: Boromphimarn 4 size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: 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 Sat Oct 20 05:16: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 61C09130DC9 for ; Sat, 20 Oct 2018 05:16: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 MKEB2ouX3xG4 for ; Sat, 20 Oct 2018 05:16:04 -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 52F26126BED for ; Sat, 20 Oct 2018 05:16:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 42chZl21Zfz3J8; Sat, 20 Oct 2018 14:15:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1540037759; bh=/5NaQQLkdT6WSr3IX+AeQfhH/hd84SufDXE5liS4oTo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UI6VL4zI7gqvbTo74gCD0ViVES/fSESSjinPDJu3NnulHW1E/uF2OhJ3LnQIM/jHO Vx1uVy6MNijFx1xewXxLqarZrBc0vLRQXMtPY2gohgoi6fEQooJ+dG1lyUEGTP6Bxu 6ogF0sMUeuPmVtSUEpEmEC2dzK0SDWdqMJjefw28= 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 YOND-liEs54W; Sat, 20 Oct 2018 14:15:58 +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; Sat, 20 Oct 2018 14:15:58 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 592523A3134; Sat, 20 Oct 2018 08:15:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 592523A3134 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4FCC041C3B26; Sat, 20 Oct 2018 08:15:57 -0400 (EDT) Date: Sat, 20 Oct 2018 08:15:57 -0400 (EDT) From: Paul Wouters To: Tobias Guggemos cc: IPsecME WG In-Reply-To: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> Message-ID: References: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> 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] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 12:16:07 -0000 On Thu, 18 Oct 2018, Tobias Guggemos wrote: > With the new mode, the sender can decide to send certain packets “uncompressed” if the receiver may not be able to decompress properly. The sender notifies the > receiver by using a different SA and thus a different SPI. > > We believe this is more clean than defining something like a “compressed” bit in the ESP packet.. I really don't like either option. I was hoping we could get rid of IPCOMP, not make it even more complex with other different kinds of complicated compressions that take up more then a single IPsec SA. > More specifically here are the following possibilities > > A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with USE_COMPRESS_MODE the SA that compress payload (using EHC). The other SA *without* USE_COMPRESS_ > MODE will not proceed to compression. In other words, EHC is activated if and only if USE_COMPRESS_MODE is active for the SA. > > B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes compression is requested and one without EHC in which case no compression is performed. I'm not sure I like either. Tero, can be discuss this at the meeting? Paul From nobody Mon Oct 22 02:05: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 C79C9130DFB for ; Mon, 22 Oct 2018 02:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 8oIGOmPqkQCU for ; Mon, 22 Oct 2018 02:05: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 5B391130DF9 for ; Mon, 22 Oct 2018 02:05: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 w9M950t2010115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 22 Oct 2018 12:05:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w9M950JJ023001; Mon, 22 Oct 2018 12:05:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23501.37564.225914.802321@fireball.acr.fi> Date: Mon, 22 Oct 2018 12:05:00 +0300 From: Tero Kivinen To: ipsec@ietf.org 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: [IPsec] Finished: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 09:05:10 -0000 This call for adoptation has now finished, and we did got several people supporting adopting this document as WG base document. Several of those people also said that this is good baseline, but said we need to work on the actual solution bit more, i.e., how many notifies are needed and what is the relationship with this and RFC5739 etc. As such I will mark this WG Adoptation call as success, and we can discuss the changes for the draft in the Bangkok IETF meeting. -- kivinen@iki.fi From nobody Mon Oct 22 13:25:12 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 42DF112DD85; Mon, 22 Oct 2018 13:25:04 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154023990423.13510.1283890619889461320@ietfa.amsl.com> Date: Mon, 22 Oct 2018 13:25:04 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-split-dns-13.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:25:05 -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 : Split DNS Configuration for IKEv2 Authors : Tommy Pauly Paul Wouters Filename : draft-ietf-ipsecme-split-dns-13.txt Pages : 13 Date : 2018-10-22 Abstract: This document defines two Configuration Payload Attribute Types for the IKEv2 protocol that add support for private DNS domains. These domains are intended to be resolved using DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This approach of resolving a subset of domains using non- public DNS servers is referred to as "Split DNS". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-split-dns-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-split-dns-13 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 Mon Oct 22 13:27:28 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 A3985130DD7; Mon, 22 Oct 2018 13:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 vSHsggY9_pSV; Mon, 22 Oct 2018 13:26:47 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 7E4F5130E5A; Mon, 22 Oct 2018 13:26:44 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9MKLvMN020871; Mon, 22 Oct 2018 13:26:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=/y+LpnBgp2m6I27czdsC0hmWG5XONHc1QcqIm7i4oI0=; b=WtA9d4AKVm+tqsy0NTRBaUfcQxnx67Uy0FssaLWiBulxOQKYD76ZDHdc3ap0568fQVPD RyhEEbHnEUj+iEDCi81Yty804Zx2rqIZU/Mt023WpBXgFu7LoDZHRYKPJP5MmVJdZsce cAOcomZr86Pfw3xNfQDy0PPMJy38SqY1Wdc3gxr0GqtJLiDA7rBzDF3HMGZNEcJYJCpp q7ZAJq9alw36oYQPILoI68cZL79GqSWfcgbG8jKYj6y4IDu9uue88bnLAEbQyLmvW7LS TGHtkLh0s6SL3uSoTenrddnPykOiKSVQMfCulVdI4J6WErc8laupIFt3fHGRQ+97msPk ug== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2n83a43u9u-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Oct 2018 13:26:41 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_AIk2C9sUBqsG6G+zQUleIQ)" Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PH000AIUOSETRH0@ma1-mtap-s03.corp.apple.com>; Mon, 22 Oct 2018 13:26:39 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PH000C00OHJ1E00@nwk-mmpp-sz09.apple.com>; Mon, 22 Oct 2018 13:26:39 -0700 (PDT) X-Va-A: X-Va-T-CD: 1ea6b3df8a455fbf46f6c02bb174fde4 X-Va-E-CD: c2b8930c6ab4a651d1441d92483deb69 X-Va-R-CD: 941d76882d4051faa38891808138997d X-Va-CD: 0 X-Va-ID: 7308b217-d9f9-4b61-ba48-b82689b1651d X-V-A: X-V-T-CD: 4872e25be6e630dbcadfff6081c6c948 X-V-E-CD: c2b8930c6ab4a651d1441d92483deb69 X-V-R-CD: 941d76882d4051faa38891808138997d X-V-CD: 0 X-V-ID: e4434b18-5ebc-43be-bd7d-6b768baf64ce Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PH000700O86QM00@nwk-mmpp-sz09.apple.com>; Mon, 22 Oct 2018 13:26:38 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-22_11:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp14.corp.apple.com-10000_instance1 Received: from [17.234.8.234] (unknown [17.234.8.234]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PH000EV2OSDND50@nwk-mmpp-sz09.apple.com>; Mon, 22 Oct 2018 13:26:37 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Mon, 22 Oct 2018 13:26:36 -0700 In-reply-to: Cc: "ipsec@ietf.org" , "gen-art@ietf.org" , "draft-ietf-ipsecme-split-dns.all@ietf.org" , "ietf@ietf.org" To: Christer Holmberg References: <153448715569.12184.4843735916628840351@ietfa.amsl.com> <220503CD-69AA-4015-A954-DF48D071D522@apple.com> X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-22_11:, , signatures=0 Archived-At: Subject: Re: [IPsec] Genart last call review of draft-ietf-ipsecme-split-dns-12 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 20:26:59 -0000 --Boundary_(ID_AIk2C9sUBqsG6G+zQUleIQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Christer, Thanks again for the review. I've addressed all three comments below in = an update to the draft: https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13 = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-split-dns-13.txt Thanks, Tommy=20 > On Aug 19, 2018, at 1:39 PM, Christer Holmberg = wrote: >=20 > Hi Tommy, >=20 > Please see inline. >=20 >=20 > Minor issues: >=20 > Q1: >=20 >>> Section 3.1 contains some SHOULD-do statements, e.g.,: >>>=20 >>> "the initiator SHOULD also include one or more INTERNAL_IP4_DNS and >>> INTERNAL_IP6_DNS attributes in the CFG_REQUEST" >>>=20 >>> "the initiator SHOULD also include one or more INTERNAL_DNS_DOMAIN = attributes >>> in the CFG_REQUEST." >>>=20 >>> Is there a reason for not using MUST instead of SHOULD? >>=20 >> In general, the CFG_REQUEST attributes are a bit loose=E2=80=94they're = hints more than requirements. >>=20 >> =46rom section 3.15.1 of RFC7296: >>=20 >> The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request >> information from its peer. If an attribute in the CFG_REQUEST >> Configuration payload is not zero-length, it is taken as a = suggestion >> for that attribute. The CFG_REPLY Configuration payload MAY return >> that value, or a new one. It MAY also add new attributes and not >> include some requested ones. Unrecognized or unsupported attributes >> MUST be ignored in both requests and responses. >>=20 >> So, the CFG_REPLY MUST have a DNS server to go along with the DNS = domain, but I left the SHOULD in spirit=20 >> of the fact that the CFG_REQUEST is more of a suggestion. >>=20 >> That being said, if others in the WG would like to see this be a = MUST, I'm fine with that as well. I don't think we=20 >> should have the responder error out if it doesn't see both, however. >=20 > Well, if it is only a suggestion, then I guess my question is why use = something as strong as SHOULD :) SHOULD basically means = MUST-unless-you-have-a-good-reason to. >=20 > In general, is providing suggestions a SHOULD, or is it only for the = attributes above? >=20 > Anyway, if you want to have a SHOULD (or even a MUST) I won't object. = But, when I see a SHOULD, I always ask about the background :) >=20 >=20 > Q2: >=20 >>> Section 3.2 says: >>>=20 >>> "the initiator SHOULD behave as if Split DNS configurations are not = supported >>> by the server." >>>=20 >>> Again, is there a reason for not using MUST? >>=20 >> This one could be a MUST. The one exception I could see is if the = initiator was statically configured with some split DNS domains to use = as split domains >> In case the responder didn't provide any in the CFG_REPLY, it should = still use those and not send all DNS queries inside the tunnel. I = wouldn't want this >> MUST to disable the static configuration workarounds that = implementations have done prior to allowing split DNS to be negotiated. >=20 > Could you say: >=20 > "the initiator MUST behave as if a Split DNS configurations are not = supported, unless " >=20 >=20 >=20 > Nits/editorial comments: >=20 > Q3: >=20 >>> Is there a need for the "Background" section? Since the text is = related to what >>> is described in the "Introduction", could the the text be moved = there? >>=20 >> The main new points that the Background section adds on top of the = Introduction are: >> - The prior art for split DNS in IKEv1 >> - The fact that this is currently mainly seen in enterprise VPN = deployments >>=20 >> These points could indeed be moved to the introduction. I had felt = they fit better as "background" since they're=20 >> not essential to the description of the protocol, but give context = that is relevant now (and may be less so in the future). >=20 > The first sections of both the Introduction and the Background = sections talk about split DNS: >=20 > "Split DNS is a common configuration for secure tunnels, such as > Virtual Private Networks in which host machines private to an > organization can only be resolved using internal DNS resolvers" >=20 > "Split DNS is a common configuration for enterprise VPN deployments, > in which one or more private DNS domains are only accessible and > resolvable via an IPsec based VPN connection." >=20 > So, isn't Split DNS already covered by the Introduction? What extra = does the Background text bring? >=20 > The second paragraph of the Background could be placed at the end of = the Introduction, in my opinion. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_AIk2C9sUBqsG6G+zQUleIQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Christer,

Thanks = again for the review. I've addressed all three comments below in an = update to the draft:

https://tools.ietf.org/html/draft-ietf-ipsecme-split-dns-13=
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-split-= dns-13.txt

Thanks,
Tommy 
On Aug = 19, 2018, at 1:39 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Tommy,

Please see inline.


Minor issues:

Q1:

Section 3.1 contains = some SHOULD-do statements, e.g.,:

"the = initiator SHOULD also include one or more INTERNAL_IP4_DNS and
INTERNAL_IP6_DNS attributes in the CFG_REQUEST"

"the initiator SHOULD also include one or more = INTERNAL_DNS_DOMAIN attributes
in the CFG_REQUEST."

Is there a reason for not using MUST instead = of SHOULD?

In general, the = CFG_REQUEST attributes are a bit loose=E2=80=94they're hints more than = requirements.

=46rom section 3.15.1 of = RFC7296:

 The CFG_REQUEST and = CFG_REPLY pair allows an IKE endpoint to request
 information from its peer.  If an attribute in the = CFG_REQUEST
 Configuration payload is not = zero-length, it is taken as a suggestion
 for that = attribute.  The CFG_REPLY Configuration payload MAY return
 that value, or a new one.  It MAY also add new = attributes and not
 include some requested ones. =  Unrecognized or unsupported attributes
 MUST be = ignored in both requests and responses.

So, = the CFG_REPLY MUST have a DNS server to go along with the DNS domain, = but I left the SHOULD in spirit 
of the fact = that the CFG_REQUEST is more of a suggestion.

That being said, if others in the WG would like to see this = be a MUST, I'm fine with that as well. I don't think we 
should have = the responder error out if it doesn't see both, however.

Well, if it is only a suggestion, then I guess my question is = why use something as strong as SHOULD :) SHOULD basically means = MUST-unless-you-have-a-good-reason to.

In general, is providing suggestions a SHOULD, or is it only = for the attributes above?

Anyway, if you want to have a SHOULD (or even a MUST) I won't = object. But, when I see a SHOULD, I always ask about the background = :)


Q2:

Section 3.2 says:

"the initiator SHOULD behave as if Split DNS = configurations are not supported
by the server."

Again, is there a reason for not using = MUST?

This one could be a = MUST. The one exception I could see is if the initiator was statically = configured with some split DNS domains to use as split domains
In case the responder didn't provide any in the CFG_REPLY, it = should still use those and not send all DNS queries inside the tunnel. I = wouldn't want this
MUST to disable the static = configuration workarounds that implementations have done prior to = allowing split DNS to be negotiated.

Could you say:

"the initiator MUST behave as if = a Split DNS configurations are not supported, unless <insert text = above the statically configuration case above>"



Nits/editorial = comments:

Q3:

Is there a need for the = "Background" section? Since the text is related to what
is = described in the "Introduction", could the the text be moved there?

The main new points that the = Background section adds on top of the Introduction are:
- = The prior art for split DNS in IKEv1
- The fact that this = is currently mainly seen in enterprise VPN deployments

These points could indeed be moved to the introduction. I had = felt they fit better as "background" since they're 
not = essential to the description of the protocol, but give context that is = relevant now (and may be less so in the future).

The first sections of both the Introduction and the = Background sections talk about split DNS:

  "Split DNS is a common configuration for secure = tunnels, such as
  Virtual Private Networks in which host machines = private to an
  organization can only be resolved using internal = DNS resolvers"

  "Split DNS is a common configuration for = enterprise VPN deployments,
  in which one or more private DNS domains are only = accessible and
  resolvable via an IPsec based VPN = connection."

So, isn't = Split DNS already covered by the Introduction? What extra does the = Background text bring?

The second paragraph of the Background could be placed at the = end of the Introduction, in my opinion.

Regards,

Christer

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

= --Boundary_(ID_AIk2C9sUBqsG6G+zQUleIQ)-- From nobody Mon Oct 22 19:33: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 83353130E7E; Mon, 22 Oct 2018 19:33:22 -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.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154026200249.13921.4256770609682491037@ietfa.amsl.com> Date: Mon, 22 Oct 2018 19:33:22 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 02:33:23 -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 : IKEv2 Notification Codes for IPv4/IPv6 Coexistence Author : Mohamed Boucadair Filename : draft-ietf-ipsecme-ipv6-ipv4-codes-00.txt Pages : 6 Date : 2018-10-22 Abstract: This document specifies new IKEv2 notification codes to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ipv6-ipv4-codes-00 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 Mon Oct 22 23:15:08 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 380D8130DED for ; Mon, 22 Oct 2018 23:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 KrIH5eyTtnOK for ; Mon, 22 Oct 2018 23:15:01 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD7912F1AC for ; Mon, 22 Oct 2018 23:15:01 -0700 (PDT) Received: from DESKTOP58DFL8T (unknown [62.29.163.234]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 5621D94B5A8; Tue, 23 Oct 2018 08:14:59 +0200 (CEST) From: "Tobias Guggemos" To: "'Paul Wouters'" Cc: "IPsecME WG" References: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> In-Reply-To: Date: Tue, 23 Oct 2018 08:14:58 +0200 MIME-Version: 1.0 Message-ID: <001d01d46a97$b9f4a150$2ddde3f0$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdRlbbE9N6OWrYbbQ/2iQK0xgl1pVQC8DLyAAGrrAVA= Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=pLHXMvxVdaVBbh=-=" Archived-At: Subject: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 06:15:06 -0000 This is a multipart message in MIME format. --=-=pLHXMvxVdaVBbh=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Paul, thanks for sharing your thoughts.=20 The major issue behind is, what can we do if the sender recognizes somethin= g the receiver is not able to decompress. One example of such are UDP options, which could appear without being "agre= ed" on during the IKE exchange. https://tools.ietf.org/html/draft-ietf-tsvw= g-udp-options-05 The options basically use the UDP Length to indicate an UDP options trailer= , so if we would compress the length field, we would lose the information a= bout the size of the user data. What we propose is a "regular" SA, which can either be agreed during the in= itial exchange or simply upon necessity (e.g. when the first uncompressible= packet appears).=20 This allows us to use the SPI as an identifier for compressed and uncompres= sed packets.=20 Obviously, the "rude" option would be just to discard the outgoing packet a= s it mismatches the SA, but that seemed not to be a good way of handling it= (maybe there are other opinions on that?) In order to be efficient, EHC is meant to be used in settings where an SA i= s restricted to (in the best case) one specific connection (e.g. IP-address= + ports set to be unique on both sides), this is why I anyway assume that = there might be another SA for packets not fitting this particular use case = which can be used as a fallback. Any thoughts? Tobias > -----Urspr=C3=BCngliche Nachricht----- > Von: IPsec Im Auftrag von Paul Wouters > Gesendet: Samstag, 20. Oktober 2018 14:16 > An: Tobias Guggemos > Cc: IPsecME WG > Betreff: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header > Compression (EHC) >=20 > On Thu, 18 Oct 2018, Tobias Guggemos wrote: >=20 > > With the new mode, the sender can decide to send certain packets > > =E2=80=9Cuncompressed=E2=80=9D if the receiver may not be able to decom= press properly. The > sender notifies the receiver by using a different SA and thus a different= SPI. > > > > We believe this is more clean than defining something like a =E2=80=9Cc= ompressed=E2=80=9D > bit in the ESP packet.. >=20 > I really don't like either option. I was hoping we could get rid of IPCOM= P, not > make it even more complex with other different kinds of complicated > compressions that take up more then a single IPsec SA. >=20 > > More specifically here are the following possibilities > > > > A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with > > USE_COMPRESS_MODE the SA that compress payload (using EHC). The other > SA *without* USE_COMPRESS_ MODE will not proceed to compression. In > other words, EHC is activated if and only if USE_COMPRESS_MODE is active = for > the SA. > > > > B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes > compression is requested and one without EHC in which case no compression= is > performed. >=20 > I'm not sure I like either. >=20 > Tero, can be discuss this at the meeting? >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=-=pLHXMvxVdaVBbh=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlvOvF0ACgkQyEcVbMgz VZ+yVwf+MmQp3pTCu+cM2sWw/gvRnkV2gkwydk4IzddFHFp4oMMU5eBU+zWZhNfe TpmbfOPMzo/QlZ4cIeBdt3VFTOHJVzn2lMuePP3rjtlzmPDAOqMvstobvfAIyBZA 32LbgKcZ4DJqE1NDijbqnED1VgcSgimGTIQnxAJzP7toIT7gCmu17fM0R4cF6OPx o09xxM1Mb+poTdpfTniaJD06MrXY/PJodEd/A1fDDCeYjpBz1BsOFHXr/4OXxqIh y5bUy04yJF7lezsl0Djy3idpSqK3hF6wMAPk0zMNEIcUmsw2umyJyLkpBJOx5bsW T8vQtHPjC7rLlDvhTnGvTn/S0bskAA== =iBwN -----END PGP SIGNATURE----- --=-=pLHXMvxVdaVBbh=-=-- From nobody Wed Oct 24 05:59:38 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 725B1130ED4 for ; Wed, 24 Oct 2018 05:59:30 -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, UNPARSEABLE_RELAY=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 rJxozGYHaPGz for ; Wed, 24 Oct 2018 05:59:26 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ADF6130F2F for ; Wed, 24 Oct 2018 05:59:25 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 42g9Lz3Khmz8tR1; Wed, 24 Oct 2018 14:59:23 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.56]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 42g9Lz2cLVzCqkd; Wed, 24 Oct 2018 14:59:23 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM64.corporate.adroot.infra.ftgroup ([fe80::90ac:b7b7:7efe:9b11%21]) with mapi id 14.03.0415.000; Wed, 24 Oct 2018 14:59:22 +0200 From: To: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: Too many new notifications? (was RE: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes Thread-Index: AdRrmWJrcKxn+shrQMCnkidPjRkmww== Date: Wed, 24 Oct 2018 12:59:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E02D197@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [IPsec] Too many new notifications? (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 12:59:36 -0000 Hi Valery, all,=20 Thank you for raising this comment.=20 As a reminder, the current version of the draft defines 4 NEW codes. The ra= tionale is as follows:=20 (1) An initiator may request one address/prefix, but the request may be rej= ected because the requested address family is not supported. Returning UNSU= PPORTED_AF helps the initiator to deterministically know the failure cause.= An alternate AF, if supported, will be used for subsequent requests. =20 (2) An initiator may request addresses for both address families. If only o= ne of the requested address families is supported, an address/prefix and no= tification code is returned to inform the initiation why only one AF is inc= luded in the response. This code may be IP4_ONLY_SUPPORTED or IP6_ONLY_SUPP= ORTED. =20 (3) An initiator may request addresses for both address families but, for p= olicy reasons, only one address/prefix per request can be honored (even if = both AFs are supported). For this case, none of the previous codes is appro= priate. A new code is defined to cover this case: SINGLE_AF_SUPPORTED.=20 Can you please indicate which of these codes you think is not required? Tha= nk you. Cheers, Med =20 > -----Message d'origine----- > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Valery Smyslov > Envoy=E9=A0: mercredi 17 octobre 2018 08:59 > =C0=A0: 'Tero Kivinen'; ipsec@ietf.org > Objet=A0: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-= ipv6- > ipv4-codes >=20 > Hi, >=20 > after reading the draft's introduction, I think the problem described > is real. So I support adoption of this draft. >=20 > That said, it seems that the current draft solves the problem in > suboptimal way (too many new notifications defined), but that > can be definitely discussed in the WG. And yes, I'm ready to > review the draft. >=20 > Regards, > Valery. >=20 > > Our new charter has been approved and that includes item: > > > > RFC7296 defines a generic notification code that is related to a > > failure to handle an internal address failure. That code does not > > explicitly allow an initiator to determine why a given address > > family is not assigned, nor whether it should try using another > > address family. The Working Group will specify a set of more > > specific notification codes that will provide sufficient > > information to the IKEv2 initiator about the encountered failure. > > A possible starting pointing is > > draft-boucadair-ipsecme-ipv6-ipv4-codes. > > > > So this email will start one week long WG adoptation call for that > > document [1] for WG adoptation. > > > > Send your comments to this list before the 2018-10-21. > > > > [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4- > codes/ > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Oct 24 06:11:32 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 1494E124408 for ; Wed, 24 Oct 2018 06:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nVEkBODG9RD9 for ; Wed, 24 Oct 2018 06:11:28 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE6C128A6E for ; Wed, 24 Oct 2018 06:11:28 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 42g9ct22NYz4wG4; Wed, 24 Oct 2018 15:11:26 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.92]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 42g9ct1Grqz8sY5; Wed, 24 Oct 2018 15:11:26 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORMAC.corporate.adroot.infra.ftgroup ([fe80::f9fb:6cba:1c64:7737%21]) with mapi id 14.03.0415.000; Wed, 24 Oct 2018 15:11:25 +0200 From: To: Daniel Migault CC: IPsecME WG Thread-Topic: Daniel's comments (RE: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) Thread-Index: AdRrmxAwOAVS5QPhQ7mnp666uaXlDA== Date: Wed, 24 Oct 2018 13:11:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E02D1F2@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302E02D1F2OPEXCNORMADcorp_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] Daniel's comments (RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 13:11:31 -0000 --_000_787AE7BB302AE849A7480A190F8B93302E02D1F2OPEXCNORMADcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsLA0KDQpUaGFuayB5b3UgZm9yIHRoZSBjb21tZW50cy4NCg0KUGxlYXNlIHNlZSBp bmxpbmUuDQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IElQc2VjIFttYWlsdG86aXBzZWMtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBEYW5pZWwgTWlnYXVsdA0KRW52b3nDqSA6IHZlbmRy ZWRpIDE5IG9jdG9icmUgMjAxOCAxMjoyOA0Kw4AgOiBUb21teSBQYXVseQ0KQ2MgOiBJUHNlY01F IFdHOyBWYWxlcnkgU215c2xvdjsgVGVybyBLaXZpbmVuDQpPYmpldCA6IFJlOiBbSVBzZWNdIENh bGwgZm9yIFdHIEFkb3B0YXRpb24gZm9yIGRyYWZ0LWJvdWNhZGFpci1pcHNlY21lLWlwdjYtaXB2 NC1jb2Rlcw0KDQorMSwgdGhlcmUgc2VlbXMgYSBwcm9ibGVtIHRvIHNvbHZlLCBzbyBJIHN1cHBv cnQgdGhlIGFkb3B0aW9uLg0KDQpUaGUgcXVlc3Rpb24gSSB3b3VsZCByYWlzZSBhcmU6DQoqIERv IHdlIHdhbnQgdG8gYWRkIGNvZGUgYW5kIHVwZGF0ZSBJS0V2MiBvciBkbyB3ZSB3YW50IHRvIGRl ZmluZSBhbiBleHRlbnNpb24gd2l0aCBJUDQ2X1NVUFBPUlRFRC4gRm9yIGludGVyb3BlcmFiaWxp dHksIHRoZSBsYXRlc3QgbWF5IGJlIHByZWZlcnJlZC4NCg0KW01lZF0gV2hhdCB3b3VsZCBiZSB0 aGUgcHVycG9zZSBvZiBJUDQ2X1NVUFBPUlRFRD8NCg0KKiBMb29raW5nIGF0IHRoZSBjb2RlIHBv aW50cywgSSBoYXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgd2l0aCB0aGUgY3VycmVudCBzaWduYWxp bmcsIG9ubHkgdGhlIGNhc2Ugd2hlcmUgYSBzaW5nbGUgYWYgaXMgc3VwcG9ydGVkIGNvdWxkIGJl IGFtYmlndW91cy4gQSBob3N0IHNlbmRpbmcgYSByZXF1ZXN0IGZvciBJUDQgYW5kIElQNiBhZGRy ZXNzZXMsIGNhbiBlYXNpbHkgZGVkdWNlIGlzIHdoaWNoIGFyZSB0aGUgc3VwcG9ydGVkIEFGLCBl eGNlcHQgd2hlbiB0aGUgYSBzaW5nbGUgQUYgaXMgc3VwcG9ydGVkLg0KDQpbTWVkXSBUaGVyZSBh cmUgY2FzZXMgd2hlcmUgYm90aCBBRnMgYXJlIHN1cHBvcnRlZCwgYnV0IG9ubHkgYW4gYWRkcmVz cy9wcmVmaXggY2FuIGJlIHJldHVybmVkLiBXaGljaCBhZGRyZXNzIGlzIHJldHVybmVkIGlzIHBv bGljeS1iYXNlZC4gQW4gaW5pdGlhdG9yIHdoaWNoIGRvZXMgbm90IGdldCBhbiBhZGRyZXNzIGZh bWlseSB0eXBlIGRvZXMgbm90IGtub3cgd2hldGhlciBpdCBkaWRu4oCZdCBnZXQgdGhlIHJlcXVl c3RlZCBBRiBiZWNhdXNlICgxKSBpdCBpcyBub3Qgc3VwcG9ydGVkIG9yICgyKSBiZWNhdXNlIG9m IGEgcG9saWN5LiBUaGUgYmVoYXZpb3Igb2YgdGhlIGluaXRpYXRvciBtYXkgY2hhbmdlIGFzIGZ1 bmN0aW9uIG9mIHRoaXMuDQoNCkZvciBleGFtcGxlLCBpZiBpdCByZWFsbHkgbmVlZHMgYW4gSVB2 NCwgYnV0IGdldHMgYW4gSVB2NiBwcmVmaXgsIGl0IHdpbGwgbmVlZCB0byBpc3N1ZSBhIHJlcXVl c3QgaW4gd2hpY2ggb25seSBJTlRFUk5BTF9JUDRfQUREUkVTUyB3aWxsIGJlIGluY2x1ZGVkIGFu ZCBzbyBvbi4NCg0KSW4gdGhhdCBjYXNlIG1heWJlIHRoZSBJUDYgc2hvdWxkIGJlIHByb3ZpZGVk IHdpdGggdGhlIG5vdGlmaWNhdGlvbiAsaW4gY2FzZSB0aGUgaG9zdCByZWFsbHkgd2FudHMgYSBJ UDQgYWRkcmVzcy4NCg0KKiBXaGlsZSAzZ3BwIHVzZSBjYXNlIGlzIHN1ZmZpY2llbnQsIEkgYW0g d29uZGVyaW5nIGlmIHdlIGhhdmUgdXNlIGNhc2VzIG91dHNpZGUgM2dwcCB3aGVyZSBzdWNoIGV4 dGVuc2lvbiBpcyBuZWVkZWQgPw0KDQpbTWVkXSBJ4oCZbSBub3QgYXdhcmUgb2Ygb3RoZXIgdXNl IGNhc2VzIGJ1dCBJ4oCZbSBtb3JlIHRoYW4gaGFwcHkgdG8gY2l0ZSBvdGhlcnMgaWYgYW55Lg0K DQoNCk9mIGNvdXJzZSB0aGVzZSBjb3VsZCBiZSBkaXNjdXNzZWQgYWZ0ZXIgYWRvcHRpb24uDQoN CllvdXJzLA0KRGFuaWVsDQoNCk9uIFdlZCwgT2N0IDE3LCAyMDE4IGF0IDk6MjcgQU0gVG9tbXkg UGF1bHkgPHRwYXVseUBhcHBsZS5jb208bWFpbHRvOnRwYXVseUBhcHBsZS5jb20+PiB3cm90ZToN CkFncmVlZCB3aXRoIFZhbGVyeSB0aGF0IHRoaXMgaXMgYSBmaW5lIHN0YXJ0aW5nIHBvaW50IHRv IGRlZmluZSB0aGUgcHJvYmxlbSwgYnV0IHdlIHdpbGwgbmVlZCB0byBpdGVyYXRlIG9uIHRoZSBk ZXRhaWxzLg0KDQpJIGRvIHN1cHBvcnQgYWRvcHRpb24uDQoNClRoYW5rcywNClRvbW15DQoNCj4g T24gT2N0IDE2LCAyMDE4LCBhdCAxMTo1OSBQTSwgVmFsZXJ5IFNteXNsb3YgPHNteXNsb3YuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnNteXNsb3YuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4g SGksDQo+DQo+IGFmdGVyIHJlYWRpbmcgdGhlIGRyYWZ0J3MgaW50cm9kdWN0aW9uLCBJIHRoaW5r IHRoZSBwcm9ibGVtIGRlc2NyaWJlZA0KPiBpcyByZWFsLiBTbyBJIHN1cHBvcnQgYWRvcHRpb24g b2YgdGhpcyBkcmFmdC4NCj4NCj4gVGhhdCBzYWlkLCBpdCBzZWVtcyB0aGF0IHRoZSBjdXJyZW50 IGRyYWZ0IHNvbHZlcyB0aGUgcHJvYmxlbSBpbg0KPiBzdWJvcHRpbWFsIHdheSAodG9vIG1hbnkg bmV3IG5vdGlmaWNhdGlvbnMgZGVmaW5lZCksIGJ1dCB0aGF0DQo+IGNhbiBiZSBkZWZpbml0ZWx5 IGRpc2N1c3NlZCBpbiB0aGUgV0cuIEFuZCB5ZXMsIEknbSByZWFkeSB0bw0KPiByZXZpZXcgdGhl IGRyYWZ0Lg0KPg0KPiBSZWdhcmRzLA0KPiBWYWxlcnkuDQo+DQo+PiBPdXIgbmV3IGNoYXJ0ZXIg aGFzIGJlZW4gYXBwcm92ZWQgYW5kIHRoYXQgaW5jbHVkZXMgaXRlbToNCj4+DQo+PiAgICBSRkM3 Mjk2IGRlZmluZXMgYSBnZW5lcmljIG5vdGlmaWNhdGlvbiBjb2RlIHRoYXQgaXMgcmVsYXRlZCB0 byBhDQo+PiAgICBmYWlsdXJlIHRvIGhhbmRsZSBhbiBpbnRlcm5hbCBhZGRyZXNzIGZhaWx1cmUu IFRoYXQgY29kZSBkb2VzIG5vdA0KPj4gICAgZXhwbGljaXRseSBhbGxvdyBhbiBpbml0aWF0b3Ig dG8gZGV0ZXJtaW5lIHdoeSBhIGdpdmVuIGFkZHJlc3MNCj4+ICAgIGZhbWlseSBpcyBub3QgYXNz aWduZWQsIG5vciB3aGV0aGVyIGl0IHNob3VsZCB0cnkgdXNpbmcgYW5vdGhlcg0KPj4gICAgYWRk cmVzcyBmYW1pbHkuIFRoZSBXb3JraW5nIEdyb3VwIHdpbGwgc3BlY2lmeSBhIHNldCBvZiBtb3Jl DQo+PiAgICBzcGVjaWZpYyBub3RpZmljYXRpb24gY29kZXMgdGhhdCB3aWxsIHByb3ZpZGUgc3Vm ZmljaWVudA0KPj4gICAgaW5mb3JtYXRpb24gdG8gdGhlIElLRXYyIGluaXRpYXRvciBhYm91dCB0 aGUgZW5jb3VudGVyZWQgZmFpbHVyZS4NCj4+ICAgIEEgcG9zc2libGUgc3RhcnRpbmcgcG9pbnRp bmcgaXMNCj4+ICAgIGRyYWZ0LWJvdWNhZGFpci1pcHNlY21lLWlwdjYtaXB2NC1jb2Rlcy4NCj4+ DQo+PiBTbyB0aGlzIGVtYWlsIHdpbGwgc3RhcnQgb25lIHdlZWsgbG9uZyBXRyBhZG9wdGF0aW9u IGNhbGwgZm9yIHRoYXQNCj4+IGRvY3VtZW50IFsxXSBmb3IgV0cgYWRvcHRhdGlvbi4NCj4+DQo+ PiBTZW5kIHlvdXIgY29tbWVudHMgdG8gdGhpcyBsaXN0IGJlZm9yZSB0aGUgMjAxOC0xMC0yMS4N Cj4+DQo+PiBbMV0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm91Y2Fk YWlyLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzLw0KPj4gLS0NCj4+IGtpdmluZW5AaWtpLmZpPG1h aWx0bzpraXZpbmVuQGlraS5maT4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gSVBzZWMgbWFpbGluZyBsaXN0DQo+PiBJUHNlY0BpZXRm Lm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwc2VjDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZzxt YWlsdG86SVBzZWNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBzZWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmc8bWFpbHRvOklQc2VjQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K --_000_787AE7BB302AE849A7480A190F8B93302E02D1F2OPEXCNORMADcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6dGF4PSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv ZnQuY29tL3NoYXJlcG9pbnQvdGF4b25vbXkvc29hcC8iIHhtbG5zOnRucz0iaHR0cDovL3NjaGVt YXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvcmVjb3Jkc3JlcG9zaXRvcnkvIiB4bWxu czpzcHN1cD0iaHR0cDovL21pY3Jvc29mdC5jb20vd2Vic2VydmljZXMvU2hhcmVQb2ludFBvcnRh bFNlcnZlci9Vc2VyUHJvZmlsZVNlcnZpY2UiIHhtbG5zOm1tbD0iaHR0cDovL3d3dy53My5vcmcv MTk5OC9NYXRoL01hdGhNTCIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9y Zy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBl IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJh dG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQpzcGFu LlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2Fy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTD qSBIVE1MIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkZSO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBEYW5pZWwsJm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhhbmsgeW91IGZvciB0aGUg Y29tbWVudHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+UGxlYXNlIHNlZSBpbmxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TWVkPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSVBzZWMgW21haWx0bzppcHNl Yy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gRGFuaWVsIE1pZ2F1bHQ8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gdmVuZHJlZGkgMTkgb2N0b2JyZSAyMDE4IDEyOjI4 PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBUb21teSBQYXVseTxicj4NCjxiPkNjJm5ic3A7OjwvYj4g SVBzZWNNRSBXRzsgVmFsZXJ5IFNteXNsb3Y7IFRlcm8gS2l2aW5lbjxicj4NCjxiPk9iamV0Jm5i c3A7OjwvYj4gUmU6IFtJUHNlY10gQ2FsbCBmb3IgV0cgQWRvcHRhdGlvbiBmb3IgZHJhZnQtYm91 Y2FkYWlyLWlwc2VjbWUtaXB2Ni1pcHY0LWNvZGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEsIHRoZXJlIHNlZW1zIGEg cHJvYmxlbSB0byBzb2x2ZSwgc28gSSBzdXBwb3J0IHRoZSBhZG9wdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHF1ZXN0aW9uIEkg d291bGQgcmFpc2UgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiBEbyB3ZSB3YW50IHRvIGFkZCBjb2RlIGFuZCB1cGRhdGUgSUtFdjIgb3Ig ZG8gd2Ugd2FudCB0byBkZWZpbmUgYW4gZXh0ZW5zaW9uIHdpdGggSVA0Nl9TVVBQT1JURUQuIEZv ciBpbnRlcm9wZXJhYmlsaXR5LCB0aGUgbGF0ZXN0IG1heSBiZSBwcmVmZXJyZWQuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPltNZWRdIFdoYXQgd291bGQgYmUgdGhlIHB1cnBvc2Ug b2YgSVA0Nl9TVVBQT1JURUQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIExvb2tp bmcgYXQgdGhlIGNvZGUgcG9pbnRzLCBJIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCB3aXRoIHRo ZSBjdXJyZW50IHNpZ25hbGluZywgb25seSB0aGUgY2FzZSB3aGVyZSBhIHNpbmdsZSBhZiBpcyBz dXBwb3J0ZWQgY291bGQgYmUgYW1iaWd1b3VzLiBBIGhvc3Qgc2VuZGluZyBhIHJlcXVlc3QgZm9y IElQNCBhbmQgSVA2IGFkZHJlc3NlcywgY2FuIGVhc2lseSBkZWR1Y2UgaXMgd2hpY2ggYXJlIHRo ZQ0KIHN1cHBvcnRlZCBBRiwgZXhjZXB0IHdoZW4gdGhlIGEgc2luZ2xlIEFGIGlzIHN1cHBvcnRl ZC4gPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5bTWVkXSBUaGVyZSBhcmUgY2FzZXMgd2hlcmUgYm90 aCBBRnMgYXJlIHN1cHBvcnRlZCwgYnV0IG9ubHkgYW4gYWRkcmVzcy9wcmVmaXggY2FuIGJlIHJl dHVybmVkLiBXaGljaCBhZGRyZXNzIGlzIHJldHVybmVkIGlzIHBvbGljeS1iYXNlZC4gQW4gaW5p dGlhdG9yIHdoaWNoDQogZG9lcyBub3QgZ2V0IGFuIGFkZHJlc3MgZmFtaWx5IHR5cGUgZG9lcyBu b3Qga25vdyB3aGV0aGVyIGl0IGRpZG7igJl0IGdldCB0aGUgcmVxdWVzdGVkIEFGIGJlY2F1c2Ug KDEpIGl0IGlzIG5vdCBzdXBwb3J0ZWQgb3IgKDIpIGJlY2F1c2Ugb2YgYSBwb2xpY3kuIFRoZSBi ZWhhdmlvciBvZiB0aGUgaW5pdGlhdG9yIG1heSBjaGFuZ2UgYXMgZnVuY3Rpb24gb2YgdGhpcy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+Rm9yIGV4YW1wbGUsIGlmIGl0IHJlYWxseSBuZWVkcyBhbiBJUHY0LCBidXQg Z2V0cyBhbiBJUHY2IHByZWZpeCwgaXQgd2lsbCBuZWVkIHRvIGlzc3VlIGEgcmVxdWVzdCBpbiB3 aGljaCBvbmx5IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SU5URVJOQUxfSVA0X0FERFJFU1Mg d2lsbCBiZSBpbmNsdWRlZCBhbmQgc28gb24uIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkluIHRoYXQgY2FzZSBtYXliZSB0aGUgSVA2IHNob3VsZCBiZSBwcm92aWRlZCB3 aXRoIHRoZSBub3RpZmljYXRpb24gLGluIGNhc2UgdGhlIGhvc3QgcmVhbGx5IHdhbnRzIGEgSVA0 IGFkZHJlc3MuICZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+KiBXaGlsZSAzZ3BwIHVzZSBjYXNlIGlzIHN1ZmZpY2llbnQsIEkgYW0gd29u ZGVyaW5nIGlmIHdlIGhhdmUgdXNlIGNhc2VzIG91dHNpZGUgM2dwcCB3aGVyZSBzdWNoIGV4dGVu c2lvbiBpcyBuZWVkZWQgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5bTWVkXSBJ4oCZbSBub3QgYXdhcmUgb2Ygb3RoZXIgdXNlIGNhc2VzIGJ1dCBJ 4oCZbSBtb3JlIHRoYW4gaGFwcHkgdG8gY2l0ZSBvdGhlcnMgaWYgYW55LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9mIGNvdXJzZSB0 aGVzZSBjb3VsZCBiZSBkaXNjdXNzZWQgYWZ0ZXIgYWRvcHRpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdXJzLCA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhbmllbDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE9jdCAx NywgMjAxOCBhdCA5OjI3IEFNIFRvbW15IFBhdWx5ICZsdDs8YSBocmVmPSJtYWlsdG86dHBhdWx5 QGFwcGxlLmNvbSI+dHBhdWx5QGFwcGxlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkIHdpdGgg VmFsZXJ5IHRoYXQgdGhpcyBpcyBhIGZpbmUgc3RhcnRpbmcgcG9pbnQgdG8gZGVmaW5lIHRoZSBw cm9ibGVtLCBidXQgd2Ugd2lsbCBuZWVkIHRvIGl0ZXJhdGUgb24gdGhlIGRldGFpbHMuDQo8YnI+ DQo8YnI+DQpJIGRvIHN1cHBvcnQgYWRvcHRpb24uIDxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpU b21teSA8YnI+DQo8YnI+DQomZ3Q7IE9uIE9jdCAxNiwgMjAxOCwgYXQgMTE6NTkgUE0sIFZhbGVy eSBTbXlzbG92ICZsdDs8YSBocmVmPSJtYWlsdG86c215c2xvdi5pZXRmQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnNteXNsb3YuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7IDxicj4NCiZndDsgSGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGFmdGVyIHJlYWRpbmcgdGhl IGRyYWZ0J3MgaW50cm9kdWN0aW9uLCBJIHRoaW5rIHRoZSBwcm9ibGVtIGRlc2NyaWJlZDxicj4N CiZndDsgaXMgcmVhbC4gU28gSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoYXQgc2FpZCwgaXQgc2VlbXMgdGhhdCB0aGUgY3VycmVudCBkcmFm dCBzb2x2ZXMgdGhlIHByb2JsZW0gaW4gPGJyPg0KJmd0OyBzdWJvcHRpbWFsIHdheSAodG9vIG1h bnkgbmV3IG5vdGlmaWNhdGlvbnMgZGVmaW5lZCksIGJ1dCB0aGF0PGJyPg0KJmd0OyBjYW4gYmUg ZGVmaW5pdGVseSBkaXNjdXNzZWQgaW4gdGhlIFdHLiBBbmQgeWVzLCBJJ20gcmVhZHkgdG8gPGJy Pg0KJmd0OyByZXZpZXcgdGhlIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxi cj4NCiZndDsgVmFsZXJ5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgT3VyIG5ldyBjaGFydGVy IGhhcyBiZWVuIGFwcHJvdmVkIGFuZCB0aGF0IGluY2x1ZGVzIGl0ZW06PGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IFJGQzcyOTYgZGVmaW5lcyBhIGdlbmVyaWMgbm90 aWZpY2F0aW9uIGNvZGUgdGhhdCBpcyByZWxhdGVkIHRvIGE8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgZmFpbHVyZSB0byBoYW5kbGUgYW4gaW50ZXJuYWwgYWRkcmVzcyBmYWlsdXJlLiBUaGF0 IGNvZGUgZG9lcyBub3Q8YnI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgZXhwbGljaXRseSBhbGxv dyBhbiBpbml0aWF0b3IgdG8gZGV0ZXJtaW5lIHdoeSBhIGdpdmVuIGFkZHJlc3M8YnI+DQomZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgZmFtaWx5IGlzIG5vdCBhc3NpZ25lZCwgbm9yIHdoZXRoZXIgaXQg c2hvdWxkIHRyeSB1c2luZyBhbm90aGVyPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IGFkZHJl c3MgZmFtaWx5LiBUaGUgV29ya2luZyBHcm91cCB3aWxsIHNwZWNpZnkgYSBzZXQgb2YgbW9yZTxi cj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBzcGVjaWZpYyBub3RpZmljYXRpb24gY29kZXMgdGhh dCB3aWxsIHByb3ZpZGUgc3VmZmljaWVudDxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBpbmZv cm1hdGlvbiB0byB0aGUgSUtFdjIgaW5pdGlhdG9yIGFib3V0IHRoZSBlbmNvdW50ZXJlZCBmYWls dXJlLjxicj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBBIHBvc3NpYmxlIHN0YXJ0aW5nIHBvaW50 aW5nIGlzPGJyPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IGRyYWZ0LWJvdWNhZGFpci1pcHNlY21l LWlwdjYtaXB2NC1jb2Rlcy48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBTbyB0aGlzIGVt YWlsIHdpbGwgc3RhcnQgb25lIHdlZWsgbG9uZyBXRyBhZG9wdGF0aW9uIGNhbGwgZm9yIHRoYXQ8 YnI+DQomZ3Q7Jmd0OyBkb2N1bWVudCBbMV0gZm9yIFdHIGFkb3B0YXRpb24uPGJyPg0KJmd0OyZn dDsgPGJyPg0KJmd0OyZndDsgU2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoaXMgbGlzdCBiZWZvcmUg dGhlIDIwMTgtMTAtMjEuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgWzFdIDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1pcHNlY21l LWlwdjYtaXB2NC1jb2Rlcy8iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWJvdWNhZGFpci1pcHNlY21lLWlwdjYtaXB2NC1jb2Rlcy88L2E+ PGJyPg0KJmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86a2l2aW5lbkBp a2kuZmkiIHRhcmdldD0iX2JsYW5rIj5raXZpbmVuQGlraS5maTwvYT48YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCiZndDsmZ3Q7IElQc2VjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpJUHNlY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklQc2VjQGlldGYub3Jn PC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXBzZWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwc2VjPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgSVBzZWMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86SVBzZWNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5JUHNlY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjPC9hPjxicj4NCjxicj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSVBzZWMgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOklQc2VjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+SVBzZWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93302E02D1F2OPEXCNORMADcorp_-- From nobody Thu Oct 25 00:32:52 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 C72D6130E2A for ; Thu, 25 Oct 2018 00:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_NONE=-0.0001, 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 a0mbXNpzT7kq for ; Thu, 25 Oct 2018 00:32:48 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 18055130DDC for ; Thu, 25 Oct 2018 00:32:48 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id q6-v6so5241377lfh.9 for ; Thu, 25 Oct 2018 00:32:47 -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:content-language:thread-index; bh=JBmX/VYeGs+F4zhuztxAXwmh34ZhNQZFl6gBbj1vAx8=; b=eOsj9hEixL0qyjcKqNxJGwvTAYm2G+yYpXBH0cUmzqZcAmzUY7q66lat3Wqvdsmcyj cRj5zyr+yk/rGMBRFmQDIR4aCaxnWJ99Jx4rCy15d0JqBTDb+zrFWvuR1+ICPAWzwPgM FSFnthzaGvSS2Ma8uyOuRVXjYSnZRuH/ijT+4iybh6b1ALYTY6Ex2Fxj1R/jx5lGDJn+ 0hnGn9cLOtmOvBu/2p7nHQzAPP8tK5NoBSgcvnUdy6aNoLZjPqWFnAA+kfCgldPP9oio CYL3Cy9RAv3QSob9wOaDcOWW3qtqql3Ny2fojlsEjTYelBqHH3SrFfVtr0CL/oJcAySL sigQ== 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:content-language :thread-index; bh=JBmX/VYeGs+F4zhuztxAXwmh34ZhNQZFl6gBbj1vAx8=; b=KScnDX1cq+q+Bg0aX3ySgMNwtu8diM/WLHdHWkSiHkvH/gt1q8k1xk2MTfyfmA2f01 3/SlHlV/3yjJJkzyo2eT5KAVjwGOf1XSMhd7GP1CeU5xX+MSWBI9DZuIP9nzECOKKiNF VA8r27m3yop10vbW4Wn2eyzEg+oNTcKD1ZnNVxswhvkNmSbHGQIJgYdDhyoNz3ePIysv DvPNeFCMQhPZNkSzSQPEN7i0EsR7JJcoBWynHe6ceecSliLq8HGsyDZUEMhYJioL0Zja GLfYamCbnld1qDWOJsBylUT/2PyKHBMcOLVPE5u7vxyVKI7e6rKtSECHG2wU9dLXkOKQ pgdQ== X-Gm-Message-State: AGRZ1gL4Zy9LM8KZ6VQuRNX61m4fhXCPuw6gAtp5iYkOXY7FOi/BP0/m sNkYkGe5fBwVnEHiKQgzmRqHM19p X-Google-Smtp-Source: AJdET5dUeFLGO4teZ8cscJ0yrmsI1nlLp2pPAYdmv4/Cbt5xH7I493AjJOJtYbyiEu5NuzxzAlBiNQ== X-Received: by 2002:a19:c4cc:: with SMTP id u195mr358810lff.141.1540452765811; Thu, 25 Oct 2018 00:32:45 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d24-v6sm1092802lfj.64.2018.10.25.00.32.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Oct 2018 00:32:45 -0700 (PDT) From: "Valery Smyslov" To: , References: <787AE7BB302AE849A7480A190F8B93302E02D197@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E02D197@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Date: Thu, 25 Oct 2018 10:32:26 +0300 Message-ID: <031b01d46c34$e1635670$a42a0350$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQIZgrWlp44L4kbZAiVEIPjypkLXfKSlTcqQ Archived-At: Subject: Re: [IPsec] Too many new notifications? (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 07:32:50 -0000 Hi Med, > Hi Valery, all, >=20 > Thank you for raising this comment. >=20 > As a reminder, the current version of the draft defines 4 NEW codes. = The rationale is as follows: >=20 > (1) An initiator may request one address/prefix, but the request may = be rejected because the requested > address family is not supported. Returning UNSUPPORTED_AF helps the = initiator to deterministically know the > failure cause. An alternate AF, if supported, will be used for = subsequent requests. >=20 > (2) An initiator may request addresses for both address families. If = only one of the requested address families > is supported, an address/prefix and notification code is returned to = inform the initiation why only one AF is > included in the response. This code may be IP4_ONLY_SUPPORTED or = IP6_ONLY_SUPPORTED. >=20 > (3) An initiator may request addresses for both address families but, = for policy reasons, only one > address/prefix per request can be honored (even if both AFs are = supported). For this case, none of the > previous codes is appropriate. A new code is defined to cover this = case: SINGLE_AF_SUPPORTED. >=20 > Can you please indicate which of these codes you think is not = required? Thank you. Unless I missed something, I believe you can get all the needed = functionality with a single new notification SUPPORTED_AFS, with a data containing information which AFs are = supported (say a single octet per AF). In your first three use cases the assignment would not be done and the = responder would return this notification=20 with the data filled in accordingly.=20 The 4th use case is a bit trickier. When the initiator requested both = AFs, the responder would return IP of only one=20 (any of requested) AF assigned and again the notification SUPPORTED_AFS = indicating whic AFs are supported. The initiator could deduce that a second request is needed to get = address from the other AF.=20 Note also, that your notifications are error-type notifications. I'd = rather define status type notification (like SUPPORTED_AFS). The problem with error type notifications is that if the initiator = doesn't understand it (e.g. an old implementation), it will tear down IKE SA, because it assumes that the request has failed = entirely (Section 3.10.1 of RFC7296).=20 This will complicate the deployment of your extension. Regards, Valery. > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Valery = Smyslov > > Envoy=E9=A0: mercredi 17 octobre 2018 08:59 > > =C0=A0: 'Tero Kivinen'; ipsec@ietf.org > > Objet=A0: Re: [IPsec] Call for WG Adoptation for = draft-boucadair-ipsecme-ipv6- > > ipv4-codes > > > > Hi, > > > > after reading the draft's introduction, I think the problem = described > > is real. So I support adoption of this draft. > > > > That said, it seems that the current draft solves the problem in > > suboptimal way (too many new notifications defined), but that > > can be definitely discussed in the WG. And yes, I'm ready to > > review the draft. > > > > Regards, > > Valery. > > > > > Our new charter has been approved and that includes item: > > > > > > RFC7296 defines a generic notification code that is related to = a > > > failure to handle an internal address failure. That code does = not > > > explicitly allow an initiator to determine why a given address > > > family is not assigned, nor whether it should try using = another > > > address family. The Working Group will specify a set of more > > > specific notification codes that will provide sufficient > > > information to the IKEv2 initiator about the encountered = failure. > > > A possible starting pointing is > > > draft-boucadair-ipsecme-ipv6-ipv4-codes. > > > > > > So this email will start one week long WG adoptation call for that > > > document [1] for WG adoptation. > > > > > > Send your comments to this list before the 2018-10-21. > > > > > > [1] = https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4- > > codes/ > > > -- > > > kivinen@iki.fi > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 25 01:42:32 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 BA5F2130E03 for ; Thu, 25 Oct 2018 01:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 83W1roLahyPE for ; Thu, 25 Oct 2018 01:42:28 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 74F6D12F1AC for ; Thu, 25 Oct 2018 01:42:27 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id c16so6119468lfj.8 for ; Thu, 25 Oct 2018 01:42:27 -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-language:thread-index; bh=8cfxG/raHuDScc526WBhurYKlz3quoXBLUmwHXLQRVg=; b=QkNlQY9zWDbL+lscfYpOyjnfQfbCW+/nUqLS2mAxZTgIwMwAMm85KH7zmVq25vv20j 9dBx8QeeH8XXVTKedhR89804dq8Z3M4I93X+CwSxlARiGQRY+HywRbcsESv/ivzJkzWo QLaJglqB6zjk3wLqfXOvc44qBjnJIgRwZM97w6iRrCRX18fTSQaei5lRRufsNS2hhWww rn9Lowgl5lTkcIcbxbGigDb4JXXq7eNP4XHKYf2QOMwX3K3soGgRAriRU7rqr0OetXcQ dyOLr81ht5g24NuXzp/lRhY8JG1Qav/3wRGLH45+RdA22C+7CmqSFiNLmZbF2I8LbZk6 u02A== 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-language:thread-index; bh=8cfxG/raHuDScc526WBhurYKlz3quoXBLUmwHXLQRVg=; b=txbOUmJr4ggneH+cRiiQ8JdRJca2PXbHxZNiiHp4TvU+EiO8inYiBqR5yGLow8J6tb optH4EoxSOsr28R2MjE8rTSPRRc0/GjOxxM789jMbeuDY3jv5uwfPDxDd1LhXcQYHUyl hjxMAKG3gG1w1NdXx8lPLTH5DGtJ3NsrR8eUuoD3esate/1Elrdg48ywzoJM/qMJ+cHX E2jEFgZH+/pWWMOXpOYWwrTFHj4GUSOOh02fQsFRfizWTQ7vKPt3+Tl1JPseKy733Y9Q 05ugr08wSCy9xZAT6GjZ52Rmoj4miBev7kI64EUFkZhVBuDiHjFomQNGAebpjE65WG04 o8Rg== X-Gm-Message-State: AGRZ1gKQpnDuSw+JMJBivEX/rfnizwRulnhFBD+UWUJhlL/lvl9JptkW VJv1XvIDYQ2ZhaZcrm1ULkg= X-Google-Smtp-Source: AJdET5fNxZYkkj+7DcqWCWbUU0YacSRHf1dPYGDeO+ou5SAHPSv6esQvTarbKj3zvEr7E0p7UsXGDw== X-Received: by 2002:a19:4345:: with SMTP id m5mr536348lfj.142.1540456945544; Thu, 25 Oct 2018 01:42:25 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h21sm271831lfk.41.2018.10.25.01.42.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Oct 2018 01:42:24 -0700 (PDT) From: "Valery Smyslov" To: "'Tobias Guggemos'" , "'IPsecME WG'" References: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> In-Reply-To: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> Date: Thu, 25 Oct 2018 11:42:05 +0300 Message-ID: <033e01d46c3e$9c8bb240$d5a316c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_033F_01D46C57.C1E51F40" X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQG0d6gs8O2nQ5CYJbIrqTdYJsefRaVvioxg Archived-At: Subject: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 08:42:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_033F_01D46C57.C1E51F40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tobias, =20 unless I missed something, I think USE_COMPRESSED_MODE notify is = superfluous=20 and is not needed. As far as I understand, you negotiate EHC parameters = per IPsec SA basis, so if they are negotiated successfully, then compression is used for = this SA. If you need separate SA for the traffic that cannot be compressed, then = negotiate it separately without EHC_STRATEGY_SUPPORTED notification. You may = create as many IPsec SAs with the same Traffic Selectors as you like. Am I = missing something? =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tobias Guggemos Sent: Thursday, October 18, 2018 1:57 PM To: IPsecME WG Subject: [IPsec] Proposals for IPsec Compression Mode for ESP Header = Compression (EHC) =20 Hey all, =20 ESP Header Compression (EHC, [1]) defines a set of rules how to compress = ESP for specific scenarios, e.g. IoT and [2] describes how to negotiate = this rules with IKEv2. Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), = which is necessary in order to prevent decompression failures in certain = maybe unforeseen situation (e.g. IP fragmentation, or the use UDP = options). =20 With the new mode, the sender can decide to send certain packets = =E2=80=9Cuncompressed=E2=80=9D if the receiver may not be able to = decompress properly. The sender notifies the receiver by using a = different SA and thus a different SPI. We believe this is more clean than defining something like a = =E2=80=9Ccompressed=E2=80=9D bit in the ESP packet..=20 =20 That=E2=80=99s why we also thought about how to negotiate this new mode = with IKEv2. We believe that a clean way to negotiate this new mode is with a new = Notify Payload, namely =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D. The question is, do we need an explicit agreement of the COMPRESSED_MODE = or is the negotiation of using EHC [1] enough to figure out that the two = peers have to use COMPRESSED_MODE anyways? =20 More specifically here are the following possibilities A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with = USE_COMPRESS_MODE the SA that compress payload (using EHC). The other SA = *without* USE_COMPRESS_ MODE will not proceed to compression. In other = words, EHC is activated if and only if USE_COMPRESS_MODE is active for = the SA. B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes = compression is requested and one without EHC in which case no = compression is performed. =20 During the last IETF we had a brief discussion in the meeting which we = would like to bring to the list now. We=E2=80=99re looking forward to any opinions or suggestions. =20 Regards Tobias =20 [1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06=20 [2] = https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension-0= 1 =20 =20 --=20 _ _ _ _ _ _ Tobias Guggemos M.Sc. |\/| |\ | |\/| Institut f=C3=BCr Informatik / Dept. of = CS | | | \| | | Ludwig-Maximilians-Universit=C3=A4t = M=C3=BCnchen =3D=3D=3D=3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D = Oettingenstr. 67, 80538 Munich, Germany Room E 010, Phone +49-89-2180-9209=20 Munich Network Management Team Email: = guggemos@nm.ifi.lmu.de =20 Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos=20 =20 ------=_NextPart_000_033F_01D46C57.C1E51F40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi = Tobias,

 

unless I missed something, I = think USE_COMPRESSED_MODE notify is superfluous

and is not needed. As far as I = understand, you negotiate EHC parameters per IPsec SA = basis,

so if they are negotiated = successfully, then compression is used for this = SA.

If you need separate SA for the = traffic that cannot be compressed, then = negotiate

it separately without = EHC_STRATEGY_SUPPORTED notification. You may = create

as many IPsec SAs with the same = Traffic Selectors as you like. Am I missing = something?

 

Regards,

Valery.

 

From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of = Tobias Guggemos
Sent: Thursday, October 18, 2018 1:57 = PM
To: IPsecME WG
Subject: [IPsec] Proposals for = IPsec Compression Mode for ESP Header Compression = (EHC)

 

Hey all,

 

ESP Header Compression (EHC, [1]) defines a set of rules = how to compress ESP for specific scenarios, e.g. IoT and [2] describes = how to negotiate this rules with IKEv2.

Due to some suggestions we defined = a new IPsec mode (COMPRESSION_MODE), which is necessary in order to = prevent decompression failures in certain maybe unforeseen situation = (e.g. IP fragmentation, or the use UDP options).

 

With the new mode, the sender can = decide to send certain packets =E2=80=9Cuncompressed=E2=80=9D if the = receiver may not be able to decompress properly. The sender notifies the = receiver by using a different SA and thus a different = SPI.

We = believe this is more clean than defining something like a = =E2=80=9Ccompressed=E2=80=9D bit in the ESP packet.. =

 

That=E2=80=99s why we also thought about how to negotiate = this new mode with IKEv2.

We believe that a clean way to = negotiate this new mode is with a new Notify Payload, namely = =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D.

The question is, do we need an = explicit agreement of the COMPRESSED_MODE or is the negotiation of using = EHC [1] enough to figure out that the two peers have to use = COMPRESSED_MODE anyways?

 

More specifically here are the following = possibilities

A) Negotiating 2 IPsec SAs with EHC parameters and = specifying. with USE_COMPRESS_MODE the SA that compress payload (using = EHC). The other SA *without* USE_COMPRESS_ MODE will not proceed = to compression. In other words, EHC is activated if and only if = USE_COMPRESS_MODE is active for the SA.

B) Negotiation of 2 IPsec SAs. One = with EHC parameters which assumes compression is requested and one = without EHC in which case no compression is = performed.

 

During the last IETF we had a brief discussion in the = meeting which we would like to bring to the list = now.

We=E2=80=99re looking forward to any opinions or = suggestions.

 

Regards

Tobias

 

[1] https= ://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 =

[2] https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-= extension-01

 

 

--

         _  _ = _  _ _  = _          Tobias Guggemos = M.Sc.

         |\/| |\ | = |\/|          Institut = f=C3=BCr Informatik / Dept. of CS

         |  | | \| = |  |          = Ludwig-Maximilians-Universit=C3=A4t M=C3=BCnchen

      =3D=3D=3D=3D=3D=3D=3D TEAM = =3D=3D=3D=3D=3D=3D=3D       Oettingenstr. = 67, 80538 = Munich, Germany

           &= nbsp;           &n= bsp;         Room E 010, Phone = +49-89-2180-9209

Munich Network = Management Team   Email: guggemos@nm.ifi.lmu.de 

Muenchner Netz-Management Team   http://www.nm.ifi.lmu.de/~gug= gemos

 

------=_NextPart_000_033F_01D46C57.C1E51F40-- From nobody Thu Oct 25 05:58:08 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 1DB761271FF for ; Thu, 25 Oct 2018 05:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 E5FUL9Af72ee for ; Thu, 25 Oct 2018 05:58:04 -0700 (PDT) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4808130E66 for ; Thu, 25 Oct 2018 05:58:03 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 42gnGx5mQnz4xJB; Thu, 25 Oct 2018 14:58:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 42gnGx4pfMz1xpG; Thu, 25 Oct 2018 14:58:01 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0415.000; Thu, 25 Oct 2018 14:58:01 +0200 From: To: Valery Smyslov , "ipsec@ietf.org" Thread-Topic: Too many new notifications? (was RE: [IPsec] Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes Thread-Index: AdRrmWJrcKxn+shrQMCnkidPjRkmwwAirp4AAA48gKA= Date: Thu, 25 Oct 2018 12:58:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E037A45@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93302E02D197@OPEXCNORMAD.corporate.adroot.infra.ftgroup> <031b01d46c34$e1635670$a42a0350$@gmail.com> In-Reply-To: <031b01d46c34$e1635670$a42a0350$@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Too many new notifications? (was RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 12:58:07 -0000 Hi Valery,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Valery Smyslov [mailto:smyslov.ietf@gmail.com] > Envoy=E9=A0: jeudi 25 octobre 2018 09:32 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; ipsec@ietf.org > Objet=A0: RE: Too many new notifications? (was RE: [IPsec] Call for WG > Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes >=20 > Hi Med, >=20 > > Hi Valery, all, > > > > Thank you for raising this comment. > > > > As a reminder, the current version of the draft defines 4 NEW codes. Th= e > rationale is as follows: > > > > (1) An initiator may request one address/prefix, but the request may be > rejected because the requested > > address family is not supported. Returning UNSUPPORTED_AF helps the > initiator to deterministically know the > > failure cause. An alternate AF, if supported, will be used for subseque= nt > requests. > > > > (2) An initiator may request addresses for both address families. If on= ly > one of the requested address families > > is supported, an address/prefix and notification code is returned to in= form > the initiation why only one AF is > > included in the response. This code may be IP4_ONLY_SUPPORTED or > IP6_ONLY_SUPPORTED. > > > > (3) An initiator may request addresses for both address families but, f= or > policy reasons, only one > > address/prefix per request can be honored (even if both AFs are support= ed). > For this case, none of the > > previous codes is appropriate. A new code is defined to cover this case= : > SINGLE_AF_SUPPORTED. > > > > Can you please indicate which of these codes you think is not required? > Thank you. >=20 > Unless I missed something, I believe you can get all the needed functiona= lity > with a single new notification > SUPPORTED_AFS, with a data containing information which AFs are supported > (say a single octet per AF). > In your first three use cases the assignment would not be done and the > responder would return this notification > with the data filled in accordingly. >=20 [Med] Paul has already proposed this, see: https://mailarchive.ietf.org/arc= h/msg/ipsec/fFr6rKaK4MkICeA5MI9M4xpmxD0. The comment I made at that time is= : Given the available space (47-8191 or 16385-24575), assigning 4 codes is mu= ch more simple compared to assigning a type with sub-values. Isn't it? > The 4th use case is a bit trickier. When the initiator requested both AFs= , > the responder would return IP of only one > (any of requested) AF assigned and again the notification SUPPORTED_AFS > indicating whic AFs are supported. > The initiator could deduce that a second request is needed to get address > from the other AF. >=20 [Med] That would work if we go with sub-values. Given the available space, = is it really worth to go down to fields and sub-fields? > Note also, that your notifications are error-type notifications. I'd rath= er > define status type notification (like SUPPORTED_AFS). [Med] Good point. Will consider this. > The problem with error type notifications is that if the initiator doesn'= t > understand it (e.g. an old implementation), it will > tear down IKE SA, because it assumes that the request has failed entirely > (Section 3.10.1 of RFC7296). > This will complicate the deployment of your extension. [Med] Thank you.=20 >=20 > Regards, > Valery. >=20 > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: IPsec [mailto:ipsec-bounces@ietf.org] De la part de Valery Smy= slov > > > Envoy=E9=A0: mercredi 17 octobre 2018 08:59 > > > =C0=A0: 'Tero Kivinen'; ipsec@ietf.org > > > Objet=A0: Re: [IPsec] Call for WG Adoptation for draft-boucadair-ipse= cme- > ipv6- > > > ipv4-codes > > > > > > Hi, > > > > > > after reading the draft's introduction, I think the problem described > > > is real. So I support adoption of this draft. > > > > > > That said, it seems that the current draft solves the problem in > > > suboptimal way (too many new notifications defined), but that > > > can be definitely discussed in the WG. And yes, I'm ready to > > > review the draft. > > > > > > Regards, > > > Valery. > > > > > > > Our new charter has been approved and that includes item: > > > > > > > > RFC7296 defines a generic notification code that is related to = a > > > > failure to handle an internal address failure. That code does n= ot > > > > explicitly allow an initiator to determine why a given address > > > > family is not assigned, nor whether it should try using another > > > > address family. The Working Group will specify a set of more > > > > specific notification codes that will provide sufficient > > > > information to the IKEv2 initiator about the encountered failur= e. > > > > A possible starting pointing is > > > > draft-boucadair-ipsecme-ipv6-ipv4-codes. > > > > > > > > So this email will start one week long WG adoptation call for that > > > > document [1] for WG adoptation. > > > > > > > > Send your comments to this list before the 2018-10-21. > > > > > > > > [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-i= pv4- > > > codes/ > > > > -- > > > > kivinen@iki.fi > > > > > > > > _______________________________________________ > > > > IPsec mailing list > > > > IPsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Oct 25 08:39: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 9D794130E76 for ; Thu, 25 Oct 2018 08:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAFwTP2MWoBi for ; Thu, 25 Oct 2018 08:39:20 -0700 (PDT) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (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 C13B2130DD3 for ; Thu, 25 Oct 2018 08:39:19 -0700 (PDT) Received: by mail-lf1-f52.google.com with SMTP id h192so2214635lfg.3 for ; Thu, 25 Oct 2018 08:39:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5QVEuSUeG2rC1qBdvxr3vZ7HjsSAuMYXCxc//eNArDs=; b=Xw0Wuu58HGplZX5IL0ZLWL4YjePrBnDqwpKyqFV5AiyctpeYgiijK+CvGMMKsQASGh kXgwTR2KyG8mq+OsvjPgcoozXzY6xs32y544ucCPF+u95KPZiytID1DcY0xhud6scJsb BF0FcTe0pY9Z16xkpt5ZjKQCLfL6m3AdncK1OZt8mWfJejWeC+uYZKD6jgTmvbihH74X PzfWIORMTMK+KEnopinOJZrzgsoEdDPeEh6O41VhlNx2FA5J4RiE+/QBZ4E7ytxYYF5E Hm2tKwGbQumw4Tq8V6ljJ2FbZ2FMwZeUbpqNQs7eMFDJN0BSiXzJ0n3T0LNs7WlRXpgO N0FQ== X-Gm-Message-State: AGRZ1gJY8OphX6aen6n3yUFfHsyRpD8qiESnezH8X5V5CV0cAHbLqZmG 7b4u9HSb5uKnHyaiXC0ETmZtijSmwCxd1tLppS0= X-Google-Smtp-Source: AJdET5cFr3hiEhH3RIdGkEenfRn1dlhdGjxZuFBjoiEEO4eScwT3IEyBSVI/VvGIrIU8YkJt19SwHBOwmFgQiTSKhmk= X-Received: by 2002:a19:639b:: with SMTP id v27mr1467518lfi.95.1540481957644; Thu, 25 Oct 2018 08:39:17 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302E02D1F2@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E02D1F2@OPEXCNORMAD.corporate.adroot.infra.ftgroup> From: Daniel Migault Date: Thu, 25 Oct 2018 11:39:06 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: IPsecME WG Content-Type: multipart/alternative; boundary="000000000000de505405790f676a" Archived-At: Subject: Re: [IPsec] Daniel's comments (RE: Call for WG Adoptation for draft-boucadair-ipsecme-ipv6-ipv4-codes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:39:22 -0000 --000000000000de505405790f676a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your response, please see my response. Yours, Daniel On Wed, Oct 24, 2018 at 9:11 AM wrote: > Hi Daniel, > > > > Thank you for the comments. > > > > Please see inline. > > > > Cheers, > > Med > > > > *De :* IPsec [mailto:ipsec-bounces@ietf.org] *De la part de* Daniel > Migault > *Envoy=C3=A9 :* vendredi 19 octobre 2018 12:28 > *=C3=80 :* Tommy Pauly > *Cc :* IPsecME WG; Valery Smyslov; Tero Kivinen > *Objet :* Re: [IPsec] Call for WG Adoptation for > draft-boucadair-ipsecme-ipv6-ipv4-codes > > > > +1, there seems a problem to solve, so I support the adoption. > > > > The question I would raise are: > > * Do we want to add code and update IKEv2 or do we want to define an > extension with IP46_SUPPORTED. For interoperability, the latest may be > preferred. > > > > [Med] What would be the purpose of IP46_SUPPORTED? > > > The notification of the support of the code points. These woudl be exchanged in the IKE_AUTH Similar as N(MOBIKE_SUPPORTED). * Looking at the code points, I have the impression that with the current > signaling, only the case where a single af is supported could be ambiguou= s. > A host sending a request for IP4 and IP6 addresses, can easily deduce is > which are the supported AF, except when the a single AF is supported. > > > > [Med] There are cases where both AFs are supported, but only an > address/prefix can be returned. Which address is returned is policy-based= . > An initiator which does not get an address family type does not know > whether it didn=E2=80=99t get the requested AF because (1) it is not supp= orted or > (2) because of a policy. The behavior of the initiator may change as > function of this. > > For example, if it really needs an IPv4, but gets an IPv6 prefix, it will= need to issue a request in which only > > INTERNAL_IP4_ADDRESS will be included and so on. > > ok so policy based means that we can expect everything, and we are not able to define that policy in you draft. In other words we really need all these code points > > > In that case maybe the IP6 should be provided with the notification ,in > case the host really wants a IP4 address. > > > > * While 3gpp use case is sufficient, I am wondering if we have use cases > outside 3gpp where such extension is needed ? > > > > [Med] I=E2=80=99m not aware of other use cases but I=E2=80=99m more than = happy to cite > others if any. > > That was a question, I am not aware of other use cases. > > > Of course these could be discussed after adoption. > > > > Yours, > > Daniel > > > > On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly wrote: > > Agreed with Valery that this is a fine starting point to define the > problem, but we will need to iterate on the details. > > I do support adoption. > > Thanks, > Tommy > > > On Oct 16, 2018, at 11:59 PM, Valery Smyslov > wrote: > > > > Hi, > > > > after reading the draft's introduction, I think the problem described > > is real. So I support adoption of this draft. > > > > That said, it seems that the current draft solves the problem in > > suboptimal way (too many new notifications defined), but that > > can be definitely discussed in the WG. And yes, I'm ready to > > review the draft. > > > > Regards, > > Valery. > > > >> Our new charter has been approved and that includes item: > >> > >> RFC7296 defines a generic notification code that is related to a > >> failure to handle an internal address failure. That code does not > >> explicitly allow an initiator to determine why a given address > >> family is not assigned, nor whether it should try using another > >> address family. The Working Group will specify a set of more > >> specific notification codes that will provide sufficient > >> information to the IKEv2 initiator about the encountered failure. > >> A possible starting pointing is > >> draft-boucadair-ipsecme-ipv6-ipv4-codes. > >> > >> So this email will start one week long WG adoptation call for that > >> document [1] for WG adoptation. > >> > >> Send your comments to this list before the 2018-10-21. > >> > >> [1] > https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/ > >> -- > >> kivinen@iki.fi > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000000000000de505405790f676a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for your response, please see my response.
Yours,
Daniel

On Wed, Oct 24, 2018 at 9:11 AM <mohamed.boucadair@orange.com> w= rote:

Hi Daniel,=C2=A0

=C2=A0

Thank you for the comments.

=C2=A0

Please see inline.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: IPse= c [mailto:ipsec= -bounces@ietf.org] De la part de Daniel Migault
Envoy=C3=A9=C2=A0: vendredi 19 octobre 2018 12:28
=C3=80=C2=A0: Tommy Pauly
Cc=C2=A0: IPsecME WG; Valery Smyslov; Tero Kivinen
Objet=C2=A0: Re: [IPsec] Call for WG Adoptation for draft-boucadair-= ipsecme-ipv6-ipv4-codes

=C2=A0

+1, there seems a problem to solve, so I support the= adoption.

=C2=A0

The question I would raise are:

* Do we want to add code and update IKEv2 or do we w= ant to define an extension with IP46_SUPPORTED. For interoperability, the l= atest may be preferred.

=C2=A0

[Med] What would be the purpose= of IP46_SUPPORTED?

=C2=A0

<= /div>
<mglt>The notification of th= e support of the code points. These woudl be exchanged in the IKE_AUTH Simi= lar as=C2=A0 N(MOBIKE_SUPPORTED). </mglt>

* Looking at the code points, I have the impression = that with the current signaling, only the case where a single af is support= ed could be ambiguous. A host sending a request for IP4 and IP6 addresses, = can easily deduce is which are the supported AF, except when the a single AF is supported.

=C2=A0

[Med] There are cases where bot= h AFs are supported, but only an address/prefix can be returned. Which addr= ess is returned is policy-based. An initiator which does not get an address family type does not know whether it didn=E2=80=99= t get the requested AF because (1) it is not supported or (2) because of a = policy. The behavior of the initiator may change as function of this. 

For example, if it really n=
eeds an IPv4, but gets an IPv6 prefix, it will need to issue a request in w=
hich only =C2=A0
= 
INTERNAL_IP4_ADDRESS will be i=
ncluded and so on. =C2=A0=
=C2=A0
<mglt= >ok so policy based means that we can expect everything, and we are not = able to define that policy in you draft. In other words we really need all = these code points</mglt>

=C2=A0

In that case maybe the IP6 shou= ld be provided with the notification ,in case the host really wants a IP4 a= ddress. =C2=A0

=C2=A0

* While 3gpp use case is suffic= ient, I am wondering if we have use cases outside 3gpp where such extension= is needed ?

=C2=A0

[Med] I=E2=80=99m not aware of = other use cases but I=E2=80=99m more than happy to cite others if any.

<= /div>
<mglt>That was a question, I am no= t aware of other use cases.</mglt>

=C2=A0

Of course these could be discussed after adoption.

=C2=A0

Yours,

Daniel

=C2=A0

On Wed, Oct 17, 2018 at 9:27 AM Tommy Pauly <tpauly@apple.com> = wrote:

Agreed with Valery that this is a fine starting poin= t to define the problem, but we will need to iterate on the details.

I do support adoption.

Thanks,
Tommy

> On Oct 16, 2018, at 11:59 PM, Valery Smyslov <smyslov.ietf@gmail.com> wrote= :
>
> Hi,
>
> after reading the draft's introduction, I think the problem descri= bed
> is real. So I support adoption of this draft.
>
> That said, it seems that the current draft solves the problem in
> suboptimal way (too many new notifications defined), but that
> can be definitely discussed in the WG. And yes, I'm ready to
> review the draft.
>
> Regards,
> Valery.
>
>> Our new charter has been approved and that includes item:
>>
>>=C2=A0 =C2=A0 RFC7296 defines a generic notification code that is r= elated to a
>>=C2=A0 =C2=A0 failure to handle an internal address failure. That c= ode does not
>>=C2=A0 =C2=A0 explicitly allow an initiator to determine why a give= n address
>>=C2=A0 =C2=A0 family is not assigned, nor whether it should try usi= ng another
>>=C2=A0 =C2=A0 address family. The Working Group will specify a set = of more
>>=C2=A0 =C2=A0 specific notification codes that will provide suffici= ent
>>=C2=A0 =C2=A0 information to the IKEv2 initiator about the encounte= red failure.
>>=C2=A0 =C2=A0 A possible starting pointing is
>>=C2=A0 =C2=A0 draft-boucadair-ipsecme-ipv6-ipv4-codes.
>>
>> So this email will start one week long WG adoptation call for that=
>> document [1] for WG adoptation.
>>
>> Send your comments to this list before the 2018-10-21.
>>
>> [1] https://datatracker.ietf.org/doc/draft-boucadair-ipsecme-ipv6-ipv4-codes/
>> --
>> kivinen@iki.fi=
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org=
>> https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--000000000000de505405790f676a-- From nobody Fri Oct 26 15:28: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 B8D6212D4E9 for ; Fri, 26 Oct 2018 15:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 R3nLPbDyd0ut for ; Fri, 26 Oct 2018 15:28:19 -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 443D9127148 for ; Fri, 26 Oct 2018 15:28:19 -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 w9QMSE2e007622 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 27 Oct 2018 01:28:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w9QMSEJb001912; Sat, 27 Oct 2018 01:28:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23507.38142.529398.232621@fireball.acr.fi> Date: Sat, 27 Oct 2018 01:28:14 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 3 min Archived-At: Subject: [IPsec] Agenda for Bangkok meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 22:28:22 -0000 We seem to have very short meeting, or at least we do not have that much things we want to discuss in next meeting in Bangkok. I have only received 2 agenda items, and one comment that we should discuss IPsec Compression mode for ESP (EHC) in the meeting. I.e., the current agenda for IPsecME meeting is: ---------------------------------------------------------------------- IETF 103 IPsecME WG meeting in Bangkok Wednesday, November 7, 2018 13:50-15:20 Boromphimarn 4 - Agenda bashing, Logistics -- Chairs (5 min) 13:50 - Draft status -- Chairs (15 min) 13:55 - draft-ietf-ipsecme-eddsa -> RFC8420 - draft-ietf-ipsecme-split-dns - draft-ietf-ipsecme-qr-ikev2 - draft-ietf-ipsecme-implicit-iv - draft-ietf-ipsecme-ipv6-ipv4-codes - Work items - PSK authentication (10 min) Paul Wouters - IKE over TCP implementation issues (10 min) Valery Smyslov - draft-smyslov-ipsecme-tcp-guidelines - IPsec Compression mode for ESP (EHC) (15 min) - draft-mglt-ipsecme-ikev2-diet-esp-extension ---------------------------------------------------------------------- If there is anything else you would like to talk please send email to me as soon as possible (perhaps implicit iv, or ipv6-ipv4-codes). -- kivinen@iki.fi From nobody Sat Oct 27 02:32:02 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 A66AB128CFD for ; Sat, 27 Oct 2018 02:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 B4C5BUHANoDs for ; Sat, 27 Oct 2018 02:31:56 -0700 (PDT) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C2D127AC2 for ; Sat, 27 Oct 2018 02:31:55 -0700 (PDT) Received: from DESKTOP58DFL8T (ipbcc03590.dynamic.kabel-deutschland.de [188.192.53.144]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id EA69E94B04A; Sat, 27 Oct 2018 11:31:53 +0200 (CEST) From: "Tobias Guggemos" To: "'Valery Smyslov'" , "'IPsecME WG'" References: <001e01d466d1$42875370$c795fa50$@nm.ifi.lmu.de> <033e01d46c3e$9c8bb240$d5a316c0$@gmail.com> In-Reply-To: <033e01d46c3e$9c8bb240$d5a316c0$@gmail.com> Date: Sat, 27 Oct 2018 11:31:48 +0200 MIME-Version: 1.0 Message-ID: <001501d46dd7$e33f7510$a9be5f30$@nm.ifi.lmu.de> X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdRlbbE9N6OWrYbbQ/2iQK0xgl1pVQGwCaKAAGmTAJA= Content-Language: de Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="=-=vDveqvQQbIBDpo=-=" Archived-At: Subject: Re: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compression (EHC) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 09:32:01 -0000 This is a multipart message in MIME format. --=-=vDveqvQQbIBDpo=-= Content-Type: multipart/alternative; boundary="=-=ybhAEGDxnwKQu1=-=" --=-=ybhAEGDxnwKQu1=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Valery, =20 Thanks for your thoughts. The idea was to keep the notification of the support of compression separat= ed from the notification how the compression is actually performed. However, you=E2=80=99re perfectly right, it is not necessary and I=E2=80=99= m perfectly fine with not defining this new notify payload for IKEv2. =20 Regards Tobias =20 Von: Valery Smyslov =20 Gesendet: Donnerstag, 25. Oktober 2018 10:42 An: 'Tobias Guggemos' ; 'IPsecME WG' Betreff: RE: [IPsec] Proposals for IPsec Compression Mode for ESP Header Co= mpression (EHC) =20 Hi Tobias, =20 unless I missed something, I think USE_COMPRESSED_MODE notify is superfluou= s=20 and is not needed. As far as I understand, you negotiate EHC parameters per= IPsec SA basis, so if they are negotiated successfully, then compression is used for this S= A. If you need separate SA for the traffic that cannot be compressed, then neg= otiate it separately without EHC_STRATEGY_SUPPORTED notification. You may create as many IPsec SAs with the same Traffic Selectors as you like. Am I missing= something? =20 Regards, Valery. =20 From: IPsec [mailto:ipsec-bounces@ietf.org = ] On Behalf Of Tobias Guggemos Sent: Thursday, October 18, 2018 1:57 PM To: IPsecME WG Subject: [IPsec] Proposals for IPsec Compression Mode for ESP Header Compre= ssion (EHC) =20 Hey all, =20 ESP Header Compression (EHC, [1]) defines a set of rules how to compress ES= P for specific scenarios, e.g. IoT and [2] describes how to negotiate this = rules with IKEv2. Due to some suggestions we defined a new IPsec mode (COMPRESSION_MODE), whi= ch is necessary in order to prevent decompression failures in certain maybe= unforeseen situation (e.g. IP fragmentation, or the use UDP options). =20 With the new mode, the sender can decide to send certain packets =E2=80=9Cu= ncompressed=E2=80=9D if the receiver may not be able to decompress properly= . The sender notifies the receiver by using a different SA and thus a diffe= rent SPI. We believe this is more clean than defining something like a =E2=80=9Ccompr= essed=E2=80=9D bit in the ESP packet..=20 =20 That=E2=80=99s why we also thought about how to negotiate this new mode wit= h IKEv2. We believe that a clean way to negotiate this new mode is with a new Notify= Payload, namely =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D. The question is, do we need an explicit agreement of the COMPRESSED_MODE or= is the negotiation of using EHC [1] enough to figure out that the two peer= s have to use COMPRESSED_MODE anyways? =20 More specifically here are the following possibilities A) Negotiating 2 IPsec SAs with EHC parameters and specifying. with USE_COM= PRESS_MODE the SA that compress payload (using EHC). The other SA *without*= USE_COMPRESS_ MODE will not proceed to compression. In other words, EHC is= activated if and only if USE_COMPRESS_MODE is active for the SA. B) Negotiation of 2 IPsec SAs. One with EHC parameters which assumes compre= ssion is requested and one without EHC in which case no compression is perf= ormed. =20 During the last IETF we had a brief discussion in the meeting which we woul= d like to bring to the list now. We=E2=80=99re looking forward to any opinions or suggestions. =20 Regards Tobias =20 [1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06 =20 [2] https://tools.ietf.org/html/draft-mglt-ipsecme-ikev2-diet-esp-extension= -01 =20 =20 =20 --=20 _ _ _ _ _ _ Tobias Guggemos M.Sc. |\/| |\ | |\/| Institut f=C3=BCr Informatik / Dept. of CS | | | \| | | Ludwig-Maximilians-Universit=C3=A4t M=C3= =BCnchen =3D=3D=3D=3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D Oettingenstr. = 67, 80538 Munich, Germany Room E 010, Phone +49-89-2180-9209=20 Munich Network Management Team Email: guggemos@nm.ifi.lmu.de =20 Muenchner Netz-Management Team http://www.nm.ifi.lmu.de/~guggemos =20 =20 --=-=ybhAEGDxnwKQu1=-= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey Valery,

 

Th= anks for your thoughts.

The idea was to keep the notification of = the support of compression separated from the notification how the compress= ion is actually performed.

However, you=E2=80=99re perfectly righ= t, it is not necessary and I=E2=80=99m perfectly fine with not defining thi= s new notify payload for IKEv2.

<= span lang=3DEN-US style=3D'color:#1F497D'> 

Regards

Tobias

 

Von: Valery Smyslov <smyslov.ietf@gmail= .com>
Gesendet: Donnerstag, 25. Oktober 2018 10:42
An: 'Tobias Gug= gemos' <guggemos@nm.ifi.lmu.de>; 'IPsecME WG' <ipsec@ietf.org><= br>Betreff: RE: [IPsec] Proposals for IPsec Compression Mode for ESP= Header Compression (EHC)

 

Hi Tobias,

 

unless I missed some= thing, I think USE_COMPRESSED_MODE notify is superfluous =

and is not needed. As far as I understand, you negotiate EHC para= meters per IPsec SA basis,

so if they are negoti= ated successfully, then compression is used for this SA.<= /p>

If you need separate SA for the traffic that cannot be compressed,= then negotiate

it separately without EHC_STRATE= GY_SUPPORTED notification. You may create

as man= y IPsec SAs with the same Traffic Selectors as you like. Am I missing somet= hing?

 

Regards,=

Valery.

 <= /o:p>

From: IPsec [mailto:ips= ec-bounces@ietf.org] On Behalf Of = Tobias Guggemos
Sent: Thursday, October 18, 2018 1:57 PM
<= b>To: IPsecME WG
Subject: [IPsec] Proposals for IPsec Compres= sion Mode for ESP Header Compression (EHC)

 

Hey all,

 

ESP Header Compression (EHC, [1]) defines a set of ru= les how to compress ESP for specific scenarios, e.g. IoT and [2] describes = how to negotiate this rules with IKEv2.

Due to some suggestions we defined a new IPsec mo= de (COMPRESSION_MODE), which is necessary in order to prevent decompression= failures in certain maybe unforeseen situation (e.g. IP fragmentation, or = the use UDP options).

 

With the new mode, the sender can decide to send certain packets =E2=80= =9Cuncompressed=E2=80=9D if the receiver may not be able to decompress prop= erly. The sender notifies the receiver by using a different SA and thus a d= ifferent SPI.

= We believe this is more clean than defining something like a =E2=80=9Ccompr= essed=E2=80=9D bit in the ESP packet..

 

= That=E2=80=99s why we also thought about how to negotiat= e this new mode with IKEv2.

We believe that a clean way to negotiate this new mode is wit= h a new Notify Payload, namely =E2=80=9CUSE_COMPRESSED_MODE=E2=80=9D.<= /o:p>

The question is, do= we need an explicit agreement of the COMPRESSED_MODE or is the negotiation= of using EHC [1] enough to figure out that the two peers have to use COMPR= ESSED_MODE anyways?

 

M= ore specifically here are the following possibilities

=

A) Negotiating 2 IPsec SAs with EHC= parameters and specifying. with USE_COMPRESS_MODE the SA that compress pay= load (using EHC). The other SA *without* USE_COMPRESS_ MODE will not= proceed to compression. In other words, EHC is activated if and only if US= E_COMPRESS_MODE is active for the SA.

B) Negotiation of 2 IPsec SAs. One with EHC paramet= ers which assumes compression is requested and one without EHC in which cas= e no compression is performed.

 

During the last IETF we had a brief discussion in the meeting whi= ch we would like to bring to the list now.

We=E2=80=99re looking forward to any opinions = or suggestions.

 

Regar= ds

Tobias=

 <= /span>

[1] https://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-06

[2] https://tools.ietf.org/html/dra= ft-mglt-ipsecme-ikev2-diet-esp-extension-01

 

 

--

     &= nbsp;   _  _ _  _ _  _    = ;      Tobias Guggemos M.Sc.

=

  =        |\/| |\ | |\/|    =       Institut f=C3=BCr Informatik / Dept. of CS

         |  | | \| |&n= bsp; |          Ludwig-Maximil= ians-Universit=C3=A4t M=C3=BCnchen

      = =3D=3D=3D=3D=3D=3D=3D TEAM =3D=3D=3D=3D=3D=3D=3D    &nb= sp;  Oettingenstr. 67, 80538 Munich, Germany

  &nbs= p;            &= nbsp;           &nbs= p;     Room E 010, Phone +49-89-2180-9209

Munich Network Management Team   Email: guggemos@nm.ifi.lmu.de 

Muenchner Netz-Management Team=    http://www.nm.ifi.lmu.de/~guggemos=

 

--=-=ybhAEGDxnwKQu1=-=-- --=-=vDveqvQQbIBDpo=-= Content-Transfer-Encoding: 7bit Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEyFCRjitB0A1IDrryyEcVbMgzVZ8FAlvUMHwACgkQyEcVbMgz VZ/W4gf/TYR7YNvpoC2UdaW5ottlNpqArKyb9rS9ylV9aV/MZPnYFMzoZxgckYMl 6MIhptwp+/mCzESJ+PpnF+b1ahZPTHr4JDEYZDuoksQzrtA1n3Ruh3mrs6Bde4cl ndAyxmxFNznoA+Sm+w0f2Gr25d4YwbK18aJLxzjKMEIHDZDvIFFknPim6HsFmdqd UZcHNIU4JGGfS7+pajtE2uZeBdl8dBIcdgOlhd1Qe9HO1Kb6inMxYEXqQZThfaDV wsbGBK/RyE6cI6CMuMAvTE51PbMdXrUpYa/+qBM8hTMe3Bw0qw2+uXoR5ovy/Nv2 m6Q7Y/RbEaDXiwu51qWs/j1rDFa9oQ== =Y20R -----END PGP SIGNATURE----- --=-=vDveqvQQbIBDpo=-=-- From nobody Wed Oct 31 06:55:55 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 CBB12129385; Wed, 31 Oct 2018 06:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_NONE=-0.0001, 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 VAliPww4KSRI; Wed, 31 Oct 2018 06:55:46 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 6D6C21252B7; Wed, 31 Oct 2018 06:55:42 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id f3-v6so14897077ljk.9; Wed, 31 Oct 2018 06:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=ae+LvBHv8q7XgQ1v9GshAuWj+OROQKEchvUAAEhQaR4=; b=JFPqfrr3Q0tOKD9H+N34WTR/EWD9Lz6bMumUZ2LnHchYm486xIcmwyV97xS9J0ASkw ja78DPT30wHkW5zPyvEI7OZRtbjNQDczlEUwXi4DAPtz9Cg4AHSX67Qwtm0qHdtws9P4 8hnFgJ+mvZu4b1vqR5vl86wK4s3rwScANHhc1RMrL71LdJYM4t+vuk3YHZ4MZtu0KNP3 aVFQ+6bTTfqRZmVl/bZzzynYLQlwfybyHXTXmcAptmBGEy3XIL83CX7wWwarydOzrXjv eR1jhZcgYgY7gZ76DjoEslmVwUhPkkC8m1t4uvl2hKFzuHZ/86uR8yXaYGdbC6OsDrZF jDNQ== 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:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=ae+LvBHv8q7XgQ1v9GshAuWj+OROQKEchvUAAEhQaR4=; b=D2y/LHiuT3JFZ9CBJfWpf7ZVmlpShe+q4peTfm6jcD7QF8ZG1EBjL6iK/t+ko2Bc2u 1Czi1rwi8xvXAwLuibg4RLJHUiCLJGkGwl5iDuQsIh4XuwrmAq80wErnd9mavruY/zrU Jujz00ywnHbwj/BK7c1fxjJSELySmBWCu9EXp+ikr5vg/13d3otDUClZmJVRBleMxz32 DkJ3vazdmt863aLXrV70t07DhlDbZJ6n+CUs8L0HNtBpMeF7oGlQEogw6a+D/0TRj06f pr7GkjDA2CDf4LSML26cOfhm++x7UuyRq+hH7NlNbEDwKHclANz1Iukx51o9VNzXPAHw vkvg== X-Gm-Message-State: AGRZ1gKHJdmmOC8brHXIngs6RmA6awgIIGREjtbCMmyNfB9KoI5kxxhO CYnvHQOO0pM0xhhCvgDnM1mXm64t X-Google-Smtp-Source: AJdET5c2n6d77F4mkdGG2hgCqjmLQrr5rJaji0HSjWl1B0uOeBpvvlpIRm0yos/i1Hx7ylS68WhFqw== X-Received: by 2002:a2e:a202:: with SMTP id h2-v6mr2121197ljm.72.1540994139999; Wed, 31 Oct 2018 06:55:39 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g2-v6sm1521303ljg.9.2018.10.31.06.55.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Oct 2018 06:55:39 -0700 (PDT) From: "Valery Smyslov" To: "IPsecME WG" Cc: Date: Wed, 31 Oct 2018 16:55:23 +0300 Message-ID: <06bb01d47121$5f7bb7f0$1e7327d0$@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: AdRxISFkud4inQZOTYCMbnQCiNECBQ== Archived-At: Subject: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 13:55:53 -0000 Hi, here are some comments on -02 QSKE draft to stimulate further discussion. 1. Nonces. The draft specifies that each additional key exchange performed over IKE_AUX includes new nonces. My question - why nonces exchanged during IKE_SA_INIT cannot be used instead? Is it critical for security? I have no problem with exchanging new nonces in each IKE_AUX, my concern is that while performing authentication only the nonces exchanged in IKE_SA_INIT are covered by the signature. For example for initiator: InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI where NonceRData is the content of the responder's nonce from IKE_SA_INIT. Currently IKE_AUX draft doesn't redefine this, except that it adds initiator's IKE_AUX content into the calculation. Is it OK, or should we modify AUTH payload calculation in case QSKE is used? In particular - include all the peer's nonces from IKE_AUX exchanges in NonceRData? 2. QSKE negotiation. I still think that we can use the existing negotiation mechanism instead of defining an additional one. I don't think we should consider the argument that now there are buggy implementations out there, since we're developing a long term solution. How it can be done with existing mechanism. First approach, classical: we define new transform types as follows: Transform Type 6: QSKE of type 1 (say lattice based) Transform Type 7: QSKE of type 2 (say isogeny based) Transform Type 8: QSKE of type 3 (say code based) etc. In this case list of Transform IDs for each new Transform Type will be different - only relevant algorithms must be included. In addition some QSKE Transform IDs with a small public key (regardless of type) will also be added to the list of possible Transform IDs for Transform Type 4. With this approach there's no strict mapping from QSKE to IKE_AUX, actually all the selected QSKE can be put together into single IKE_AUX exchange or can be performed one after one in a series of IKE_AUX exchanges. The latter seems more natural and is in line with current QSKE draft. Note, that KE from Transform Type 4 will always be performed in IKE_SA_INIT. If QSKEs are performed in a series of IKE_AUX, the order of them is not defined explicitly. Either we decide that the order is not imported (if it is OK from security PoV), or the order will be implicitly defined by the order of new Transform Types (6 and up) in initiator's proposal (there is no requirement in RFC 7296 that responder keep the order of Transform Types in a response). This approach has a potential problem: if more types of QSKE appear this will require to add new Transform Types. Since old implementations are unaware of these types (even if they are aware of Types 6, 7, 8 etc), policy need to be written in such a way, that proposals are doubled - one with new types and one without them. This will increase the size of SA payload. This problem can be dealt with if we define spare Transform Types beforehand - so as the same time as Transform Types 6-8 are defined for known types of QSKE, we can define also Transform Types 9, 10, 11 and so on (how many is enough?) for yet unknown types of QSKE (populated only with NONE Transform ID for now). With this "hack" all new implementations will know what these transforms are and won't reject proposals with them. Another problem with this approach is that if we want to express policy "perform single QSKE of any type" then the number of proposals would grow, since initiator has to include all the new Transform Types in each proposal including NONE Transform ID in all but one Transform Type, different in each proposal. For these reasons I think a different approach is more convenient: we define new transform types as follows: Transform Type 6: Additional QSKE performed in 1st IKE_AUX Transform Type 7: Additional QSKE performed in 2nd IKE_AUX Transform Type 8: Additional QSKE performed in 3rd IKE_AUX etc. (How many do we want to combine?) The same list of possible Transform IDs representing QSKE methods will be defined for each of these new Transform Types. In addition these QSKE Transform IDs (or some of them with a small enough public key) will also be added to the list of possible Transform IDs for Transform Type 4. This approach is flexible enough to define various policies: - don't use QSKE - use a single QSKE (in addition to classical KE) - use combination of no less than two (three, etc) QSKEs The SA payload may still grow if you want to restrict which QSKE methods can be combined with which ones. Comparing to the separate negotiation mechanism proposed in the draft: - it seems that using SA Proposals is clearer than separate mechanism - in case of complex policies the size of SA payload may grow, so the size of IKE_SA_INIT request may be larger than with the draft's negotiation mechanism. I still hope that we can avoid the necessity of complex policies, but if this is a concern, we may consider the draft draft-smyslov-ipsecme-ikev2-compact-04 "Compact Format of IKEv2 Payloads", which allows to substantially reduce the size of SA payload. Any thoughts? 3. CREATE_CHILD_SA The draft currently is silent about using QSKE in CREATE_CHILD_SA exchange. However it seems that QSKE methods must also be supported in this exchange (at least for IKE SA rekeying). IKE_AUX is specifically designed to be used between IKE_SA_INIT and IKE_AUTH, so either we must modify CREATE_CHILD_SA to allow multiple KE payloads or define some new exchange. My concern is that sending all QSKE payloads in one message may result in a very large number of fragments, that would potentially decrease protocol reliability on a lossy networks (if any single fragment is lost all fragments must be resent). With IKE_AUX QSKE are performed one by one, so the number of fragments will be less. If this is a concern, then some mechanisms need to be defined that allow to perform QSKE one by one even in CREATE_CHILD_SA. For example, perform a series of INFORMATIONAL exchanges linked to CREATE_CHILD_SA to complete QS key exchange: Initiator Responder ------------------------------------------------------------------- HDR, SK {SA, Ni, KEi} --> <-- HDR, SK {SA, Nr, KEr, N(ExchangeID1)} since initiator proposed and responder agreed upon that one or more QSKE need to be performed, the new SA is not created at this point, instead the responder returns some Exchange ID in a new notification (this Exchange ID allows to link INFORMATIONAL exchanges with the CREATE_CHILD_SA and with subsequent INFORMATIONAL). Then initiator starts series of INFORMATIONAL exchanges (one by one) to complete key exchange with QS methods: Initiator Responder ------------------------------------------------------------------- HDR, SK { N(ExchangeID1), N1i, QSKe1i,} --> <-- HDR, SK { N1r, QSKe1r, N(ExchangeID2)} HDR, SK { N(ExchangeID2), N2i, QSKe2i,} --> <-- HDR, SK { N2r, QSKe2r, N(ExchangeID3)} HDR, SK { N(ExchangeID3), N3i, QSKe3i,} --> <-- HDR, SK { N3r, QSKe3r} At this point all key are exchanged, so the SA is created. Any ideas? Regards, Valery. From nobody Wed Oct 31 09:16:15 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 8E1F9130DC2; Wed, 31 Oct 2018 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6Z1HjEHhfKMZ; Wed, 31 Oct 2018 09:16:05 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E891293FB; Wed, 31 Oct 2018 09:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11550; q=dns/txt; s=iport; t=1541002565; x=1542212165; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g7acmFAgAazEJjVYHzEYH34b/MYMTP/Z+iQ0Hmk6BA8=; b=CxNyjq1yzw9oDctmdQnorbEP/hSTRYr5DktNvezou+9uOJbuj+tgBwwA uKyzJ10kv8sHU0obVvk0wqqm2rPWE2nWNPqzaKehQRUR9kk/19/cZKYqr E5NjnVmvnNAeIgNNaD5kpKMWRrbZ8vygIGwr4W301z3Ec3J2drYNv7+cb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAACO1Nlb/5FdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggSBZSgKmiN6iAeQIAsBAYRsAoM3Ijc?= =?us-ascii?q?KDQEDAQECAQECbSiFOgEBAQMBJxM/BQcEAgEIEQQBAR8QIREdCAEBBAENBQg?= =?us-ascii?q?ThHADDQipQTOHfg2CGItpF4FBP4EQAYJdNYJWgk6FNQKIYiSVRSYuCQKKDYN?= =?us-ascii?q?SgyEgkE+NfYkNAhEUgSYzIoFVcBU7gmyCJQEXjhpviwCBHwEB?= X-IronPort-AV: E=Sophos;i="5.54,447,1534809600"; d="scan'208";a="194417381" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Oct 2018 16:16:04 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9VGG3Wb028488 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Oct 2018 16:16:04 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 31 Oct 2018 12:16:02 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1395.000; Wed, 31 Oct 2018 12:16:02 -0400 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , IPsecME WG CC: "draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org" Thread-Topic: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 Thread-Index: AdRxISFkud4inQZOTYCMbnQCiNECBQABjTEg Date: Wed, 31 Oct 2018 16:16:02 +0000 Message-ID: <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> In-Reply-To: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.146, xch-rtp-006.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 16:16:13 -0000 > -----Original Message----- > From: Valery Smyslov > Sent: Wednesday, October 31, 2018 9:55 AM > To: IPsecME WG > Cc: draft-tjhai-ipsecme-hybrid-qske-ikev2@ietf.org > Subject: Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 >=20 > Hi, >=20 > here are some comments on -02 QSKE draft to stimulate further discussion. >=20 >=20 > 1. Nonces. >=20 > The draft specifies that each additional key exchange performed > over IKE_AUX includes new nonces. My question - why nonces exchanged > during IKE_SA_INIT cannot be used instead? Is it critical for securit= y? No, it is not. Instead, we were (mostly) reusing the format of the CREATE_= CHILD_SA request; as that request already had nonces, we saw no specific re= ason to remove them. > I have no problem with exchanging new nonces in each IKE_AUX, > my concern is that while performing authentication only the nonces > exchanged in IKE_SA_INIT are covered by the signature. For example > for initiator: >=20 > InitiatorSignedOctets =3D RealMessage1 | NonceRData | MACedIDForI >=20 > where NonceRData is the content of the responder's nonce from > IKE_SA_INIT. > Currently IKE_AUX draft doesn't redefine this, except that it adds in= itiator's > IKE_AUX content into the calculation. Is it OK, or should we modify A= UTH > payload > calculation in case QSKE is used? In particular - include all the pee= r's > nonces from IKE_AUX exchanges in NonceRData? Your draft includes the hash (collision resistant PRF, actually) of the aux= messages in the AUX_I, which is included in the data which is signed. Bec= ause the nonces are included in computing the AUX_I messages, we are protec= ted; there is no specific need to include those nonces separately. >=20 >=20 > 2. QSKE negotiation. >=20 > I still think that we can use the existing negotiation mechanism inste= ad of > defining an additional one. I don't think we should consider the argum= ent > that now there are buggy implementations out there, since we're > developing a long term solution. >=20 > How it can be done with existing mechanism. >=20 > First approach, classical: we define new transform types as follows: >=20 > Transform Type 6: QSKE of type 1 (say lattice based) > Transform Type 7: QSKE of type 2 (say isogeny based) > Transform Type 8: QSKE of type 3 (say code based) > etc. >=20 > In this case list of Transform IDs for each new Transform Type will b= e > different - only relevant > algorithms must be included. In addition some QSKE Transform IDs with= a > small public key > (regardless of type) will also be added to the list of possible Trans= form IDs > for Transform Type 4. Minor comment on the last bit about making small public key transforms all = type 4; because (with your proposal) the responder can't accept more than o= ne type 4 transform, that would mean that you couldn't bundle (say) Curve25= 519 and SIKE (which is a small postquantum key exchange). I would claim that is something that we would want to allow people to negot= iate (as SIKE isn't necessarily well trusted, and so it would be plausible = that someone would like to negotiate Curve25519 as well). >=20 > With this approach there's no strict mapping from QSKE to IKE_AUX, > actually all the > selected QSKE can be put together into single IKE_AUX exchange or can= be > performed > one after one in a series of IKE_AUX exchanges. The latter seems more > natural > and is in line with current QSKE draft. Note, that KE from Transform T= ype 4 > will > always be performed in IKE_SA_INIT. If QSKEs are performed in a serie= s of > IKE_AUX, > the order of them is not defined explicitly. Either we decide that the= order > is not imported > (if it is OK from security PoV), or the order will be implicitly defin= ed by the > order > of new Transform Types (6 and up) in initiator's proposal (there is no > requirement in RFC 7296 that > responder keep the order of Transform Types in a response). My issue with this general idea is backwards compatibility; if we issue a t= ransform of type 5 to an old IKEv2 system, it may reject the entire exchang= e with an "unrecognized transform type" error (and yes, there are real syst= ems that behave this way). And, it could be argued that such an IKEv2 implementation would be complian= t; section 3.3.3 of RFC7296 would appear to forbid any transform types othe= r than 1-4 in an IKE negotiation. >=20 > This approach has a potential problem: if more types of QSKE appear th= is > will require to add > new Transform Types. Since old implementations are unaware of these > types (even if they are > aware of Types 6, 7, 8 etc), policy need to be written in such a way, > that proposals are doubled - one with new types and one without them. > This will increase the size of SA payload. This problem can be dealt w= ith > if we define spare Transform Types beforehand - so as the same time > as Transform Types 6-8 are defined for known types of QSKE, > we can define also Transform Types 9, 10, 11 and so on (how many is > enough?) > for yet unknown types of QSKE (populated only with NONE Transform ID > for now). > With this "hack" all new implementations will know what these transfo= rms > are > and won't reject proposals with them. >=20 > Another problem with this approach is that if we want to express polic= y > "perform single QSKE of any type" then the number of proposals would > grow, since initiator has to include all the new Transform Types > in each proposal including NONE Transform ID in all but one Transform > Type, > different in each proposal. >=20 > For these reasons I think a different approach is more convenient: we > define > new transform types as follows: >=20 > Transform Type 6: Additional QSKE performed in 1st IKE_AUX > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX > etc. (How many do we want to combine?) >=20 > The same list of possible Transform IDs representing QSKE methods wil= l be > defined > for each of these new Transform Types. In addition these QSKE Transfo= rm > IDs > (or some of them with a small enough public key) will also be added t= o the > list > of possible Transform IDs for Transform Type 4. Why not make them all a possible transform id for type 4? After all, there= are scenarios where fragmentation is not an issue (e.g. TCP encaps) >=20 > This approach is flexible enough to define various policies: > - don't use QSKE > - use a single QSKE (in addition to classical KE) > - use combination of no less than two (three, etc) QSKEs >=20 > The SA payload may still grow if you want to restrict which QSKE meth= ods > can be combined with which ones. >=20 > Comparing to the separate negotiation mechanism proposed in the draft: > - it seems that using SA Proposals is clearer than separate mechanism > - in case of complex policies the size of SA payload may grow, so the = size > of IKE_SA_INIT request may be larger than with the draft's negotiati= on > mechanism. I still hope that we can avoid the necessity of complex > policies, but if this is a concern, we may consider the draft > draft-smyslov-ipsecme-ikev2-compact-04 "Compact Format of IKEv2 > Payloads", > which allows to substantially reduce the size of SA payload. >=20 > Any thoughts? Now, one thing that had been bothering me with our proposal is that there i= s no way to include attributes along with the transform id. Now, the exist= ing DH/ECDH transforms do not have any attributes defined; however some of = the NIST submissions have a large number of variations (Round2 had 30 diffe= rent ones), and while we could make each variation a different transform id= (which is effectively what we did with DH and ECDH; there really is only o= ne DH algorithm; the exact transform id selected which parameters were used= with that algorithm), however it's not clear if that's the approach we wan= t to mandate with the newer postquantum transforms. >=20 > 3. CREATE_CHILD_SA >=20 > The draft currently is silent about using QSKE in CREATE_CHILD_SA > exchange. Or, more specifically, using more than one keying mechanism; you can use an= y single KE for a CREATE_CHILD_SA, either conventional or postquantum. Actually, I believe that there is some weasel working saying "you can get t= his effect by negotiating several child SA's in succession"; however, I can= certainly understand it if the working group decided that was not acceptab= le... > However it seems that QSKE methods must also be supported in this > exchange (at least for IKE SA rekeying). IKE_AUX is specifically desi= gned > to be used between IKE_SA_INIT and IKE_AUTH, so either we must > modify CREATE_CHILD_SA to allow multiple KE payloads or define > some new exchange. My concern is that sending all QSKE payloads > in one message may result in a very large number of fragments, that w= ould > potentially decrease protocol reliability on a lossy networks (if any= single > fragment is lost all fragments must be resent). With IKE_AUX QSKE > are performed one by one, so the number of fragments will be less. > If this is a concern, then some mechanisms need to be defined > that allow to perform QSKE one by one even in CREATE_CHILD_SA. > For example, perform a series of INFORMATIONAL exchanges > linked to CREATE_CHILD_SA to complete QS key exchange: >=20 > Initiator Responder > ------------------------------------------------------------------- > HDR, SK {SA, Ni, KEi} --> > <-- HDR, SK {SA, Nr, KEr, N(ExchangeID1)= } >=20 > since initiator proposed and responder agreed upon that > one or more QSKE need to be performed, the new SA is not > created at this point, instead the responder returns some > Exchange ID in a new notification (this Exchange ID allows > to link INFORMATIONAL exchanges with the CREATE_CHILD_SA > and with subsequent INFORMATIONAL). Then initiator starts > series of INFORMATIONAL exchanges (one by one) to complete > key exchange with QS methods: >=20 > Initiator Responder > ------------------------------------------------------------------- > HDR, SK { N(ExchangeID1), N1i, QSKe1i,} --> > <-- HDR, SK { N1r, QSKe1r, N(ExchangeID2= )} >=20 > HDR, SK { N(ExchangeID2), N2i, QSKe2i,} --> > <-- HDR, SK { N2r, QSKe2r, N(ExchangeID3= )} >=20 > HDR, SK { N(ExchangeID3), N3i, QSKe3i,} --> > <-- HDR, SK { N3r, QSKe3r} >=20 > At this point all key are exchanged, so the SA is created. I suspect you'll need to be more explicit about having something tying the = multiple messages together. After all, there can be several of these excha= nges going on simultaneously; it would be good to be explicit. >=20 > Any ideas? >=20 > Regards, > Valery. >=20 >=20 From nobody Wed Oct 31 16:04:36 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 08BC6130E8A; Wed, 31 Oct 2018 16:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, 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 7-bsEspguZMW; Wed, 31 Oct 2018 16:04:22 -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 BB1D7130E59; Wed, 31 Oct 2018 16:04:21 -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 w9VN3qXF022183 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Nov 2018 01:03:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w9VN3qeT026073; Thu, 1 Nov 2018 01:03:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23514.13527.860102.126373@fireball.acr.fi> Date: Thu, 1 Nov 2018 01:03:51 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: Valery Smyslov , IPsecME WG , "draft-tjhai-ipsecme-hybrid-qske-ikev2\@ietf.org" In-Reply-To: <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> References: <06bb01d47121$5f7bb7f0$1e7327d0$@gmail.com> <2fd3f2617b5a4ed7b0d5892e9cb1c9fe@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 30 min X-Total-Time: 32 min Archived-At: Subject: Re: [IPsec] Some comments on draft-tjhai-ipsecme-hybrid-qske-ikev2-02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2018 23:04:34 -0000 Scott Fluhrer (sfluhrer) writes: > My issue with this general idea is backwards compatibility; if we > issue a transform of type 5 to an old IKEv2 system, it may reject > the entire exchange with an "unrecognized transform type" error (and > yes, there are real systems that behave this way). That implementation is broken, and needs to be fixed. > And, it could be argued that such an IKEv2 implementation would be > compliant; section 3.3.3 of RFC7296 would appear to forbid any > transform types other than 1-4 in an IKE negotiation. That is not true. Section 3.3.3 lists mandatory types, and those optional types, which are included in that RFC. It does NOT list any of the future optional types. In section 3.3.6 this is explained very clearly: If the responder receives a proposal that contains a Transform Type it does not understand, or a proposal that is missing a mandatory Transform Type, it MUST consider this proposal unacceptable; however, other proposals in the same SA payload are processed as usual. Similarly, if the responder receives a transform that it does not understand, or one that contains a Transform Attribute it does not understand, it MUST consider this transform unacceptable; other transforms with the same Transform Type are processed as usual. This allows new Transform Types and Transform Attributes to be defined in the future. I.e., the intention is that if there is transform type you do not understand you skip whole proposal, but STILL PROCESS rest of the proposals normally, i.e., this allows backward compatiblity. I.e., if we have SA payload: SA Payload | +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, | | 14 transforms) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) | +-- Transform D-H ( Name = 8192-bit MODP Group ) | +-- Transform D-H ( Name = Curve25519 ) | +-- Transform D-H ( Name = Curve448 ) | +-- Transform QSKE1 ( Name = Foobar ) | +-- Transform QSKE1 ( Name = Zappa ) | +--- Proposal #2 ( Proto ID = IKE(1), SPI size = 0, | | 14 transforms) | | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 128 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 192 ) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | | +-- Attribute ( Key Length = 256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 ) | +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 ) | +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) | +-- Transform D-H ( Name = 8192-bit MODP Group ) | +-- Transform D-H ( Name = Curve25519 ) | +-- Transform D-H ( Name = Curve448 ) | +-- Transform QSKE1 ( Name = Foobar ) | +-- Transform QSKE2 ( Name = Zappa ) | +--- Proposal #3 ( Proto ID = IKE(1), SPI size = 0, | 12 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 128 ) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 192 ) +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_384 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_256_128 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_384_192 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = 8192-bit MODP Group ) +-- Transform D-H ( Name = Curve25519 ) +-- Transform D-H ( Name = Curve448 ) Then complient old implementation will ignore proposals 1 and 2, as they include Transforms they do not understand, and see that proposal 3 has all the things it needs, and nothing extra, and then it will pick one value for each Transform Type and return that back i.e., it might return: +--- Proposal #3 ( Proto ID = IKE(1), SPI size = 0, | 4 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve448 ) If you have implementation that do support QSKE algorithm "Zappa", but not "Foobar", then it will ignore the Proposal 2, as proposal 2 has QSKE1 transform ID of "Foobar" which it does not support (and as that has both QSKE1 and QSKE2, so it must pick one value from both. So it would then pick proposal 1 and return: +--- Proposal #1 ( Proto ID = IKE(1), SPI size = 0, | 5 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve448 ) +-- Transform QSKE1 ( Name = Zappa ) Implementation which supports both "Foobar" and "Zappa", can either do one of them by picking proposal #1, and selecting the one it wants to do in QSKE1, or it can also pick proposal #2 and do both "Foobar" and "Zappa", and Foobar will be done as QSKE1 and Zappa is done as QSKE2: +--- Proposal #6 ( Proto ID = IKE(1), SPI size = 0, | 6 transforms) | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | +-- Attribute ( Key Length = 256 ) +-- Transform PRF ( Name = PRF_HMAC_SHA2_512 ) +-- Transform INTEG ( Name = AUTH_HMAC_SHA2_512_256 ) +-- Transform D-H ( Name = Curve448 ) +-- Transform QSKE1 ( Name = Foobar ) +-- Transform QSKE2 ( Name = Zappa ) > > For these reasons I think a different approach is more > > convenient: we define new transform types as follows: > > > > Transform Type 6: Additional QSKE performed in 1st IKE_AUX > > Transform Type 7: Additional QSKE performed in 2nd IKE_AUX > > Transform Type 8: Additional QSKE performed in 3rd IKE_AUX > > etc. (How many do we want to combine?) > > > > The same list of possible Transform IDs representing QSKE > > methods will be defined for each of these new Transform Types. In > > addition these QSKE Transform IDs (or some of them with a small > > enough public key) will also be added to the list of possible > > Transform IDs for Transform Type 4. > > Why not make them all a possible transform id for type 4? After all, > there are scenarios where fragmentation is not an issue (e.g. TCP > encaps) If all of them are Transform Type 4, i.e. D-H, then responder MUST pick exactly one that is the only one to be used. Responder is not allowed return more than one Transform ID for each Transform Type there is in proposal. > Now, one thing that had been bothering me with our proposal is that > there is no way to include attributes along with the transform id. > Now, the existing DH/ECDH transforms do not have any attributes > defined; however some of the NIST submissions have a large number of > variations (Round2 had 30 different ones), and while we could make > each variation a different transform id (which is effectively what > we did with DH and ECDH; there really is only one DH algorithm; the > exact transform id selected which parameters were used with that > algorithm), however it's not clear if that's the approach we want to > mandate with the newer postquantum transforms. Each Transform ID can also have arbitrary number of attributes inside, and the as you can have multiple entries with same Transform Type, but either different Transform ID or different Attributes inside, the responder can pick exactly one of the Transform Type of that type, and include all attributes unmodified. Currently we only have Key Length attribute, but lets say we later define "Key Rounds" attribute, then we could have Transform Type ENCR with following proposals: +-- Transform ENCR ( Name = ENCR_FOO ) | +-- Attribute ( Key Length = 128 ) | +-- Attribute ( Key Rounds = 16 ) +-- Transform ENCR ( Name = ENCR_FOO ) | +-- Attribute ( Key Length = 256 ) | +-- Attribute ( Key Rounds = 32 ) +-- Transform ENCR ( Name = ENCR_AES_CBC ) +-- Attribute ( Key Length = 256 ) And now responder can return any of the 3 proposed ENCR transforms, i.e.: +-- Transform ENCR ( Name = ENCR_FOO ) +-- Attribute ( Key Length = 128 ) +-- Attribute ( Key Rounds = 16 ) or +-- Transform ENCR ( Name = ENCR_FOO ) +-- Attribute ( Key Length = 256 ) +-- Attribute ( Key Rounds = 32 ) or +-- Transform ENCR ( Name = ENCR_AES_CBC ) +-- Attribute ( Key Length = 256 ) but nothing else. It cannot modify the attributes in any way. -- kivinen@iki.fi