Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting
Valery Smyslov <smyslov.ietf@gmail.com> Wed, 29 July 2020 06:54 UTC
Return-Path: <smyslov.ietf@gmail.com>
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 B43DF3A0CC5 for <ipsec@ietfa.amsl.com>; Tue, 28 Jul 2020 23:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi8ZbjoyaF5Y for <ipsec@ietfa.amsl.com>; Tue, 28 Jul 2020 23:54:52 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444F23A1049 for <ipsec@ietf.org>; Tue, 28 Jul 2020 23:54:52 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id q4so23870609lji.2 for <ipsec@ietf.org>; Tue, 28 Jul 2020 23:54:52 -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=JcQxKLaYbA8ipdXp/e1A/nV6hrhShnqncw9xKt4jmdQ=; b=Gxjvu9bhLLg9YcQIsQKVGQJGkyocKYVbq5uTTDRPT4IdV59D/mKvxP8nRfSuQtQ+V+ OUYSpDeBw3qSb0XtOhfpJ/ky3xY8HSSryQ9tqScZNyTL0oY6C2xmHj5b9Mf5jg7E+o4G 8kEmReDtnEOavo0UwTJp55w5WI0Qi8zovsEkGWIGvLXrzGhcT0rd/CGt0rJxr7VC9J7m cwmfaON5LG56dtNM2tx9dDG5l18ITLXhzJvBoIkfyuY5tcupO+6jN/igjP/LjqXMulqT FRMD+ANlNz/DW4bLyLowERJLPYqt4bJm0ykqd1ucvt41MPt7+c2sLpLrf/N+qIV3mu5c JYYQ==
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=JcQxKLaYbA8ipdXp/e1A/nV6hrhShnqncw9xKt4jmdQ=; b=tVyVva7ZvCbJWBJV1pz9GGiS3A/osjUYGjqJENGUjFcy/dj2BCF5eWeLO5rJ2JaTFC q8ruQ8EOyrF9vI7ZikfOQoy/ORavOB2j7pnMQYX8Am57Eqb7ml+g/HSWOz3bjEhvP3Hn hQbZ+71P3kJb+2396kEZL1VBDXM5Imu8KSfjysPLdSwdRoGRbB/JXTx3c3eI1Kv2hHyq fW/KLmZY30Uk84spJ+uqHULXD+dv1241Zu1qMNcf71Sd8BiQTwDWBbA3fdanlX87RY4z HnXasyTLv57vfh1jTiIU4ns2W7DsjLlo6VxaZKuhzhQtOjZ6uQIjDXqdbgYUUINto1RC 2VoA==
X-Gm-Message-State: AOAM532mrmMdyc57FapNJHxrpTOpRDrXDU072lTKBIZUZ2cvo8LD0u0l z19pfnGED/41FIy/5jzqEiOkrhZj
X-Google-Smtp-Source: ABdhPJzv3/Zg/zgYIoxdvgyb9WeOOQRG8OD5E72GAv8Hhtdihc6YKNs5VcVbanfATxwMZwmFkPdVZw==
X-Received: by 2002:a2e:6e06:: with SMTP id j6mr5452405ljc.431.1596005688317; Tue, 28 Jul 2020 23:54:48 -0700 (PDT)
Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id j17sm244719lfr.32.2020.07.28.23.54.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jul 2020 23:54:47 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org
References: <24352.9444.775247.214537@fireball.acr.fi>
In-Reply-To: <24352.9444.775247.214537@fireball.acr.fi>
Date: Wed, 29 Jul 2020 09:54:49 +0300
Message-ID: <122101d66575$27287470$75795d50$@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: AQInefrQBTpZenNP/fPozA2vH2E+dah79V5w
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/cZnpILlMqNNe8_RgxUAYYJ0gWkc>
Subject: Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 06:54:56 -0000
Hi Tero, > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan Just for clarification (sorry it wasn't spelled out well at the session) - by "tested" here I meant that these interop tests were performed with us (ELVIS-PLUS), probably more vendors tested between themselves. Regards, Valery. > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Tuesday, July 28, 2020 4:15 PM > To: ipsec@ietf.org > Subject: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting > > Here is preliminary minues from the IETF 108 IPsecME WG meeting. I > copied some discussion about the proposed changes to ESP from Jabber > to here, as I think it was important to record those even when we did > not have time to have comments during the meeting. > > If you have any comments, please send them to me as soon as possible. > ---------------------------------------------------------------------- > # IPsecME IETF 108 > > Time: Tuesday, 28-Jul-2020, at 11:00-12:40 UTC > > ## Agenda: > * 11:00-11:05 - Note Well, technical difficulties and agenda bashing > * 11:05-11:10 - Document status (chairs) > * 11:10-11:25 - draft-smyslov-ipsecme-rfc8229bis (Valery/Tommy) > * 11:25-11:35 - draft-btw-add-ipsecme-ike-00 (Valery) > * 11:35-11:45 - draft-smyslov-ipsecme-ikev2-auth-announce (Valery) > * 11:45-12:00 - Proposed improvements to ESP (Michael Rossberg) > * 12:00-12:15 - IPTFS (Christian Hopps) > * 12:15-12:30 - YANG model for IPTFS (Christian Hopps) > * 12:30-12:40 - AOB + Open Mic > > ### Note Well, technical difficulties and agenda bashing > *Chairs* (5min) > > No Edits > > ### Document status > *chairs* (5min) > > *-implicit-Iv published as RFC8750 > *-qr-ikev2 published as RFC8784 > > *-ipv6-ipv4-codes publication requested > > ### draft-smyslov-ipsecme-rfc8229bis (TCP encap of IKE/IPsec) > *Valery/Tommy* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-rfc8229bis-00 > > Paul Wouters: What are the kernel implications? And does this allow for smaller IPsec/ESP Packets? > Valery: Text is a bit short, TCP stream packets will have same class > Paul: What Interop testing has been done? > Valery: Tested with Apple, Cisco, libreswan > > Piannissimo Hum for who has read the draft > > Paul: Good idea to adopt, found issues that would be good to incorporate in draft > > Yoav: Will take to list if we need an update to 8229 and if this is the right starting point. > > ### draft-btw-add-ipsecme-ike-00 (IKEv2 config for Encrypted DNS) > *Valery* (10min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ikev2-configuration-for- > encrypted-dns-00 > > Paul: What to do outside of VPN tunnel seems out of scope? (regarding Scope bit) > > Valery: Still an interesting subject > > Ben (AD): (missed first point Belongs in ADD?) Slide with attribute format, for DoH, need to provide URI > template > > Valery: Presentation also requested in ADD, but didn't have room in agenda. Re: URI, will be covered in DoH > clarifications (?) > > Ben: When DoQ arrives may need additional work > > Tero: Add configuration attributes, less internal strucutre, more higher level structure > > Yoav (participant): Missing motivation from draft Moving towards encrypted world, don't want to force > people to keep insecure DNS just for legacy IKEv2 server > > Valery: That is one of the motivations; users won't see this, but it is useful. > > Tirumaleswar Reddy: URL can be discovered another way > > Benedict Wong: My understanding is that in some cases we need a hostname to do validation of the DoT > server > > Tirumaleswar: This only supports PKI-based verification, so we can verify based on sent certificate. > > Yoav: Calling for adoption? > > Valery: ADD Primary target for adoption, ipsecme is just informational, if there is interest it could persist in > this WG, but not yet. > > Tirumaleswar: Couple more revisions necessary, extension to IKE, want to make sure both working groups are > aware of work > > Ben (AD): If ipsecme was concerned by the work, or on the other hand thinks it makes sense, it's good > information for ADD to have > > ### draft-smyslov-ipsecme-ikev2-auth-announce > *Valery* (10min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-announcing-supported- > authentication-methods-in-ikev2-00 > > Paul: Good idea, unclear where complexity might be, in the past migration between methods (null -> > something else) needed a ppk hack - sending two auth payloads > > Tero (participant): Could have one part negotiate the algorithm, and the second part to negotiate the > algorithm ids for CAs in the certreq > > Yoav: will take a call for adoption to the list > > ### Proposed improvements to ESP > *Michael Rossberg* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp- > 01 > > Yoav (?): Discussion happening on list and in jabber. Informational would be wrong, changes packet on wire, > so experimental or standards track if anything > > Summary of questions and comments from the jabber: > > * Yoav: Some firewalls would be very upset about this packet format, because it looks like every packet is > retransmission. > * Paul: so flip sender/window id with sequence number > * Chopps: andeven put the higher order after lower order so stays exactly the same as before > * Scott Fluhrer: In addition, each sending id/window id has its own replay window, does that mean that the > receiver needs to track 4 billion antireplay windows? > * Scott: Also, it wouldn't be secure with CBC > * Paul: It drops all non-AEAD, which we should do anyways > * Scott: You also lose the multitarget protection with GCM by not including the 32 bits of key-derived nonce > * chopps: The sender id is really a mcast thing, so it reduces to 64k > * Scott: Does the receiver need to track a antireplay window for each multicast sender? > * Yaov: Yes > * Scott: I can't see how that can work on a decryptor that can't dynamically allocate memory > * Bob Moskowitz: Would need a change to robust header compression so that smaller seq# for constrained > links? > * Valery: This proposal lacks enough generality to replace ESP - it considers very small set of ciphers and use > cases > * Paul: and we might as well throw in a discussion of implicit IV if we are updating ESP to v4 > * Yoav: @Valery: doesn't it use all the ciphers that people care about now? Consider that TLS 1.3 has about > two ciphers (plus another 1 for IOT). > * Valery: In addition, many things it aims for can be achieved using ESP. Even replay protection for multicast > (with some limitations). > * Steffen Klassert: Get rid of the trailer would be nice from implementation point of view > * Valery: @yoav, No, it doesn't work with CBC at all. Moreover, if IV is somehow structured, it won't work too > * Yoav: TLS 1.3 doesn't support CBC either. > * Valery: I understand, but what if tomorrow a new cipher mode appear that is superior to GCM and will > require some special form of IV? The problem is that this design requires IV to be in a particular form. If cipher > requires other form, it'll fail > > Tero: Not in charter, this is a big change. See if it is a good idea first before taking to much time discussing > and writing > > ### IPTFS -- [draft-ietf-ipsecme-iptfs-01](https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-01) > *Christian Hopps* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-ip-traffic-flow-security-00 > > Yoav: Hasn't gotten much review, WGLC is one way, but don't know if it is the best way. Requesting transport > area early may be a good way too. > > Tero: Might be hard to get another protocol number. > > Lou: Getting a protocol number shouldn't be a big deal; many can be deprecated. > > Ben: Please fill out the official early-allocation form request. > > Agreed on sending this out for transport area early review. > > ### YANG model for IPTFS -- [draft-fedyk-ipsecme-yang-iptfs-00](https://tools.ietf.org/html/draft-fedyk- > ipsecme-yang-iptfs-00) > *Christian Hopps* (15min) > > Slides link: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-yang-model-for-ip-traffic-flow- > security-00 > > Tero: SDN YANG models generally work in two mode, either IKE-less, where it configures IPsec SAs, or in IKE > mode where it does not touch IPsec SAs, as IKE configures them, so they wanted to keep the configuration > clear which parts they are configuring. > > Christian: Also operational state, even if not configured via YANG > > Tero: If we could consolidate on a single YANG model, that would be ideal (such as I2NFS) > > Yoav: Per chat, would benefit from a YANG Dr. review > > Lou: Would benefit from another review, per datatracker, latest draft needs another review. > > ### AOB + Open Mic > *all* (10min) > > Paul: Labeled IPsec still in review. Graveyard draft still in limbo > > Tero: Take to list; a few of these can go to WGLC, but should check with AD first. > > Tero: I think we need to have interm meeting about the ESP. We cut the discussion out from here, as it would > have taken the rest of the time, but we should have separate interm just for it. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec
- [IPsec] Preliminary minutes from the IETF 108 IPs… Tero Kivinen
- Re: [IPsec] Preliminary minutes from the IETF 108… Yoav Nir
- Re: [IPsec] Preliminary minutes from the IETF 108… Valery Smyslov
- Re: [IPsec] Preliminary minutes from the IETF 108… mohamed.boucadair
- Re: [IPsec] Preliminary minutes from the IETF 108… Benjamin Kaduk