[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 <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. > ### > > > > 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" > > > 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" ? > > 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. > ### > > > > 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" ? > ### > > > > 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 :) > ### > > > > 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. > ### > > > > 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 > 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. > > ### > > > > 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. Paul
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
