To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, tcpinc <tcpinc@ietf.org>, krose@krose.org,
 tcpinc-chairs@ietf.org, draft-ietf-tcpinc-tcpcrypt@ietf.org
References: <151018832684.17229.17081270342741352337.idtracker@ietfa.amsl.com>
 <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <e674acae-925e-10e7-b473-46629452d0a2@nostrum.com>
Date: Wed, 8 Nov 2017 20:11:49 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net>
Content-Type: multipart/alternative;
 boundary="------------F8FAB135FDE83A53ADACBB7F"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/u_q_riCfQeFW09UL1x4rutkZ0iU>
Subject: Re: [tcpinc] Adam Roach's Yes on draft-ietf-tcpinc-tcpcrypt-09:
 (with COMMENT)
Precedence: list

This is a multi-part message in MIME format.
--------------F8FAB135FDE83A53ADACBB7F
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 11/8/17 19:45, Mirja Kuehlewind (IETF) wrote:
>> In one interpretation, the TCP stack acts as if those packets were never
>> received, and so they are never acknowledged. Since retransmissions will
>> contain the same contents and also fail to decrypt, this is basically just
>> going to cause a connection failure upon expiration of the retransmission timer
>> -- in which case an immediate failure is clearly preferable.
> That’s not true. This is to cover the case where the packet got corrupted on the path, thus hopefully the retransmission will decrypt correctly.


So, to be clear, you're talking about packet corruption that happens to 
produce a valid checksum, right? If that's the reasoning here, the 
authors probably want to include that rationale in the document.


>> The other interpretation is that the TCP packet is processed as received, but
>> that all of the data that could not be decrypted is elided from the stream of
>> bytes provided to the receiving application. This is also a problem, since many
>> applications rely on the in-order delivery aspects of TCP. The prospect that a
>> sender could provide "Message A", "Message B", and then"Message C" to its TCP
>> socket and the receiver only get "Message A" followed immediately by "Message
>> C" is not something that applications will generally be capable of handling. As
>> before, a connection reset would be preferable to violating the in-order
>> delivery guarantees of TCP.
>
> This can never happen with TCP.


Right. That's exactly my point.

/a


--------------F8FAB135FDE83A53ADACBB7F
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 11/8/17 19:45, Mirja Kuehlewind
      (IETF) wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:2E9FA28D-CCE3-4F4D-A25A-976543A70C03@kuehlewind.net">
      <blockquote type="cite" style="color: #000000;">
        <pre wrap="">In one interpretation, the TCP stack acts as if those packets were never
received, and so they are never acknowledged. Since retransmissions will
contain the same contents and also fail to decrypt, this is basically just
going to cause a connection failure upon expiration of the retransmission timer
-- in which case an immediate failure is clearly preferable.
</pre>
      </blockquote>
      <pre wrap="">That’s not true. This is to cover the case where the packet got corrupted on the path, thus hopefully the retransmission will decrypt correctly.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>So, to be clear, you're talking about packet corruption that
      happens to produce a valid checksum, right? If that's the
      reasoning here, the authors probably want to include that
      rationale in the document.</p>
    <p><br>
    </p>
    <p>
      <blockquote type="cite">
        <pre wrap=""><blockquote type="cite"><pre wrap="">The other interpretation is that the TCP packet is processed as received, but
that all of the data that could not be decrypted is elided from the stream of
bytes provided to the receiving application. This is also a problem, since many
applications rely on the in-order delivery aspects of TCP. The prospect that a
sender could provide "Message A", "Message B", and then"Message C" to its TCP
socket and the receiver only get "Message A" followed immediately by "Message
C" is not something that applications will generally be capable of handling. As
before, a connection reset would be preferable to violating the in-order
delivery guarantees of TCP.</pre>
</blockquote>
</pre>
        <pre wrap="">This can never happen with TCP.</pre>
      </blockquote>
    </p>
    <p><br>
    </p>
    <p>Right. That's exactly my point.<br>
    </p>
    <p>/a<br>
    </p>
  </body>
</html>

--------------F8FAB135FDE83A53ADACBB7F--