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

• 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

Note Well, technical difficulties and agenda bashing

Chairs

Document Status

Chairs

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

(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

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

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"

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

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

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

EOF