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