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

[[e-mail]]

Hi Yoav, Ben, all,

==
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 (?)
==

Valery was referring to https://tools.ietf.org/html/draft-btw-add-rfc8484-clarification-02#section-6.1 where we define a well-known uri that will be used to retrieve the uri templates directly from the discovered Encrypted server. We that approach, we don't need to supply the URI template in the IKE attribute.

Cheers,
Med

De : IPsec [mailto:[e-mail]] De la part de Yoav Nir
Envoyé : mardi 28 juillet 2020 22:22
À : Tero Kivinen <[e-mail]>
Cc : [e-mail]
Objet : Re: [IPsec] Preliminary minutes from the IETF 108 IPsecME WG Meeting

Hi.

I uploaded a PDF version to the meeting materials. Also added a list of action items for the chairs.  Comments are welcome on that part as well.

https://www.ietf.org/proceedings/108/minutes/minutes-108-ipsecme-00

Yoav


On 28 Jul 2020, at 16:15, Tero Kivinen <[e-mail]<mailto:[e-mail]>> wrote:

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.
--
[e-mail]<mailto:[e-mail]>

_______________________________________________
IPsec mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ipsec


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.