# IP Security Maintenance and Extensions (IPsecME) WG.   {#ip-security-maintenance-and-extensions-ipsecme-wg}

IETF 118 - Thursday November 9th, 2023 13:00-14:30 CET  
https://meetings.conf.meetecho.com/ietf118/?group=ipsecme&short=&item=1

## Agenda   {#agenda}

*   Note Well, technical difficulties and agenda bashing - Chairs (5
    min)
*   Document Status - Chairs (5 min)
    *   Adoption calls - Chairs (5 min)
        *   draft-liu-ipsecme-ikev2-mtu-dect
        *   draft-mglt-ipsecme-dscp-np
        *   draft-mglt-ipsecme-diet-esp
        *   draft-mglt-ipsecme-ikev2-diet-esp-extension
        *   draft-smyslov-ipsecme-ikev2-cookie-revised

*   Other items
    *   Issues with DH with IKEv2 and rekeys - Paul Wouters (15 min)
    *   QR alt update - Valery Smyslov (10 min)
    *   Update of multiple sequence counters - Steffen Klassert (10 min)
    *   Anti-replay sequence number subspaces - Pierre Pfister (10 min)
    *   Beet mode - Antony Antony (10 min)
    *   Esp trailer adjustment - Wei Pan (5 min)
    *   Delete info - Paul Wouters (5 min)
    *   RISAV update - Yangfei Guo (5 min)

*   AOB + Open Mic (5 min)

## Minutes   {#minutes}

### Document status   {#document-status}

*Chairs*

There has not been any emails about the one document we have in the
WGLC, so please review it and send comments to list.

#### Adoption calls   {#adoption-calls}

*Chairs*

No comments about the drafts, chairs will discuss about them with AD and
issue last call.

### Issues with DH with IKEv2 and rekeys   {#issues-with-dh-with-ikev2-and-rekeys}

*Paul Wouters (PW)*

CHILD DH group != PARENT DH, but on first negotiation gets accepted
anyway.

**Michael Richardson (MCR)** notified initial negotiation should fail if
Child is configured for different values than wanted.  
(want things to fail when configuration is clearly wrong)  
**TK**: DH for IKE is the most important one. The IKE DH group is
usually stronger than the ESP DH, so continue to allow it.  
**PW**: we don't say that anywhere, but if we do a document, we could
say that.  
**TK**: if you really don't want to use DH14 for child, then you really
need to use childless negotiation. But, if it does not support
childless, then at least it breaks immediately.  
**Daniel**:   
**Scott**: a new notify to be explicit about our PFS policy is the right
thing to do. PFS is not mandatory, so how do I solve the existing case
of pfs conflict.  
**PW**: be liberal about PFS has a problem because if rekeys occur in
the other order.  
Valery: make distinction between rekey vs creation of additional child
SAs.  
**PW**: connections can have pfs=yes/no depending upon other situations,
such as when creating many SAs  
**PW** will write a document... if it includes the notify then it needs
STD. Otherwise, Informational/implementation guidance.

### QR alt update   {#qr-alt-update}

*Valery Smyslov*

**PW**: Libreswan is intrested in WG adoption because of existing
implemention of previous draft.

### Update of multiple sequence counters   {#update-of-multiple-sequence-counters}

*Steffen Klassert*

**PW**: what is PSP in brief?  
**SK**: PSP keeps trailer, but moves NH into the trailer out of the
encryption.  
**TK**: Wrapped ESP (WESP) was designed to do this. Things that are
needed could be copied there. An extra copy, but the high speed link can
cope with this. The padding changes on every single generation of the
CPU.... so this keep changing. It may not be worth optimitizing this
every time.  
**SK**: moved header to trailer, there was performance increase. Wasn't
sure WG wanted to do this.  
**TK**: WESP was designed to do extension to ESP, so we can modify it,
it is not abusing it.  
**Daniel Migault**: do we want to have an offset... and IPv6 extension
which is the copy of the unencrypted part we care about. And we already
asked for WESP (TFesp).  
**HT**: are already past the question about whether we want to work on
this problem? The instructions aren't going to change every few months,
but at a way lower rate.  
**Wei**: for the high speed problem, we have the same concerns. Our
problem statement is a bit different than yours.  
**Dan Harkins**: slide 9: want to understand this a bit better. TLS told
people off on this. What do the SDN people want to look into the header
for?  
**SK**: they just want the transport header.  
**PW**: often people run IPIP tunnels, so all the transport runs over
one port and one does not leak anything.  
**MCR**: Have you done implementation and do you have test results?  
**SK**: Yes, there is research results in document reference.  
**MCR**: What is the value from showing headers, is it worth the risk?  
**SK**: Google implemented similar in PSP.  
**MCR**: There must be very good analysis before doing this.  
(There were some other very short notifications about possible risks.)

### Anti-replay sequence number subspaces   {#anti-replay-sequence-number-subspaces}

*Pierre Pfister*

**HT**: Three people supporting is nothing.  
**TK**: Your problem is you don't support windowing mode. Big number of
SAs is not an issue, it takes few tenths of the seconds to create few
hundred Child SAs with windowing mode.  
**PW**: I was before a bit nervious because of IPR issues. Patent issue
shouldn't be a problem any more.

### BEET mode   {#beet-mode}

*Antony Antony*

**Robert Moskowitz (Bob)**: We are active using BEET in aviation with
multiple active links. With multiple links use case you get same packet
from multiple network paths. We see it very valuable to get this done.  
**DanH arkins**: Is there requirements to add this to IKE?  
**TK**: There hasn't been a way to negotiate this with IKE.  
**YN**: In flavor of standardizing this.  
**TK** (as a chair): Yes. In favor of doing this as a separate RFC. One
RFC for the beet bis mode (fixing fragmentation) and another for IKEv2
negotiation of it (keeping the HIP RFC for HIP negotiaton).

### Esp trailer adjustment   {#esp-trailer-adjustment}

*Wei Pan*

**Scott**: Your idea is really, really bad, you should not allow packet
to passed forward before the ICV has been checked.  
**HT**: Is there some more detail? I'm really intrested in problem
statement, which kind of chip are we talking about?  
**Wei**: Network processor (possibly ASIC)  
**Daniel Migault**: Is there any historical reason why next header in
trailer?  
**Bob**: There was historical reason to do things like they are done
like they are.  
**Valery**: You only need next header. If you move all trailer you loose
things.

### Delete info   {#delete-info}

*Paul Wouters*

**Bob**: We had debate in aviation: you want just TEXT, there is no way
you can enumerate all possible cases.  
**Scott**: We really need not just text to use this in our
implementation.  
**TK**: discussion on list.

### RISAV update   {#risav-update}

*Yangfei Guo*

No comments.

## AOB + Open Mic   {#aob--open-mic}

# EOF   {#eof}