On Mon, Oct 15, 2018 at 04:56:18PM +0200, Mirja Kuehlewind (IETF) wrote: > Sorry, one more comment on section 11.1: > "DSO permits zero round-trip operation using TCP Fast Open [RFC7413] > with TLS 1.3 [RFC8446] 0-RTT to reduce or eliminate round trips in > session establishment.“ > > This sounds like TCP Fast Open and TLS 0-RTT can only be used together. > However these are to different mechanism with different properties/problems > and I don’t think they should be mixed up.
If I remember correctly, it was intended in the rev to only use TFP together with TLS 1.3 0-RTT and disallow using just one, though I forget exactly how this came out of the discussion from my Discuss point about specifying the TLS 1.3 0-RTT application profile. -Benjamin > Data that is send with with TLS 0-RTT must be idempotent as for this data an > reply attack is possible which is not the case for the rest of the TLS data. > However with TCP without TLS (but maybe TFO) reply attacks are always > possible, so that’s not an additional problem if TFO. > > With TFO however, a server could start processing without having a return > routability proof, however, such a problem can also be addressed on the > server-side by simply not stat processing large request before the TCP > connection is fully established and that is actually safer than leaving the > decisions to the client. > > Please clarify that TLS 0-RTT can be used without TFO (or TFO can be used > without TLS) and I would also recommend to discuss the respective issue > separately. > > Mirja > > > > > > Am 15.10.2018 um 16:02 schrieb Mirja Kuehlewind (IETF) > > <i...@kuehlewind.net>: > > > > Hi Ted, > > > > sorry for the delay, however, as you performed a couple of changes it took > > me a while to re-review. I believe I’m unfortunately not fully ready to > > release my discuss at this point, but close.. > > > > Regarding my first discuss point (delayed ACKs aso.) I think the text > > improved and I would like to seem my minor wording question (comment 2) > > below addressed before I finally release the discuss here. However, I still > > think the extensive discussion as provided in section 9.5 now, does not > > necessarily belong in this document. Therefore I would rather would have > > preferred to move this text in a real appendix, or removed it completely > > and maybe document in an own informational RFC (in tcpm). > > > > Regarding my second discuss point (keep-alives), the text seems still not > > quite right yet, or I’m really confused. Please also see also further below > > (comment 3). > > > > Anyway here are my comments on the edited/new text in the order they appear > > in the draft: > > > > 1) I think the following text in section 3 is not fully correct: > > > > "Fast Open message: A TCP SYN packet that begins a DSO connection and > > contains early data ([RFC8446] section 2.3). Fast Open is only > > permitted when using TLS encapsulation: a TCP SYN message that does > > not use TLS encapsulation but contains early data is not permitted.“ > > If TLS 0-RTT is used this data will not be carried in the TCP SYN, it will > > „just“ be send at the same time as the TLS handshake is performed (but > > after the TCP handshake). Only if TCP Fast Open (TFO) (see RFC7413) is > > used, data can also be sent in the TCP SYN. I guess you mainly need to fix > > the reference here, or maybe name both mechanisms separately. > > > > > > 2) In section 5.5.1: > > "With a DSO request message, the TCP implementation waits for the > > application-layer client software to generate the corresponding DSO > > response message, which enables the TCP implementation to send a > > single combined IP packet containing the TCP acknowledgement, the TCP > > window update, and the application-generated DSO response message. > > This is more efficient than sending three separate IP packets.“ > > > > The phrasing here is a bit confusing, to me at least. It sounds a bit like > > there is a special TCP for DSO… maybe the following is a bit better: > > "With a DSO request message, TCP delayed acknowledge timer will usually > > make the implementation wait for the > > application-layer client software to generate the corresponding DSO > > response message before it sends out an TCP acknowledgment > > This will generate a > > single combined IP packet containing the TCP acknowledgement, the TCP > > window update, and the application-generated DSO response message and > > is more efficient than sending three separate IP packets.“ > > > > (Note that the deplayed ack timer can be configured to a very small value > > as well, and as such it depends on the processing time and the value of the > > timer if a TCP implementation will wait or not.) > > > > 3) Section 6.5.2 > > "For example, a (hypothetical and unrealistic) > > keepalive interval value of 100 ms would result in a continuous > > stream of ten messages per second or more, in both directions, to > > keep the DSO Session alive. And, in this extreme example, a single > > packet loss and retransmission over a long path could introduce a > > momentary pause in the stream of messages of over 200 ms, long enough > > to cause the server to overzealously abort the connection.“ > > I think this example is still not correct (and the changes might made have > > it worse: how can there be more then 10 messages?) > > > > So the point here is that there is a dependency on the RTT. Only if the RTT > > is smaller than 200ms this can happen, otherwise the connection is closed > > anyway after two keep-alives. However, if the RTT is much smaller than > > 100ms and e.g. TLP is used, it would still work even if one packet is lost. > > > > In any case, I don’t think this example is actually very helpful. The point > > is that the keep-alives interval should always be much larger than the RTT > > to make this work appropriately. However, the point about keeping the > > network load is, is rather independent to the question of when the > > mechanism actually breaks. I would recommend to simply remove this example > > and just say that the interval MUST not be smaller than 10 sec to keep the > > network load reasonably low. > > > > However, having read this and the previous section again, I think your > > implementation of the keep-alives mechanism could also be improved. > > Usually, there should be two intervals. One defines, how long the > > connection can be idle before an keeps-live is sent and one that defines > > when a keeper-lives should be retransmitted if it is deemed to be lost, > > where the first one just usually be larger than the second one (and both > > timers should always be larger than the RTT). That would enable faster > > failure if the connection is actually lost. > > > > 4) Section 6.6.2.2. (Reconnecting After an Unexplained Connection Drop) > > "It is also possible for a server to forcibly terminate the > > connection; in this case the client doesn't know whether the > > termination was the result of a protocol error or a network outage. > > The client could determine which of the two is occurring by noticing > > if a connection is repeatedly dropped by the server; if so, the > > client can mark the server as not supporting DSO.“ > > How often should the client try and in which interval? > > > > 5) Section 9.2: > > "In principle, anycast servers could maintain sufficient state that > > they can both handle packets in the same TCP connection.“ > > Really? I mean in theory yes but has this ever been done in practice? I > > would think that sharing TCP state is even harder than sharing DSO state. > > > > > > Thanks! > > Mirja > > > > > > > > > > > >> Am 27.09.2018 um 06:57 schrieb Ted Lemon <mel...@fugue.com>: > >> > >> Mirja, I notice that you are still holding a discuss on this document. I > >> believe that we addressed the concerns you raised in your discuss. Could > >> you please let us know if there is still work to do on this, and if not, > >> clear the discuss? > >> > >> Thanks! > >> > >> > > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
