From nobody Wed Apr 6 05:27:54 2022 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 D043E3A199D; Wed, 6 Apr 2022 05:27:51 -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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <164924807176.8548.6981260676786408454@ietfa.amsl.com> Date: Wed, 06 Apr 2022 05:27:51 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-06.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: Wed, 06 Apr 2022 12:27:52 -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 : Group Key Management using IKEv2 Authors : Valery Smyslov Brian Weis Filename : draft-ietf-ipsecme-g-ikev2-06.txt Pages : 68 Date : 2022-04-06 Abstract: This document presents an extension to the Internet Key Exchange version 2 (IKEv2) protocol for the purpose of a group key management. The protocol is in conformance with the Multicast Security (MSEC) key management architecture, which contains two components: member registration and group rekeying. Both components require a Group Controller/Key Server to download IPsec group security associations to authorized members of a group. The group members then exchange IP multicast or other group traffic as IPsec packets. This document obsoletes RFC 6407. This documents also updates RFC 7296 by renaming one of transform types defined there. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-06 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Apr 6 05:44:12 2022 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 AEEAC3A19B1 for ; Wed, 6 Apr 2022 05:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw1J5TF2FnEr for ; Wed, 6 Apr 2022 05:44:10 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C083C3A19A9 for ; Wed, 6 Apr 2022 05:44:09 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id q68so3049789ljb.3 for ; Wed, 06 Apr 2022 05:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=dkksDhD4uzgq8KkK/+fySbwBFhlx8O0T7mLhRv7Czqs=; b=IjzifNoBxKIzUobt3vQpeVj5nDVOQn+P/tUdL8flLGaPSBWAClG0s1gG7NU04K40gD LMthOuWnjf3y/MEBa2goZubBAVwz0ly4dyonzHNEXRMmWzw2zNClTFHuwMtS3bo0IV7h DdfxdPHqGvYplRrh80++9362GQcHkNLkUnvJotpZH7VyaYwvgUCHkfTIWuTESQ5NiN8H TdvjqeGsKLlyA+ULgtNNL9Wk3jxfNeaeBBUCIGF/08RXadYCue8lT/FefQnt1rm76Sz1 h2YVxlmO2OFf7Moh16uBUI4DRCG+kZMCJcz4Jd4p4EIl+wf9Atm5ap0tN/ZjyKkIzVKa jH3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=dkksDhD4uzgq8KkK/+fySbwBFhlx8O0T7mLhRv7Czqs=; b=O92EVpYU/RaKNzz1PYTBgadfMrNVXqPaVsHWEmz8h1OZRTvh+JnnoW17BcV9TJXSz/ /dMmG1qWSjoHxI2OH9I6H0/X5eu4DLCwqPSjvrp7IGCG80nCG74uzviYbTFNRsQe7kiV o+1swW8XrNYbx5Q2JUn3ecfsUG+8OPQmpTmXxEeIwhFjM8yfVlRJMcmNQCHw2gUsPlLd fDnRFpqQobDWpM6g7Khtr6X5afiukNn+xkYd7I7faHxniFc7Lpi4MUe1jhDZtFF6fUDz PekzPfgk7VxTTsHALQDKHS6GS0fh0XWGuB/iD+gqE7czjmb1dExaIfGvaOFQFui/8cat ApEw== X-Gm-Message-State: AOAM5334zZFfIy51lB85hE8xgoYLP71XaJqINiR/SKKva3BaIL7vW7pu HTa4EVZI6QZEM2GYZIVt5xJJuvIk8Gw= X-Google-Smtp-Source: ABdhPJz+vGN5176NQt1YfGsDtE3t6TysiuUEJXavOjjXH4LRFBmE8nWEcFnZx1SaaK6i9DEijdRq8g== X-Received: by 2002:a05:651c:b22:b0:24b:12c7:cf24 with SMTP id b34-20020a05651c0b2200b0024b12c7cf24mr5096239ljr.433.1649249047369; Wed, 06 Apr 2022 05:44:07 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id g2-20020a2ea4a2000000b0024983b1a8dcsm1577241ljm.105.2022.04.06.05.44.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Apr 2022 05:44:06 -0700 (PDT) From: "Valery Smyslov" To: References: <164924807176.8548.6981260676786408454@ietfa.amsl.com> In-Reply-To: <164924807176.8548.6981260676786408454@ietfa.amsl.com> Date: Wed, 6 Apr 2022 15:44:07 +0300 Message-ID: <1da401d849b4$02446f90$06cd4eb0$@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: AQGA+WVAZBQyxb+rBBJX9seeeXwKeq2RcXfQ Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-06.txt 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, 06 Apr 2022 12:44:12 -0000 Hi, this version addresses discussion we had at IETF 113. In particular: 1. Explicit PSK authentication is removed. 2. USE_TRANSPORT_MODE notification is used as in IKEv2 (which implies a restriction that all IPsec SAs in GSA must use the same mode). 3. Using ESN is MUST NOT now, but it is MUST for GCKS to rekey frequently enough to prevent SN overlap. 4. Using replay protection is clarified. This is probably the most important change, since the semantics of "Extended Sequence Numbers" transform is enhanced, which leads to its renaming to "Replay Protection" transform and thus we formally update RFC 7296 (although only by renaming IANA registry). See new section 2.6. 5. UDP encapsulation of ESP is prohibited for multicast Data-Security SAs. 6. Default Activation Time Delay and Deactivation Time Delay are set to 0 (no delay, wasn't specified before). 7. Using tunnel and transport mode clarified. 8. Clarified, that using port 848 in the IKE_SA_INIT exchange doesn't change behavior comparing to port 500 (in particular, in both cases switch to 4500 in case of NAT). 9. Multiple text improvements. Please, review. Regards, Valery. > 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 : Group Key Management using IKEv2 > Authors : Valery Smyslov > Brian Weis > Filename : draft-ietf-ipsecme-g-ikev2-06.txt > Pages : 68 > Date : 2022-04-06 > > Abstract: > This document presents an extension to the Internet Key Exchange > version 2 (IKEv2) protocol for the purpose of a group key management. > The protocol is in conformance with the Multicast Security (MSEC) key > management architecture, which contains two components: member > registration and group rekeying. Both components require a Group > Controller/Key Server to download IPsec group security associations > to authorized members of a group. The group members then exchange IP > multicast or other group traffic as IPsec packets. This document > obsoletes RFC 6407. This documents also updates RFC 7296 by renaming > one of transform types defined there. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-g-ikev2-06 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sun Apr 10 17:02:19 2022 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 B305B3A17C5; Sun, 10 Apr 2022 17:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 5IxHXh7rUm4z; Sun, 10 Apr 2022 17:02:03 -0700 (PDT) Received: from rfcpa.amsl.com (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6283A17C3; Sun, 10 Apr 2022 17:02:03 -0700 (PDT) Received: by rfcpa.amsl.com (Postfix, from userid 499) id 541A5E43A5; Sun, 10 Apr 2022 17:02:03 -0700 (PDT) To: nmalykh@gmail.com, charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi From: RFC Errata System Cc: paul.wouters@aiven.io, iesg@ietf.org, ipsec@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220411000203.541A5E43A5@rfcpa.amsl.com> Date: Sun, 10 Apr 2022 17:02:03 -0700 (PDT) Archived-At: Subject: [IPsec] [Errata Rejected] RFC7296 (4930) 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, 11 Apr 2022 00:02:08 -0000 The following errata report has been rejected for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid4930 -------------------------------------- Status: Rejected Type: Editorial Reported by: Nikolai Malykh Date Reported: 2017-02-08 Rejected by: Paul Wouters (IESG) Section: 3.16 Original Text ------------- Note that since IKE passes an indication of initiator identity in the first message in the IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity requests. The initiator MAY, however, respond to such requests if it receives them. Corrected Text -------------- Notes ----- The last sentence of this section contains unnecessary repetition written above (the last sentence in description of Type field). --VERIFIER NOTES-- The text is fine and clear as is. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Apr 10 17:06:26 2022 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 0C3663A17D0; Sun, 10 Apr 2022 17:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 BjvYfKOUJarm; Sun, 10 Apr 2022 17:06:14 -0700 (PDT) Received: from rfcpa.amsl.com (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D483A17CE; Sun, 10 Apr 2022 17:06:13 -0700 (PDT) Received: by rfcpa.amsl.com (Postfix, from userid 499) id 6C4F4E43A5; Sun, 10 Apr 2022 17:06:13 -0700 (PDT) To: mtaylor@unicoi.com, charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi From: RFC Errata System Cc: paul.wouters@aiven.io, iesg@ietf.org, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220411000613.6C4F4E43A5@rfcpa.amsl.com> Date: Sun, 10 Apr 2022 17:06:13 -0700 (PDT) Archived-At: Subject: [IPsec] [Errata Held for Document Update] RFC7296 (5056) 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, 11 Apr 2022 00:06:18 -0000 The following errata report has been held for document update for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5056 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Michael Taylor Date Reported: 2017-06-29 Held by: Paul Wouters (IESG) Section: 1.7 Original Text ------------- This document removes discussion of the INTERNAL_ADDRESS_EXPIRY configuration attribute because its implementation was very problematic. Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY Corrected Text -------------- Unclear what it should be Notes ----- Configuration attribute 5, INTERNAL_ADDRESS_EXPIRY, is a type of attribute in a configuration payload. It is not an attribute in a proposal. As documented in Section 2.7 proposals are part of an SA payload. An SA payload consists of one or more proposals. Each proposal includes one protocol. Each protocol contains one or more transforms -- each specifying a cryptographic algorithm. Each transform contains zero or more attributes (attributes are needed only if the Transform ID does not completely specify the cryptographic algorithm). So the correct behavior when one receives a *configuration* payload with INTERNAL_ADDRESS_EXPIRY cannot be to ignore a proposal. Was the intent to say that the configuration payload should be ignored? Was the intent to say that the configuration payload should be processed but the INTERNAL_ADDRESS_EXPIRY attribute ignored? Clearly these choices would result in radically different outcomes for the negotiation. Paul Wouters: This comment is about the use of the word "proposal" which I agree is open to wrong interpretation. My suggestion would be: Current: Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY Proposed: Implementations that conform to this document MUST process configuration attribute value 5 similar to any other unknown Attribute Type. It is mostly obvious that only the attribute type should be ignored, not the entire proposal. Therefor Held for Document update as it does not affect implementations but the wording should be improved in future versions of the document -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Apr 10 17:15:09 2022 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 EE6313A17EC; Sun, 10 Apr 2022 17:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 r2z-F_jTPwkQ; Sun, 10 Apr 2022 17:15:02 -0700 (PDT) Received: from rfcpa.amsl.com (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819D53A17EA; Sun, 10 Apr 2022 17:15:02 -0700 (PDT) Received: by rfcpa.amsl.com (Postfix, from userid 499) id 39E62E43A5; Sun, 10 Apr 2022 17:15:02 -0700 (PDT) To: andrew.cagney@gmail.com, charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi From: RFC Errata System Cc: paul.wouters@aiven.io, iesg@ietf.org, ipsec@ietf.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220411001502.39E62E43A5@rfcpa.amsl.com> Date: Sun, 10 Apr 2022 17:15:02 -0700 (PDT) Archived-At: Subject: [IPsec] [Errata Held for Document Update] RFC7296 (5247) 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, 11 Apr 2022 00:15:07 -0000 The following errata report has been held for document update for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5247 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Andrew Cagney Date Reported: 2018-01-30 Held by: Paul Wouters (IESG) Section: 3.10. Original Text ------------- o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. Corrected Text -------------- o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS, REKEY_SA, and CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be sent as zero to indicate NONE and MUST be ignored on receipt. Notes ----- If I assume that the 'Protocol ID' field in the notification payload is specified by: Internet Key Exchange Version 2 (IKEv2) Parameters IKEv2 Security Protocol Identifiers then a notification is using the 'Reserved' value 0. Since the value is being used, I think it would be better to give it a name. Other uses of 'Protocol ID' don't need updating as they all explicitly list allowed values, and in no case is 0 allowed. Paul Wouters: This is about name for Protocol ID 0 to be seen as "NONE", versus giving it a better name. While I agree with the poster the writing could be improved, this change is not required for implementing the RFC. Thus moved to Held for Document Update where this text can then be improved upon. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Apr 10 17:18:07 2022 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 340473A0E44; Sun, 10 Apr 2022 17:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 qOPPCErq5HBU; Sun, 10 Apr 2022 17:17:45 -0700 (PDT) Received: from rfcpa.amsl.com (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CB03A0E4D; Sun, 10 Apr 2022 17:17:45 -0700 (PDT) Received: by rfcpa.amsl.com (Postfix, from userid 499) id 8AAC7E43A5; Sun, 10 Apr 2022 17:17:44 -0700 (PDT) To: andrew.cagney@gmail.com, ynir.ietf@gmail.com From: RFC Errata System Cc: paul.wouters@aiven.io, iesg@ietf.org, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220411001744.8AAC7E43A5@rfcpa.amsl.com> Date: Sun, 10 Apr 2022 17:17:44 -0700 (PDT) Archived-At: Subject: [IPsec] [Errata Held for Document Update] RFC7634 (5441) 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, 11 Apr 2022 00:17:49 -0000 The following errata report has been held for document update for RFC7634, "ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5441 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Andrew Cagney Date Reported: 2018-07-26 Held by: Paul Wouters (IESG) Section: 4 Original Text ------------- When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the transform substructure of the SA payload as the ENCR (type 1) transform ID. As with other AEAD algorithms, INTEG (type 3) transform substructures MUST NOT be specified, or just one INTEG transform MAY be included with value NONE (0). Corrected Text -------------- When negotiating the ChaCha20-Poly1305 algorithm for use in IKE or IPsec, the value ENCR_CHACHA20_POLY1305 (28) should be used in the transform substructure of the SA payload as the ENCR (type 1) transform ID. As with other transforms that use a fixed-length key, the Key Length attribute MUST NOT be specified. As with other AEAD algorithms, INTEG (type 3) transform substructures MUST NOT be specified, or just one INTEG transform MAY be included with value NONE (0). Notes ----- Reading both RFC7634 and RFC7539 there seems to be a single fixed-length key of 256-bits. Hence, I think https://tools.ietf.org/html/rfc7296#section-3.3.5: o The Key Length attribute MUST NOT be used with transforms that use a fixed-length key. For example, this includes ENCR_DES, ENCR_IDEA,... applies (my intent is to clarify this). Paul Wouters: I agree this should be added in future versions of this document to prevent implementation mistakes. However, not mentioning it here is not an error, so resolving this as Held for Document Update. -------------------------------------- RFC7634 (draft-ietf-ipsecme-chacha20-poly1305-12) -------------------------------------- Title : ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Publication Date : August 2015 Author(s) : Y. Nir Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Apr 10 17:23:53 2022 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 10F193A0E74; Sun, 10 Apr 2022 17:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 rvVD3CWK1tOB; Sun, 10 Apr 2022 17:23:47 -0700 (PDT) Received: from rfcpa.amsl.com (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56423A0E70; Sun, 10 Apr 2022 17:23:47 -0700 (PDT) Received: by rfcpa.amsl.com (Postfix, from userid 499) id 9CD86E43A5; Sun, 10 Apr 2022 17:23:47 -0700 (PDT) To: valery@smyslov.net, tpauly@apple.com, samy.touati@ericsson.com, ramantha@cisco.com From: RFC Errata System Cc: paul.wouters@aiven.io, iesg@ietf.org, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220411002347.9CD86E43A5@rfcpa.amsl.com> Date: Sun, 10 Apr 2022 17:23:47 -0700 (PDT) Archived-At: Subject: [IPsec] [Errata Held for Document Update] RFC8229 (5320) 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, 11 Apr 2022 00:23:52 -0000 The following errata report has been held for document update for RFC8229, "TCP Encapsulation of IKE and IPsec Packets". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5320 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Valery Smyslov Date Reported: 2018-04-09 Held by: Paul Wouters (IESG) Section: GLOBAL Original Text ------------- Corrected Text -------------- TCP provides reliable transport, so there is no need for applications to deal with retransmissions. Moreover, sending retransmissions by IKE in case of TCP on congested networks could further increase congestion and degrade performance. For this reason IKE initiators SHOULD NOT retransmit requests if they are sent over TCP. However, both IKE initiators and responders MUST correctly handle retransmitted messages received over TCP, but responders SHOULD NOT resend response messages in this case. If IKE initiators still choose to retransmit requests over TCP, then the retransmission policy SHOULD be less aggressive than it would have been in case of UDP. Notes ----- While Section 12.2 discusses some implications that TCP transport could have on ESP protocol, the IKE retransmission behavior, described in Section 2.1 of RFC7296, is not redefined by this RFC. This is an oversight and some recommendations for implementers should have been given. The suggested text should be placed in a new section, presumably between sections 8 and 9. Paul Wouters: The reported of this errata is writing a bis draft for this document where this is indeed already clarified. See https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc8229bis-05#section-7.2 Resolving as Held for Document Update -------------------------------------- RFC8229 (draft-ietf-ipsecme-tcp-encaps-10) -------------------------------------- Title : TCP Encapsulation of IKE and IPsec Packets Publication Date : August 2017 Author(s) : T. Pauly, S. Touati, R. Mantha Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Sun Apr 10 17:43:45 2022 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 741503A181C for ; Sun, 10 Apr 2022 17:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io 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 RRsJ9nqZlLrQ for ; Sun, 10 Apr 2022 17:43:24 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 A0F863A1845 for ; Sun, 10 Apr 2022 17:43:24 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id bu29so24013874lfb.0 for ; Sun, 10 Apr 2022 17:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ReV+RczkvtwwuwMSaD2bjssIrs+nsD9sAE/xozYS/FA=; b=fuiRvzAGwoO22COMmqZ4AxWzQfLwCquO2FWpjP294wMPWj9h3bJrXACbpiDJiF54X0 V2zI6cKfSsIWWliTqLXiNLp60jgIIsCN3a8uV1dY8i5FcAaKpAq+BbL8OO15CVFN3vlQ kezEuAVhK20EHfBemoh7wHTVDSnBAxjneHR3I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ReV+RczkvtwwuwMSaD2bjssIrs+nsD9sAE/xozYS/FA=; b=COY5khkBO5cwzPTpbsOY6QhLLzrHeOZ8YTKuSWmmW7DSeO6QIHCN18NdbCsMTfLjxJ I8FV3vhJlfQK96rBs973UIEhZoYOUdBJcIRFBs/Npd5lK5m8e+mFaFtA1xQE7Jem/4Pl OGZTIFRkeoJKP0phpWoA8HmMGE9trIv3uKWF+IPojLebxfponpmUqju6+blQGO1jeEXG lzJfbkRhi3svt4qeMbSYgZzcgMBpPiYdODr8VemJzT1kN61LlgRYn0JH3Z4yc8ebZNM4 ByO/DeaWAphkbc5ku5sELOGVUxh36Knz0pBuUkhgxp047eBhQIRnFYIIAjXEhgR9hkaj f7/Q== X-Gm-Message-State: AOAM530XGvLgOPVZyeAyL5cZPfk6lJDl7VacUlbh0fWTNq9a5a0AW3v2 tzo0Z0PE11dPKiuDgNeMcD3sNrnJPPciNstU4N82Vw== X-Google-Smtp-Source: ABdhPJwyBGkQHhCNpbmPn9HkB2epNJItyABceJXWHk5rDbW0N5IvpXnoyDV/hq9F0DjptU4Wbo9E/z964JvfUolO2Vs= X-Received: by 2002:ac2:5581:0:b0:44a:4cbf:ed93 with SMTP id v1-20020ac25581000000b0044a4cbfed93mr20028289lfg.432.1649637802004; Sun, 10 Apr 2022 17:43:22 -0700 (PDT) MIME-Version: 1.0 References: <25150.7072.594905.131689@fireball.acr.fi> In-Reply-To: <25150.7072.594905.131689@fireball.acr.fi> From: Paul Wouters Date: Sun, 10 Apr 2022 20:43:11 -0400 Message-ID: To: Tero Kivinen , "ipsec@ietf.org WG" Cc: sec-ads@ietf.org Content-Type: multipart/alternative; boundary="00000000000032711b05dc563b28" Archived-At: Subject: Re: [IPsec] IPsec RFC Errata 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, 11 Apr 2022 00:43:43 -0000 --00000000000032711b05dc563b28 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 25, 2022 at 3:44 PM Tero Kivinen wrote: [...] Thanks for your feedback Tero. I have resolved all the errata that were mentioned and agreed in our discussions. > https://www.rfc-editor.org/errata/eid6339 > > > > There are two issues here. One is a bad test vector. I think they > > are likely right, but have no easy way to verify this. > > The second issue is about clarifying endianness. This should prob > > be split into a seperate errata and then approved ? > > No idea about this one. > I have split this errata into two to separate the issues, but also left them in Reported state. This means that for IPsec, we currently only have 3 open errata's left: https://www.rfc-editor.org/errata/eid6339 A bad test vector that we need to verify https://www.rfc-editor.org/errata/eid6931 The endianness issue originally included in 6339 https://www.rfc-editor.org/errata/eid4709 ASN.1 proposed fixes for RFC 4301 If anyone can help with these, please speak up :) Paul --00000000000032711b05dc563b28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Mar 25, 2022 at 3:44 PM Tero Kivi= nen <kivinen@iki.fi> wrote:

[...]

Thanks for your feedback Tero. I have resolved all t= he errata that were mentioned and agreed in our discussions.

> https://www.rfc-editor.org/errata/eid6339
>
> There are two issues here. One is a bad test vector. I think they
> are likely right, but have no easy way to verify this.
> The second issue is about clarifying endianness. This should prob
> be split into a seperate errata and then approved ?

No idea about this one.

I have split th= is errata into two to separate the issues, but also left them in Reported s= tate.

This means that for IPsec, we currently only= have 3 open errata's left:


A bad test vector that we need to verify

https://www.rfc-editor.org/errata/eid6931
=

The e= ndianness issue originally included in 6339

https://www.rfc-editor.org/errata/eid4709

ASN.1 proposed fixes for RFC 4301
<= div>
If anyone can help with these, please speak up :)
<= div>
Paul

--00000000000032711b05dc563b28--