Proposed changes look good. Thanks ! Paul
Sent using a virtual keyboard on a phone > On Aug 22, 2022, at 02:00, Valery Smyslov <s...@elvis.ru> wrote: > > > 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 <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
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
