IP Security Maintenance and Extensions (IPsecME) WG.

IETF 120 - Tuesday, July 23th, 2024 15:30-17:00
https://meetings.conf.meetecho.com/ietf120/?group=ipsecme&short=&item=1

Agenda

• Note Well, technical difficulties and agenda bashing -
  Chairs (2 min)
• Document Status -
  Chairs (3 min)

• Other items

  • Delete info -- Paul Wouters (3 min)
  • SA TS Payloads opt -- Paul Wouters (4 min)
  • Child PFS info -- Paul Wouters (4 min)
  • Anti replay notification -- Paul Wouters (4 min)
  • ESP Echo Protocol -- Jen Linkova (10 min)
  • Encrypted ESP Ping -- Antony Antony (10 min)
  • Beet mode -- Antony Antony (10 min)
  • Multiple sequence counters -- Steffen Klassert (5 min)
  • WESPv2 -- Steffen Klassert (15 min)
  • Diet-ESP -- Daniel Migault (5 min)
  • FrodoKEM in IKEv2 -- Wang Guilin (5 min)
  • PQC Auth -- Valery Smyslov (10 min)

• AOB + Open Mic (0 min)

Minutes

Note Well, technical difficulties and agenda bashing

Chairs
No agenda bashes.

Document Status

Chairs
Valery Smislov: successful interop with LibreSwan for ??? draft, so it
should be ready for WGLC.

Presentations

Delete info

Paul Wouters
draft-pwouters-ipsecme-delete-info

Tero Kivinen: What's the encoding of the Delete Reason Text field?
Paul Wouters: US-ASCII or UTF-8 are the usual, but there's no reason to
limit it.
Valery: Freeform text isn't better, but I'm not sure notification is
even needed. What can you do with it that's really helpful?
Paul: Some providers can't be reached out-of-band to ask why a tunnel is
down. So, there are cases where our customers would like if the software
gave some kind of reason and perhaps an idea of when to try again. I
agree that most reasons won't add much value.
Valery: I suspect mostly this isn't useful.
Paul: No need to implement it.
Christian Hopps: You aren't specifying the encoding for the text. I'm
usually happy to underspecify, but I'd prefer an encoding be specified.

Tero: Let's take both of those topics to the list.
Alan Jowett: You open yourself up to injection attacks.

SA TS Payloads opt

Paul Wouters
draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt

No comments.

Child PFS info

Paul Wouters
draft-pwouters-ipsecme-child-pfs-info

Paul: Should we do only the simple case or go back to the drawing board
and figure out how to handle the more complex cases.
Valery: I don't think this notification is all that useful when key
exchange methods are tied to other algorithms. GOST key exchange can
only be used with GOST ciphers, etc. To express such a policy, we need a
pairing.
Paul: There are many scenarios where this doesn't work. But in the IoT
use case where byte saving matters, this might be useful, even we aren't
handling more complicated use cases. Let's take it to the mailing list
to see if we can handle the more complicated use cases or give up on
that.

Anti replay notification

Paul Wouters
draft-pan-ipsecme-anti-replay-notification

Paul: Should we add value for “ESN separate from anti-replay"? We can
take this to the list.
Valery: ESN and replay can be decoupled although ESN is a should when
replay is enabled.
Paul: Many implementations don't make them separable.
Tero: G-IKEv2 also wants to disable replay prevention as well, so you
should take a look at that as well. There has also been interest for
having ESP where we have full 64-bit ESN. Take it to the list.

ESP Echo Protocol

Jen Linkova
draft-colitti-ipsecme-esp-ping

Valery: If used before IPSEC SA establishment, it can leave a lot of
questions. It's also not clear if this is to be used periodically or
only at the beginning. An encrypted ESP ping could be defined to see if
things work after IPSEC SA is established.
Jen: If you have multiple ways to establish IPSEC, failure might suggest
doing something else, with fallback to IPv4 the most common case. The
intention is to use ping before establishment, but also keeping state in
firewalls (too keep things from timing out) would say periodically.
Perhaps, normative language for that isn't necessary.
Valery: I don't have a suggestion for that. The mobile case is not
described in the draft.
Jen: We tried to specified how implement the mechanism, but didn't go
deeply into the how to use it. My question is should we?
Valery: Let's bring it to the list.
Christian: I don't think any of the use cases are normative. They're
just guidelines. Can you imagine specifying how to use ping? It's just a
mechanism, use it how you want. I think it's useful.
Lorenzo Colitti: Regarding the use of encrypted ESP ping, that requires
a lot of setup that may then have to be torn down. This is more useful
for a pre-flight check and more useful than an encrypted ESP ping.
Paul: I think you should fire off IPv4 and IPv6 connections in parallel
(happy eyeballs) and tear down one if unneeded.
Lorenzo: What about mobility cases?
Paul: People don't use MOBIKE in the field. They build up multiple
connections over multiple interfaces and route over the available
interface. I don't think MOBIKE use in needed. I think we should
implement this.
Jen: Let's take it to the list.

Encrypted ESP Ping

Antony Antony
draft-antony-ipsecme-encrypted-esp-ping

