Hi Paul,
thank you for the follow-up. From: Paul Wouters [mailto:paul.wout...@aiven.io] Sent: Thursday, August 18, 2022 9:12 PM To: Valery Smyslov Cc: The IESG; draft-ietf-ipsecme-rfc8229...@ietf.org; ipsecme-cha...@ietf.org; ipsec@ietf.org; kivi...@iki.fi Subject: Re: Paul Wouters' Yes on draft-ietf-ipsecme-rfc8229bis-07: (with COMMENT) [Cut parts we agreed on, and where you provided text that is okay with me] Note the last outstanding minor issue for me is the "one ESP message" (see below). Paul On Wed, Aug 10, 2022 at 8:49 AM Valery Smyslov < <mailto:s...@elvis.ru> s...@elvis.ru> wrote: BTW, the value 3 for the Length field is valid, even if it is under 4 :-) - in case of NAT keepalive packet (discouraged, but not prohibited over TCP). :-) I guess technically, it should have been separated into its own section, eg IKE Message, ESP packet and NAT Keepalive. But I'm okay as it is now. Fine :-) > ### > > Section 5: > > when it has been configured to be used with specific IKE peers. > > I would say "when it has been configured to be optionally used with specific > IKE peers. > Otherwise, implementers might think it needs to be an on/off setting instead > of a > "may be used when udp is blocked" setting. Well, I think these implementation details need not to be covered in the spec. While UDP is preferred, there may be situations, where it is known for sure that UDP is permanently blocked, so there is no need to try it each time introducing additional delay. For example, our implementations may be configured with three choices (per peer) - never use TCP, may use TCP if UDP is blocked, always use TCP. I'd leave the text as is. My problem is a bit with the term "use". Does it mean "when actively using this" or "when allowed as per local config to use this when UDP fails". So "to be used with specific IKE peers" might be read as "always only use TCP with these peers", or "always allow TCP fallback" Both. You may configure initiator to use TCP only when UDP fails or to use TCP always, because you know for sure that UDP is blocked for this peer. I think the text later in this para is clear enough about this: Initiators MAY use TCP encapsulation for any IKE session to a peer that is configured to support TCP encapsulation, although it is recommended that Initiators only use TCP encapsulation when traffic over UDP is blocked. Do you think any further clarification is needed? > Similarly: > > If a Responder is configured to use TCP encapsulation, > > I would say "is configured to accept TCP encapsulation" Hm, I think "use" is more generic, after accepting TCP the responder will also send something over it :-) I suggest: s/is configured to use/is configured to accept and use is it OK? How about "accept and allowed to use" ? OK, no problem. > Also instead of "previous IKE session" maybe say "previous encapsulation > session"? Then what is "encapsulation session"? This term is not defined in the spec. I think we may leave the text as is for simplicity, although I see your point. I would still like to see something that is not "previous IKE session" as that might confuse implementer in thinking they need to start a new IKE session instead of just starting a new TCP connection. How about? s/a previous IKE session/an existing IKE/ESP session > ### > > Implementations > SHOULD NOT tear down a connection if only a single ESP message has an > unknown SPI, since the SPI databases may be momentarily out of sync. > > This advise might be difficult to follow. If this out of sync really happens, > it would be likely that a number of ESP packets would be seen before the IKE > packet comes in that syncs up the SPI. (assuming this out of sync issue > happens > when the TCP responder is also the IKE responder to a rekey and once it > rekeyed > and installed a new IPsec SA it starts sending ESP packets before it sends its > IKE rekey reply, or a number of smaller ESP packets arrive sooner somehow?) There may be delays while installing the ESP SAs depending on the implementation. E.g. if you have an asynchronous API between IKE and kernel. My problem is still not resolved through. You say "a single ESP message". Whatever is causing the "single" message, could also cause 2 or 3 or 10 messages? So I find the guidance unsafe. Maybe talk in vague time windows, eg "a brief time" or "a few seconds" ? How about? s/only a single ESP message/only a few consecutive ESP packets > ### > > Section 6.3 talks a lot about how COOKIE stuff is both useless for TCP > and can fail in mysterious new ways. Why not simplify things and say > "cookies must (should?) not be verified and fully ignored when over TCP, > and only puzzles should be verified" I think it's too radical change. Cookies can still be verified with TCP if no source IP and port are included into their calculation. Reluctantly will let you get away with it :) OK :-) > ### > > How about sharing an alternative to the transport mode checksum fixups: > > Implementations MAY use the information that a NAT is present to omit > sending USE_TRANSPORT over TCP, and thus enforce tunnel mode IPsec > SA's > to avoid the need for checksum fixups for encapsulated packets inside > TCP. This is not specific to TCP encapsulation. And I think that the selection of mode may be driven by various considerations, so avoiding checksum fixups is usually not the primary one. Sure. Let's leave this one up to the implementers. Whatever they do, it is clearly signaled. Fine. > ### > > for which purpose the standard IKEv2 mechanism of > exchanging empty INFORMATIONAL messages is used > > I believe these INFORMATIONALs are not neccessarilly empty, even though > they started > out that way. I would just leave out the word "empty". Well, actually any successful IKE exchange serves as a liveness check, so we may want to leave out INFORMATIONAL too :-) But the point is that RFC 7296 specifies sending empty INFORMATIONAL request as a dedicated mechanism for liveness check. Ok fair. If you mean that an "empty" message in fact contains the Encrypted payload, then I believe we are going too far in an attempt to be accurate and this would confuse implementers. Sure any message is sent encrypted once IKE SA is established, we are speaking about its internal content... No I didn't mean that. I recall some RFC (mobike?) to add NAT-T payloads to the liveness check one, so it wouldn't be empty anymore. Maybe we can use: (empty) INFORMATIONAL That's true for MOBIKE. How about? s/empty/(usually empty) So, I'd leave the text as is. > ### > > Section 6.7 mentions QoS, but we are also working on per-CPU IPsec SA's, > which would > have the same problem. Perhaps that can be worked into the existing text? I > would > perhaps also state here that the effects on performance are not very > important, as doing > TCP encapsulation in itself is already reducing performance significantly. Sure. Did this actually get new text? since you didn't quote it here. either way, it is fine. OK. > ### > > Alternatively, implementations MAY try to re-sync after they receive > unknown SPIs by searching the TCP stream [...] > > This is an odd paragraph. "You can do this, but really it is futile". I would > remove it. We describe an alternative way as well as its drawbacks. It's not always futile, but it may happen be such. It seems like a pretty complicated MAY to implement, but okay. Fine :-) Thank you, Valery. Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
