IP Security Maintenane and Extensions (IPsecME) WG

IETF 109 - Tuesday November 17th, 2020

Agenda

Document Status

(Chairs), 5 min

ipv6-ipv6 in IETF LC (ends 01/12/2020) other in progress: * g-ikev2 * ikev2-multiple-ke * hopps-ipsecme-ipfs * labeled-ipsec

Valery:intermediate is ready for WGLC Paul: made some interop testings

Work Items

Labeled IPsec update

Paul Wouters (5 min) https://datatracker.ietf.org/doc/draft-ietf-ipsecme-labeled-ipsec/

minor fix in the security consideration. implemented in LibreSwann no interop as no implementation has implemented it

Tero: Which registry ? This is a traffic selector. Paul can proceed to the request. None in the room has read the doc.

IP-TFS Update

Christian Hopps (10 min) https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/

two updates with clarifications * an ESP payload has been assigned. * zero conf has been removed. * congestion control: time could be derived from sequence number, so the mechanism has been changed to a more conventionnal way (cf TCP)

Transport review. David Black is ready to move this forward. Yoav: The review is performed by Joe Touch and the review is not finished.

code is expected to be relased by next month.

Tero: will read the doc to evaluate if the doc is ready. No need for early allocation.

Ben: An IP number allocation requires Standard or IESG. Can be renewed by the chairs even if we are slow. The need is only if it is being used outisde IPsec. Tero: the people who would speak to using this for non-ipsec usage aren't in the room Christian: exactly, so just doing an ESP payload type is most expedient. Tero: if it gets to the IESG and they complain, then we can actually request the protocol number at that time, as the backup plan.

YANG Model for IP-TFS

Christian Hopps (5 min) https://datatracker.ietf.org/doc/draft-fedyk-ipsecme-yang-iptfs/

augmenting the IPsec Yang model i2nsf-sdn-ipsec-flow-protection IPsec counter were added in the IKE model Looking for WG adoption Tero will start a call for adoption. Tero will check IP-TFS draft (previous presentation) to see about starting WG Last Call. Will wait fro TSV-Area review to complete in any case.

New items

Beyond 64KB limit of IKEv2 Payload

Valery Smyslov (10 min) https://datatracker.ietf.org/doc/draft-tjhai-ikev2-beyond-64k-limit/

The size of the payload is limited ot 64 Kb but new PQ algo are likely to be larger - 256 Kb. Likely to reach this limit in PQ world - public key, signature, certificate

Not a generic mechanism to have ANY payload larger than 64 KB.

Simple approach, IKE state is not changed, allow data size to be diferent in different direction. but some payload are handled differently and may prevent the use of UDP.

Adoption ? Tero: This is worth being addressed. Indication with one bit specifying this is not the last fragment.

Yoav: This worth being done. Previous need for large payload. Why not changing the Payload format ?

Valery: limit the changes but can be discussed. Currenlty it is only one use case, and IKEv2 can also be used by IoT.

Tero: Maybe not in the charter but part of the PQ. More discussion may be needed on the list.

IKEv2 Configuration for Encrypted DNS

Valery Smyslov (10 min) https://datatracker.ietf.org/doc/draft-btw-add-ipsecme-ike/

New version with new attribute format: {IPversion, DoX} in which port number is added and scope has been removed. All encrypted DNS are supposed equivalent.

DoH specific parameters: DoH URI

Tommy: Document has improved. Wait for ADD WG to have a clearer path.

The trust is different with IKEv2 and DHCP.

Paul: concerned there is not certificate to enable the bootstrap.

Tiru: DoH may be hosted on private IP address and get a public certificate.

Ben: a recharter will be needed.

Tero: milestone proposal and charter update to be discussed in the list and whether the WG will take this work.

Revised Cookie Processing in IKEv2

Valery Smyslov (15 min) https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-cookie-revised/

Problem: A network with long delay a cookie may be received at the time a initiator retransmits the IKE_INIT.

[ I have not really understood the scenarios, It seems to me that the cookie is not bound to one exchange ]

It seems that in some cases it ends up in 5% of SA failing.

Yoav questions whether the problem worths being solved given that in bad condition the SA may be hardly useable.

Scott: Would selecting a fresh IKE SPI solve this ?

Valery: network issues lead to misleading errors to the end user as it would suggest a error associated to the certificate.

Ben: this could fits in the minimal modifications, so there is not need to recharter

Performance Enhancements for IPsec

Paul Wouters (20 min) https://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/

IPsec SA can typically implement 1 CPU. The document details how a SA can be spread across multiple CPUs.

Valery: interesting

Tero: Prefer is three times the number of CPUs. If you need a sub-registry QUEUE_INFO probably needs to be standardized.

Yoav: RFC6311 allows to have parallele SAs.

Christian: Does QINFO specifies the priority (e.g., for CPU selection based on load)? Paul: it's up to the implementation what to do with it. Christian: Ok, right, we use something similar in routing (admin tags/coloring) I think leaving opaque is a good idea for similar reasons.

IKEv1 graveyard

Paul Wouters (5 min) https://datatracker.ietf.org/doc/draft-pwouters-ikev1-ipsec-graveyard/

Ben: I think this is maintenance, so no need to recharter. Tero: This will be taken inside the working group, so we will start WG adoption call.

AOB + Open Mic