[IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

Tero Kivinen <kivinen@iki.fi> Tue, 28 July 2020 13:16 UTC

Return-Path: <kivinen@iki.fi>
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 0F7CD3A0C13 for <ipsec@ietfa.amsl.com>; Tue, 28 Jul 2020 06:16:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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=iki.fi
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 eecrbJ0BenaT for <ipsec@ietfa.amsl.com>; Tue, 28 Jul 2020 06:16:04 -0700 (PDT)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883C83A0C6F for <ipsec@ietf.org>; Tue, 28 Jul 2020 06:15:19 -0700 (PDT)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 3C6CE1B00592 for <ipsec@ietf.org>; Tue, 28 Jul 2020 16:15:17 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=92ZdcP6MpH2R3k2BoZqKVx4szZs8yJtKJaCPULOfBrM=; b=QjQ2mzpkuF8KZw6DF/yINqHvlE8vmtegeXBQqv2/E83Xp+NXnN0C0xfnRGJ0F/1i7VATSe IN9V85AQW2303J7r8PkphsbcbxkiAizj9MrJEFALXay+LlfWW+ty5fs/WZ5p3tVWZgSfvv qfPjWVgkVgJebOEBJ+J8KR7SAQZcSBFD0Fn0oDEEDwjn8ulBBcJbA1Vrc4iM7p813lVMUt FfUwh/KOF/hpZnkhQPrUPd2A/NxD6Nfil+RecOa9JCUMo32/Xdu/uo3cKJK81k67Bx/wBs LdUW0Z0gavQwDIH/5XsibKEGiG2WXZ2mldxAbqZ+9i/Cy/gcZV80Lf1wMem5FA==
Received: by fireball.acr.fi (Postfix, from userid 15204) id CAE5625C0E71; Tue, 28 Jul 2020 16:15:16 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24352.9444.775247.214537@fireball.acr.fi>
Date: Tue, 28 Jul 2020 16:15:16 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 6 min
X-Total-Time: 15 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595942117; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=92ZdcP6MpH2R3k2BoZqKVx4szZs8yJtKJaCPULOfBrM=; b=Nn3ikBu8oWlr9AdDUs1bH3l1Q2veXSiLx00pOqq9VCbgg3qin+BDShLGwnj2w5dAp6WtJQ BPkXEvmTnf82UKoJh1TzUsFEPrrga69nKtDsPLN9/uW7h1NKcdKSDborqYpTaFh9h3+1Fv YFRyaflKPrDmaljjIpOuSFaHiR/06SXFb5YZVUXuQTRy66qc6k/woIfqYtre5wJ+Jka/E8 v8G4bpxFEbVNGc19ouiSXaxxrgfWVCH2OZ1yVd09LLYWyWiRDmX0uPBVi30gTLxEkb4ELB kWpv2AuIkGzWOHkR5tCFFAbsaBMceR7P5Tf+/nk2RVEgncUaZUmOv+r4gnXLXg==
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1595942117; a=rsa-sha256; cv=none; b=VI85Rgd9dQC8J60T0aCtfQjmJtw9EgTxHVEsttcVHHZz3z1iZcXJL71TJxpsdn3fDa46k4 xSKJqJWn1SNMQVvjQ+mTUH5BnfdL8wBshyCLFMlYRzAzPD0RyFErA0toyh9dHlXareoBVD Wu3FSbQ1YVrC7SFUDsIzfzXavq2ZaJnRsZF+0pxPY3Ehgd5m/Z3hTP/cGzG/2LWS8gdZqi ivhxNrkLOa4Rki8GZvNyZDrnj2U7Dw0ii113QIUokULC60kbqFXhh62V+lguwNp8/v6Fue nITZgMNjr5c4H5g4Z40IAnPsEajDPqPU+PP/6OgMxhTcpzGDkTpe0XiDcVUAxQ==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/EgL6uYombcK-ltdXqLxXSX3fBFQ>
Subject: [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: Tue, 28 Jul 2020 13:16:08 -0000

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