Re: [I2nsf] [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
tom petch <daedulus@btconnect.com> Sat, 07 November 2020 12:16 UTC
Return-Path: <daedulus@btconnect.com>
X-Original-To: i2nsf@ietfa.amsl.com
Delivered-To: i2nsf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCC03A00D8; Sat, 7 Nov 2020 04:16:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 3uORm1IqESYq; Sat, 7 Nov 2020 04:16:24 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2132.outbound.protection.outlook.com [40.107.22.132]) (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 4CD613A00D2; Sat, 7 Nov 2020 04:16:22 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XF4HBIGvoPbKAkrWmqQo3uElNPbhpPiH5IAzCGAokPl90em62OyDSv69/bNODWT9dHzlu0Lp1OcAu2ipG58W2AVFOeHWvM/45v58VPl6EVsxRhbr4jX4wkz50A+3RoYSAS/xPPWyMDPoNmn3P56o3D/gTbjcr1ajSrfF/v0XQ+ateh9LEYX0qQODXJ324ombIICWS1h6IyOhzQAKQ7IyZl+CYv82wXzL44OZ6GGBzgYClRLLGZ4NGjjIcPaflLvzPFWbeeCLpb9g5lCWDXC1XWc+NWBjPrcSBLK4A+5LYpDAzm+M5CZbuw9BI0XTKLjLwZuYbwZ5XwfNL0X0Zy+Hqw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYgRHXcVK5vBmFvb24Lnv7uNWkDp1ibHw53XQxR5S3o=; b=MX4cldf2AVSSjQ7++6OuszPfPj1kOGVC+0J53mTvR1+r1Np3cWjw7/x8FOcGcJ8kS6HBAjboWgEGmoA6nUavFK25+BMDr8b8Z5uKXIBjWIn2ERm3sDYAqe2lN0FjHbN0dDyBE6c1N7KHDSaSKKlvXCbHNW6NnCnWM2e8AbPzhXvnXNoV8H6RNgjWb8e3kGL6/aLpeOYykgyH80hemwdwWZ1wimbiWQtc0/3NC7NGzznCx+gjIDwpt8hdj9W08yIPBPRtCohRWQMOlMY8VXYdEozPL0qHNbcrURk27IrUAwlO0wp6FwsYypbd4psGpwTunEZJhD+ga5YOblnvIAYuMQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYgRHXcVK5vBmFvb24Lnv7uNWkDp1ibHw53XQxR5S3o=; b=lUkWu6CQsIQV5Byd6GWNVll4bk0YLlPMtLmAFoVsDvMLYtQdd6D+Nk1J7dtr3l8VQDLejaBppe5sk2D/2zbE7mXhqs0nsrWewubw46BOzkckcOlrR6MCkMINJQ/+BPXfVBdd6RO91iziCYoEakZ5dKAumWKVDYcapiYVcK00Jd8=
Authentication-Results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=btconnect.com;
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB6382.eurprd07.prod.outlook.com (2603:10a6:800:137::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Sat, 7 Nov 2020 12:16:20 +0000
Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3564.013; Sat, 7 Nov 2020 12:16:20 +0000
To: Valery Smyslov <smyslov.ietf@gmail.com>
References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <EE5AB669-73BB-4517-A6F4-23B7807FB36E@um.es> <5F9815D1.9010303@btconnect.com> <DDE550B1-9A9E-4954-B6F9-C0A33ECE1275@um.es> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> <5FA14709.6080903@btconnect.com> <009901d6b388$fdb303a0$f9190ae0$@gmail.com>
Cc: 'Fernando Pereniguez-Garcia' <fernando.pereniguez@cud.upct.es>, i2nsf@ietf.org, 'Gabriel Lopez' <gabilm@um.es>, ipsec@ietf.org, last-call@ietf.org, 'Rafa Marin-Lopez' <rafa@um.es>
From: tom petch <daedulus@btconnect.com>
Message-ID: <5FA6900F.7060702@btconnect.com>
Date: Sat, 07 Nov 2020 12:16:15 +0000
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
In-Reply-To: <009901d6b388$fdb303a0$f9190ae0$@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [86.146.121.140]
X-ClientProxiedBy: LNXP123CA0006.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::18) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.1.65] (86.146.121.140) by LNXP123CA0006.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3541.21 via Frontend Transport; Sat, 7 Nov 2020 12:16:19 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e5882f4c-be03-49b0-99f7-08d88316ef21
X-MS-TrafficTypeDiagnostic: VI1PR07MB6382:
X-Microsoft-Antispam-PRVS: <VI1PR07MB6382DB1FC846D3093E0DC1C2C6EC0@VI1PR07MB6382.eurprd07.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 3KQmrTE7DXrzfmG7WMUk0dQp9jipPSS9lfr4nMlSVvYlSbf1z24gcMtG2Zt5QNmm6FztcaTqwda+/nKXjDBbnH7TJCQvsyTikXRIPz76fDLpFjz+dhquK9eGAHkQLq6K8RMCNqLjjtbxYQC9NudMa5wXu8XS83jbNC7LE7OMwdhP+YCbXrjHXH3OzVMBS++JgK6LnRDsUZ0esm7bNzxLdWjqKopofMRXQ51NSBXQPnDxZSqfDISRjrwCExr5mXLLkidR7x5JPAaUY6iRv+/hiFT7TERWpblvtaUYjfNxzxcxB54Merm/as7N6Q8G6cWKJsP+Vzyt8caH4AGKoSfANg==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(39860400002)(366004)(346002)(396003)(16576012)(26005)(66476007)(86362001)(53546011)(2906002)(6916009)(6666004)(316002)(8676002)(186003)(36756003)(956004)(54906003)(66556008)(15650500001)(4326008)(2616005)(83380400001)(52116002)(33656002)(478600001)(8936002)(5660300002)(6486002)(87266011)(16526019)(66946007); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData: 9AIPkIFOeU2DBWXfN9Y0zSic+8OaStEXmkParJBGSegq9K3bXi+Idtse79hs6/OrfeUWOKd6a8HFOdSat7hfqYcV0r7u5p3aVI0rTA33aK5Hpm1u8LvdRXb9RvwQLqUFgqVjq9/KudqtRPUqV/GmP8HRsq+rkXhwSJ6Q7epGAFmF8cNlVMRlWJbqNJ0VArDIpJ1CqmW96AJ3V07TocwKIj6+N/lIhu3kFstxveYxH0uX0fqXgoABfvG/S+q0SV3WfvSHpP1sNKfA5BwSBHCFoWipJYRImfTQndRv/IfiN571cCJQBzVzOZWBJpP42Hifv22z+zWbEpm4GPd/z26hDSHPzcpu3dc98egMOTDESqH917QgvmxCYYmsYTqp/1/t9IXQW2aVmiAgfDO1F+Yc5+bXbLmyv1IlDNLarYaBK1xUqPZ1CY/m/tBalMYqLs5botEnbGrXSgxqgGDh9dfVPDQvrm6WX+O4BlpIQaPPlOlTZe92xAZLim3IRe7ihH81S7QFiIuSxzpo8e39M5JCHp5e59hqxU/6Ucq2V44Mnyx4Kc6FcjpLlZz64Nhw7qXjeEk99wF53KuTz52Bm8q1WuFNb42/gRp+URa/h6WQOXod/4LV+aDcxwRJjIMNZmJ0V+QC7KL1MYygmmeHuxgtVA==
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e5882f4c-be03-49b0-99f7-08d88316ef21
X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2020 12:16:20.2976 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 9ITD49qMt0rKSNAi+38mQHZqxU4zq5B4SokSDd+7ciCCQUoV7uFbB68O0tRcAjpMKnFd9ZnPPH1u917VIUdMZg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6382
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2nsf/6nR-N4CkTHmET1DaFvm7AFF-fjE>
Subject: Re: [I2nsf] [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt
X-BeenThere: i2nsf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "*I2NSF: Interface to Network Security Functions mailing list*" <i2nsf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2nsf/>
List-Post: <mailto:i2nsf@ietf.org>
List-Help: <mailto:i2nsf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2nsf>, <mailto:i2nsf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Nov 2020 12:16:27 -0000
On 05/11/2020 15:33, Valery Smyslov wrote: > Hi Tom, > >>> we discussed with the chairs the usefulness of adding "Recommended/Not >>> recommended" column >>> (as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok >>> and I was one who >>> of those who initially suggested this. However, Tero made a very good point >>> that >>> IANA doesn't have any public history. So, in the ipsecme WG another approach >>> was taken - we have RFCs that say which algorithms are recommended/not >>> recommended >>> for ESP and for IKEv2 and these RFCs are updated periodically. >>> >>>> Thanks for getting back to me. What is missing from the IANA registry >>>> is the guidance as to the status of the algorithm, how highly it is >>>> recommended or not. This I-D tells people to go to RFC8247 and the IANA >>>> Registry for advice; RFC8247 gives that advice; the IANA web page does >>> not. >>> >>> As Tero said, the IANA web page references current RFCs (8221 & 8247 at the >>> moment) >>> that list recommended algorithms. Just one more level of indirection. All >>> algorithms that are not listed >>> in these RFC are treated as "not recommended" by default, including newly >>> added algorithms. >>> >>>> And RFC8247 specifies which algorithm are AEAD, the web page does not. >>>> The YANG module behaves differently depending on whether or not the >>>> algorithm is AEAD; YANG implementors need to know, having this >>>> information on the web page would make it easier for YANG implementors. >>> >>> Is is a problem to open corresponding RFC or I-D? Or do you want to say that >>> >>> YANG implementers don't need any other information about algorithms >>> except whether it's AEAD and whether it's recommended? >> >> Valery >> >> The problem I see is where to direct readers of the i2nsf-sdn to for >> more information, about which algorithms are recommended, or not, and, a >> secondary consideration, whether they are AEAD or not, since the latter >> affects the YANG module. The I-D has lots of references to RFC7296 and >> that RFC is very clear - for up-to-date information go to IANA. The RFC >> that update RFC7296 do not appear to update that advice. And the i2nsf >> I-D also contains references to IANA often alongside a reference to an >> RFC. You seem to be saying that IANA is only a good reference if it >> points to an RFC that says so which may not match the expectations of >> users (particularly those who are familiar with the approach of the TLS >> WG). If they are pointed to IANA they may well expect IANA to be the >> best source of information but you seem to be saying that the WG decided >> not to support that, rather expecting people to read the RFC. If IANA >> said 'use this to find the RFC but do not otherwise trust this >> information' that would be fine, well in a manner of speaking:-) >> >> So, question. What references should draft i2nsf-sdn point readers to >> for up-to-date information on algorithms (assuming that they do not >> track the IETF WG that updates information on IKEv2 ie like me)? >> Currently that is both a reference to the IANA registry and to an RFC; >> is that your best advice? > > I believe a reference to IANA suffices. Note, that IANA algorithms registries have > notes referencing RFCs with up-to-date information about algorithms status. > E.g. for encryption algorithms the following note appears in the registry: > > Note > To find out requirement levels for encryption algorithms for > ESP, see [RFC8221]. For IKEv2, see [RFC8247]. > >> Were I an author of this I-D, as opposed to a reader thereof, then based >> on what you say I would remove references to the IANA website or at >> least qualify them with some statement that they need to check the RFC >> for current information! > > IANA website has already contained this statement and references the most recent > RFCs for IKEv2 and for ESP containing algorithms requirement levels. > >> What would you advise? > > As I've already said, I believe sole reference to IANA webpage is enough > for careful reader, because IANA has notes mentioned above with > references to up-to-date RFCs describing current algorithms status. > However, I think that referencing both RFCs and IANA in the I-D won't hurt anyway. > > Whether algorithms are AEAD or not is different thing. Currently this information > is missing on the IANA webpage, so one must look into the each algorithm > specification to learn it... Valery Thank you for your thoughts on this. As you will know, the IESG are now commenting on this I-D and my experience is that, once that has started, then that takes over the discussion so having got the topic aired, albeit not necessarily to a conclusion incorporated in the I-D, I will leave it up to the IESG to decide what should or should not be included in the YANG module. I will keep the outcome of this discussion in my mind as and when the topic comes up again. As you may gather, I follow the TLS WG and so am familiar with the approach that it has taken (likewise that of SSH) but do not track the work on IKEv2 - I did not even know which WG was responsible for it:-( Tom Petch > Regards, > Valery. > >> Tom Petch >> >>> >>> Regards, >>> Valery Smyslov. >>> >>>> And RFC8247 specifies IoT, which I do not think is yet a consideration >>> here. >>>> >>>> As I said, we are currently ok but as new algorithms get added, by >>>> Expert Review, then that information is needed and may not be available >>>> as there is no requirement for the Expert Reviewer to make it available. >>>> >>>> As I said to Roman, the TLS WG found that they needed to add extra >>>> columns to their web pages of algorithms. Different columns (e.g. DTLS >>>> not AEAD) but I think that the situation is otherwise identical so I am >>>> anticipating that in a year or two you will see what I mean:-). In >>>> passing, the TLS WG determine by consensus what the status is for a new >>>> algorithm but the Expert Reviewer makes it available via the web site >>>> whether or not it is in an RFC. >>>> >>>> I take your point about duplicating data - no relational databases here! >>>> - but the answer is to specify which is authoritative and for me that >>>> should be the IANA pages as it is for many assignments in the context of >>>> YANG and before that SMI going back decades. >>>> >>>> Tom Petch >>>> > > . >
- [I2nsf] Fwd: New Version Notification for draft-i… Rafa Marin-Lopez
- Re: [I2nsf] [Last-Call] Fwd: New Version Notifica… tom petch
- Re: [I2nsf] Fwd: [Last-Call] New Version Notifica… Rafa Marin-Lopez
- Re: [I2nsf] Fwd: [Last-Call] New Version Notifica… tom petch
- Re: [I2nsf] [Last-Call] New Version Notification … Rafa Marin-Lopez
- Re: [I2nsf] [Last-Call] New Version Notification … tom petch
- Re: [I2nsf] [Last-Call] New Version Notification … tom petch
- Re: [I2nsf] [Last-Call] New Version Notification … Roman Danyliw
- Re: [I2nsf] [Last-Call] New Version Notification … tom petch
- Re: [I2nsf] [Last-Call] New Version Notification … Rafa Marin-Lopez
- Re: [I2nsf] [Last-Call] New Version Notification … Roman Danyliw
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Tero Kivinen
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Roman Danyliw
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… tom petch
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Valery Smyslov
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Yoav Nir
- Re: [I2nsf] [Last-Call] New Version Notification … tom petch
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Paul Wouters
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Tero Kivinen
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… tom petch
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Tero Kivinen
- Re: [I2nsf] [Last-Call] New Version Notification … tom petch
- Re: [I2nsf] [Last-Call] New Version Notification … Rafa Marin-Lopez
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… Valery Smyslov
- Re: [I2nsf] [Last-Call] New Version Notification … tom petch
- Re: [I2nsf] [IPsec] [Last-Call] New Version Notif… tom petch
- Re: [I2nsf] [Last-Call] New Version Notification … Benjamin Kaduk
- Re: [I2nsf] [Last-Call] New Version Notification … Rafa Marin-Lopez