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

IETF 116 - Wednesday March 29th, 2023 15:30-17:00 JST  
https://meetings.conf.meetecho.com/ietf116/?group=ipsecme&short=&item=1

## Agenda   {#agenda}

*   Note Well, technical difficulties and agenda bashing -   
    Chairs (5 min)
*   Document Status -  
    Chairs (15 min)
*   Work items
    *   Issues SA TS Payloads opt draft  
        Paul Wouters (10 min)
    *   Alternative Approach for Mixing Preshared Keys in IKEv2  
        for Post-quantum Security   
        Valery Smyslov (10 min)
    *   Extended IKEv2 Payload Format  
        Valery Smyslov (20 min)
    *   Anti replay subspaces  
        Mohsin Shaikh (10 min)
    *   IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension"   
        Daniel Migault (10 min)
    *   Traffic Selector for Internet Key Exchange  
        version 2 to add support Differentiated Services Field
        Codepoints  
        Daniel Migault (10 min)
    *   Inter-domain source address validation using RPKI and IPsec (if
        time permits)

*   AOB + Open Mic (0 min)

# Minutes   {#minutes}

## Note Well, technical difficulties and agenda bashing   {#note-well-technical-difficulties-and-agenda-bashing}

*Chairs*

## Document Status   {#document-status}

*Chairs*

## Issues SA TS Payloads opt draft   {#issues-sa-ts-payloads-opt-draft}

*Paul Wouters*

(slide 4)  
Valery: can we use both proposals for deciding what groups to use for
PFS? Paul argued for proposal 1.  
(slide 5)  
Yoav: for IPsec-type notifies, Yaov argued for proposal 2 (???)   
Valery: he argued for proposal 1  
Tero: (referring back to slide 4) put the notifies in the same place
where we put other notifies related to SAs, i.e. rfc7296 says they are
in same message where the SA payload is.  
(slide 6)  
Scott: another proposal is to just not support IPComp.   
Paul: well, this is not the place for deprecating IPComp.   
Yoav: we (checkpoint) didn't have IPComp but we had single-DES!  
(slide 7)  
Valery: if the peers don't agree it's a failure  
Paul: but you don't need to tear down IKE SA if child SA has negotiation
issue.  
Paul: discuss on list further.  
appeal for more than 2 implementations....

## Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security   {#alternative-approach-for-mixing-preshared-keys-in-ikev2-for-post-quantum-security}

(slide 5)  
Tero: GIKEv2 actually uses the wrapping keys, and if I remember right
the key for wrapping is derived in such way it gets PPK protection.  
Tero: there may be an issue if the two sides have different PPKs (with
the same PPKID). Should be easy to fix.  
Scott: you assume the peer supports 8784 and this protocol, that may not
be the case.   
Valery: if controller doesn't understand this then it's negotiatable.   
Scott: if the controller doesn't understand it's not gonna do the right
thing.  
Valery: then it will do 8784.  
Scott: need another NOTIFY to say you support this particular protocol. 

Paul: you would have the same 2 NOTIFYs-- bad.  
(slide 8)  
Paul: this could be accidentally done  
Valery: we could forbid it  
(slide 9)  
Tero: we would need to send multiple key confirmation payloads. And, are
we reusing the authpayloads, how do we tie them together - details need
to be worked out  
Michael: instead of a payload, you could use a computed id  
Tero action: this will be a working group item, should start wg adoption
call soon.

## Extended IKEv2 Payload Format   {#extended-ikev2-payload-format}

*Valery Smyslov*

Daniel: the changes are so extensive, you might as well call it IKEv3   
Yaov: we're actually solving two problems: large payloads, and trying to
compactify things. These are two different problems; perhaps they should
be solved separately.  
Scott: the rules to send large payloads is straightforward and the
compactify stuff is more complicated. Maybe leave rest to IKEv3.  
Tero: are you touching anything outside of the payloads? If not, it
might be a way to automatically convert from the standard IKEv2 format
and the compressed format.  
Tero: before the WG works on this, we need more mailing list comments  
Poll: 12 votes to support > 64k payloads, 1 not to  
Paul: Perhaps we should wait before going ahead to support huge
payloads.

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

*Mohsin Shaikh*

Q: should the group adopt this?  
Ben: it's an interesting topic and the WG should deal with it. Draft is
a reasonable starting point.   
Paul: the IPR is a standard release  
Dan: Network Alchemy may have old IPR in this area

## IKEv2 IPv4 Link Maximum Atomic Packet Notification Extension"   {#ikev2-ipv4-link-maximum-atomic-packet-notification-extension}

*Daniel Migault*

Tero: I propose that we wait for more people to comment on the list

## Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints   {#traffic-selector-for-internet-key-exchange-version-2-to-add-support-differentiated-services-field-codepoints}

*Daniel Migault*

Tero: what is the benefit? Does it make management easier?  
Tero: I see the traffic DSCP selector associated with the initiator  
Valery: DSCP is not a security property - should this be a part of the
traffic selector?  
Valery: DSCP list reduction by the responder might not work property.  
Paul: if you negotiate one SA with some of the DSCPs, and send traffic
not matching that DSCP, we'll send that traffic in the clear - not good.

## Inter-domain source address validation using RPKI and IPsec   {#inter-domain-source-address-validation-using-rpki-and-ipsec}

Yoav: didn't have time for this but we will devote time in the future.  
Paul: need routing people involved too, not just ipsec people.

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

# EOF   {#eof}