Antony: This is complementary to the previous presentation. I'm not
against that one.
Michael Richardson: I think is a great thing. I agree that there are two
interesting use cases. The probing of the return path with the different
SPIs is a good thing. I'd like to see the ability to set the TTL, for a
reverse trace. Imagine a tool that tells you in your multi-SA thing, the
things with prime sequence numbers got dropped or some other pathology
would useful. Let's adopt it.
Antony: When we the draft, we were ambivalent about announcing it in the
IKE negotiation.
Lorenzo: Can you use this packet format before IKE negotation and do
what the other draft is doing?
Antony: I think we can, but I didn't want to suggest it.
Lorenzo: I don't think we'll break any existing implementations.
Christian: In order to do congestion control, we have to know what the
return SA, so we need to have some way associating the sending and
returning SAs, just for congestion control.

Beet mode

Antony Antony
draft-antony-ipsecme-iekv2-beet-mode

Robert Moskowitz: I'm digging through archives to get old documents that
can be modified for a new draft.
Antony: I've done some manual copy and paste for this draft that might
be helpful.
Robert: We'll deal with that offline.
Paul: In general, the IESG does not favor RFCs that change things
paragraph-by-paragraph, but in this case, a minimal update as an
appendix seems better than opening up the whole document. This can be
done.
Yoav Nir: With no hats, I realize you can do this, but I don't like
something that is akin to tunnel mode and transport being specified in
an appendix. You could take the 8 page from 74xx or the 32 pages from
the XXX draft and publish it in its own RFC or publish with the one
paragraph section saying how to negotiate this with IKE. It's better
than just pointing at RFC 7402 and specifying the changes.
Antony: As Bob says, there are some minute details that come up.
Christian: It sounds like more than adding an appendix. That sounds like
a bis to me. In routing, we have been vigilant to say, "This is a bis
that does this, we are not opening it up to other things." No other
meddling.
Paul: Until IESG review.

Multiple sequence counters

Steffen Klassert
draft-mrossberg-ipsecme-multiple-sequence-counters

Yoav: This could be AD sponsored. There's even one AD who knows a lot
about IPSEC. If you don't need the WG do the work, then why not go
AD-sponsored.
Paul: Channeling Deb, we can't sponsor work for which a relevant WG
exists.
Tero: I think we can check it out in the WG and think about going to
WGLC if it is ready.

WESPv2

Steffen Klassert
draft-klassert-ipsecme-wespv2

Christian: I think we can drop the 'W' - it's ESPv2. We are taking 19
years of ESP experience and creating ESPv2. I think you're using wrapped
because you are afraid of getting a protocol number. I don't think it's
a big ask to get a new protocol number. And you'll never ask for another
one because you have a version number. We can just get an IP protocol
number and it would be clean:
Klassert: I don't see the point to it, but I don't mind either.
Christian: You are going to duplicate everything from the WESP header?
Klassert: Yes. But if the WG thinks we should go for a new protocol
number I don't mind.
Christian: Everyone makes the assertion that no one is using WESP and
maybe it's safe to make that assertion, but that's why we have protocol
numbers. I think we can float that in front of the Transport guys to see
if they object to ESPv2 after 20 years. There was no issue at all
getting a protocol number at all. It was forced on us.
Valery: You specify header length and crypto offset in 4-byte entites.
Why not in octet alignment?
Christian: ???
Antony: Word length is a 4-byte minimum (IPv4) or 8-bytes (IPv6).
Tero: This can be continued on the mailing list.

Diet-ESP

Daniel Migault
draft-ietf-ipsecme-diet-esp

Ready for WGLC by the next IETF meeting.

Paul: There were options where people copied the bits and some use cases
where they did not.
Tero: You need have an option whether you DSCP fields or actually clear
them specified by the IPsec Architecture RFC4301.
Michael: Ask the Transport folks. If it have been written this year, the
Transport people would say you have no choice of copying ECN bits. DSCP
is a different kettle of fish. There are many reasons to do different
things. A VPN is an argument for not copying those bits.
Christian: You don't want to copy ECN bits because they are not secure.
A hacker can set those and screw your TCP flow.
Michael: That's a possibility. They could also just drop your packets to
signal congestion to you, even though there wasn't any congestion. The
receivers of congestion signals need to be somewhat suspicious of those
signals.
Tero: For the DSCP, they are not copied because they have to be mapped -
they can be different for the internal network and the ISP network.
Daniel: There are cases where we should do that and where we should not.
A last question regarding the flow label: in order to compress that
field, we consider that it can be regenerated on the other gateway.

FrodoKEM in IKEv2

Wang Guilin
draft-wang-hybrid-kem-ikev2-frodo

Tero: No time for questions. Please take comments to the list.

PQC Auth

Valery Smyslov
draft-reddy-ipsecme-ikev2-pqc-auth

Paul: On Thursday at SAAG, we will have a talk whether various crypto
protocols should get an RFC number. Please go there and give us your
input.

AOB + Open Mic

Comments to the list.
How about an interim meeting?
Tero: I don't have time.
There are two chairs.
Tero: interim meeting in Helsinki!
Deb Cooley: You could ask for a longer meeting slot next time.
Tero: It's hard to size our slot. I will ask for 2 hours next.

EOF