IETF 121 - Monday, November 4th, 2024 09:30-11:30
https://meetings.conf.meetecho.com/ietf121/?group=ipsecme&short=&item=1
Presentations
AOB
Chairs (5 min)
Chairs (10 min)
Would like to get g-ikev2 out soon.
Inviting more reviews ikev2-qr-alt, specifically look two different key
generation
Daniel: diet-esp is almost ready, going to make new version and then
it should be ready.
Wei Pan (15 min)
draft-pan-ipsecme-anti-replay-notification
Wei: Problem statement : Operators tend to disable Anti-replay
protection and they notice packets are droped.
Valery: interpertation of 4303 is Window size could be zero.
Wei: Wheather to notify the peer disabling of Anti-replay
protection.
Yoav: the sender must sent the SN and the receiver may verify or
not. Sender need to maintain counter and rekey to frequently when ESN
disabled.
Valery: if sequence wraps RFC 8750, IIV, would fail. current draft
mixes the IKEv2 notify and ESP packet processing decryption need the 64
bits. so just a notifier won't help.
John: this I.D. need to cover security implications. 3GPP mandates
Anti-replay protection.
John: I would see how to do replay protection efficiently than
disabling it.
Wei: More research current security considertation.
Paul: application would cover large losses. The I.D. would like to
decouple Anti-replay protection.
Antony: is all of Appendix 4303 implemented, if not may be specify
how much is implemented. This included some specific things such as
re-injecting with second gussing higher order sequence number.
Wei: check with ESP implementation
Steffen Klassert (15 min)
draft-klassert-ipsecme-eesp
Steffen: Propsal for new protocol to replace current ESP: packet
format, base headers and optional TLV options.
Steffen: save 4 bytes using optimized on Tunnel mode. Would header
TLVs work
Steffen: IPR due to copying
Chris: saving 4 bytes in tunnel mode is signifiant
Valery: useful draft. How session ID are negotiated?. Discuss
further how to use Flow ID, CPU pinning
Steffen: not very clear now, will consider later.
Paul: Strongly support, long overdue for modernization
Scott: recomend copying from RFC4303 instead of reffering.
Chris: general gist is copy from
Liang: any materials, to describing the use cases.
Steffen: read the problem statement I.Ds referred in the document
Liang: whether to separate the draft to several drafts
Steffen: this ID provides structure and extend it
Wei: several of my I.Ds are used for problem statement, carry on
Paul: process: as IESG. IESG does not like huge "diff RFCs" and
prefers folding in changes. From programmers point of view, it is also
much easier to implement 1 RFC instead of two RFCs with "diff sections"
Antony:
Daniel: perfers a standalone draft.
Daniel: What's the overhead of EESP?
Steffen: 4-8 bytes. Several TLVs and Crypto offset is less common
Tero: suspect this not in Charter. This is not a minor extension. We
may need to re-charter to cover this I.D.
Ben Salter (10 min)
draft-salter-ipsecme-sha3
Ben: New I.D as of IETF 121.
Ben: Use SHA3 every where, most PQ libraries internally use SHA3
Ben: new PRF+ in one call, instead of current iteration
Ben: pair SHA3 instead of AEAD.
Daniel: How important is SHA 224 when most people are trying to
sunset 112-bit cryptography?
Ben: SHA 224 code point is not included, not strong preference.
Scott: HMAC SHA3 does not make much sense, instead use KMAC
Ben: absloutely KMAC is better solution, use SHA3 as intermediate
John: during PQC transition Ericsson would move to SHA3
Valery: IKEv2 rfc is hard coded PRF+ function. Negotation of PRF+
function is complicated and need discussion
Paul: Migrations support may hits bad, as implimentor go directly
for the best.
Paul: hand out code points liberally, RFCs sparringly. Use Drafts.
Paul: SAAG will discuss crypto practices/policies
Quynh Dang: we are putting out a call for AEAD, Keccak based crypto.
Which is more efficient.
Guilin: may this is nore than IPsec, may be for CFRG
Bjorn: Find one single solution.
Bob: HMAC is a beautiful thing. It is time to move to KMAC.
Wang Guilin (10 min)
draft-wang-hybrid-kem-ikev2-frodo
Result from researsh:
IKEv2 re-transmitting is not efficient when there is single packet
loss.
1: one packet loss would lead to re-transmit all packets
2: re-transmit dealy
Paul: with re-transmission IKEv2 fragmentation would help?
Valery: retransmitting all packets is a limitation, IKEv2
fragmentation would not help,
Valery: it is better to use TCP.
This is not ideal for ESP, follow the separate I.D. to separate IKE and
ESP.
Antony Antony (5 min)
draft-antony-ipsecme-iekv2-beet-mode
Tero: sending email to the list for wg adoption
Chris: support adoption.
Deb: check for Tero's opinion
Tero: want to see discussion on the mailing list before adoption
call
Antony Antony (10 min)
draft-antony-ipsecme-encrypted-esp-ping
Jun Hu: useful document. IKEv2 has DPD, what to if IKE has
confiliction with this draft?
Antony: DPD can do limited things, this draft will help you
Jun Hu: what to do if conflicted? will rekey?
Antony: rekey will not help
Jun Hu: maybe need to tear down the connection
Steffen: want adoption call before implementing it
Steffen: whether to merge two drafts?
Tero: go to mailing list
Scott Fluhrer (10 min)
draft-reddy-ipsecme-ikev2-pqc-auth
Scott: asking for WG adoption, this ID would go totogeter with AUTH
payload
Tero: send e-mail to the List asking for adoption
Deb: would like to motivate authors, the list, and the chairs move
swiftly.
Jun Hu (10 min)
draft-hu-ipsecme-pqt-hybrid-auth
Paul: why use PPK?
Jun: give hybrid authentication capability (paul: i understood it as
"protecting classic part as defense in depth")
Russ: concerned about the context string.
Scott: type 1 and type 2, why both.
Daniel van Geest: follow LAMPS
Linda Dunbar (10 min)
draft-dunbar-secdispatch-ligthtweight-authenticate
Linda: Despatch group at IETF 120 send us to IPsecME. This WG is
appropriate to get comments as expertice is here.
Chris: authentication between gateways?
Linda: additional header is added to steer the traffic, lightweight
authentication for this header
Tero: indepent from IPsec header, you have end to end IPsec, and
then separate authentication from originator to ingress gateway.
Chris: need to authenticate per hop to prevent mis-routing
Linda: Within backbone cloud, there is their own security mechanism.
Want to have authentication check in the ingress and egress node.
Tero: bring to here not because it's IPsec problem, just want to get
feedback from experts.
Chris: hybrid problem of security and routing
Deb: sound like NASR BOF. NASR will have a sidemeeting today.
Tero: discuss in IPsec list or others
Deb: not sure now