Re: [DNSOP] Mirja Kühlewind's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

On Fri, Oct 26, 2018 at 9:35 AM Mirja Kuehlewind (IETF) <[e-mail]>
wrote:

> I guess you mean RFC8446 :-)
>
Yup, sorry.


> The table there on p.18 shows only the TLS handshake, there is a TCP
> handshake before that.
>

I don't believe this is correct, and given your comment at the end maybe
I'm just misunderstanding.   Are you saying that the TLS handshake is never
included in the SYN packet with TFO, or are you saying that it *might not* be
in the SYN packet?   If the TLS handshake doesn't come in the TFO packet,
there's a round trip, so we have some assurance that we are not being
flooded with TCP SYN packets by an off-link spoofer faking its source
address.   So it's only in the case that TLS 1.3 early data *in the TFO
packet* is an issue.   I suppose because of the way that early data is
handled, if it were present in the third packet there might be some risk,
but to be honest I do not know what the risk would be, and that was not
part of the threat analysis that Benjamin asked us to do (or at least if it
was, I didn't notice, and Benjamin seems okay with the outcome).   If you
think we've missed something here, it would help to get clarity on that.
 I do not claim to be an SME!   If there is an issue, I think the fix would
be to just make the text about early data apply whether it's in a TFO or
not.


> > 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.)
> >
> > I think using the passive voice here makes the text harder to follow,
> but I see what you are saying.   How about this:
> >
> > With a bidirectional exchange over TCP, as for example with a DSO request
> > message, the operating system TCP implementation waits for the
>
> "the operating system’s TCP implementation will usually wait for"
>
> or even better
>
> „the deplayed acknowledgments timer in TCP will usually wait for"
>

Is there an error in the text as proposed?   I understand that the way the
text expresses this point is not how you would express the point, but this
feels like a nitpick, not an actual problem in the text.


> > Remember that keepalives are not synchronous.   That is, if we send a
> keepalive, we don't wait for the response.   So it's perfectly possible for
> there to be several keepalives in flight in this situation, if the RTT is
> >200ms.
>
> Yes, I misunderstood that initially, however btw. why did you decide to
> design it that way?

>
> > 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.
> >
> > A possible point of confusion is that these are not TCP keepalive
> packets.   These are DSO messages being sent over the TCP transport.   So
> it's not possible for a keepalive to be lost.   If we don't get a response
> to a keepalive during the keepalive interval, this means that the TCP
> connection has stalled, or that the remote end is no longer reachable.
>  There is no retransmission.   Is that where the confusion lies, or am I
> misunderstanding?
>
> Right, I got actually confused here. So you send data frequently and if
> something goes wrong the connection will be closed at sender-side. Hm... it
> seems like if you want to test transport liveness with this (and not
> application liveness), you might maybe rather want use the existing
> keep-alive mechanism in TCP…? Why don’t you just recommend to use that?
>

You mean just use TCP keepalive?   It takes (I think) 90 seconds for a TCP
keepalive to time out the connection.   In some cases this is fine; in
others possibly not.   Doing it at the app layer gives us more flexibility,
and also conveys more information.


> > 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.
> >
> > As Benjamin said, I took out support for TCP Fast Open without TLS 1.3
> because I didn't think it was practical to address the potential issues
> with it.
>
> Not sure why you think that/which issues you mean? rfc7413 actually
> discusses all kind of issues extensively.
>
> >   However, in looking back at what I wrote, it's easy to see why this
> was confusing.   I've substantially tightened up the text about this: all
> cases where terms like "TCP Fast Open" and "0-RTT" are used now refer to
> "early data."   The changes are relatively small, but sprinkled over a
> whole section, so I don't think it's practical to enumerate them here, but
> they should show up nicely in the diffs.   I believe these changes address
> your concern, but please let me know if they do not.
> >
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-session-signal-17
>
> Okay, I believe this is fine now. I guess you could further clarify
> somewhere that „early data“ is always 0-RTT TLS with or _WITHOUT_ TFO.
>

Hm, okay.   As I said earlier, I'm not an SME here.   If there is an issue
with 0-RTT in the third packet of a TCP three-way handshake that didn't use
TFO, I can clarify.