Subject: [tcpm] New Version Notification for draft-leslie-tcpm-checksum-option-00.txt

From: John Leslie <[email-masked]>
Date: Thu, 23 Oct 2014 17:15:41 -0400

----- Forwarded message from [email-masked] -----

Date: Thu, 23 Oct 2014 13:28:51 -0700
From: [email-masked]
Subject: New Version Notification for draft-leslie-tcpm-checksum-option-00.txt
To: "John Leslie" <[email-masked]>, John Leslie <[email-masked]>

A new version of I-D, draft-leslie-tcpm-checksum-option-00.txt
has been successfully submitted by John Leslie and posted to the
IETF repository.

Name:		draft-leslie-tcpm-checksum-option
Revision:	00
Title:		Checksum Option for TCP
Document date:	2014-10-23
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-leslie-tcpm-checksum-option-00.txt
Status:         https://datatracker.ietf.org/doc/draft-leslie-tcpm-checksum-option/
Htmlized:       http://tools.ietf.org/html/draft-leslie-tcpm-checksum-option-00

Abstract:
   There are a number of situations in TCP where middleboxes are known
   to change TCP-layer data; and it would be helpful for endpoints to
   detect such changes.  TCP-Checksum is a TCP option to pass checksums
   over particular fields from sender to receiver, which can detect such
   changes by legacy middleboxes.  This document also sets a rule for
   future middleboxes which insist upon modifying these checksums.

----- End forwarded message -----

   This defines a way to request and/or pass checksums within TCP
packets for diagnostic purposes and to verify integrity.

   I know Joe dislikes diagnostic tools ;^) but I'll be happy to work
with him to add a way to send byte-count, which he _has_ agreed could
make sense. Of course, the option name should change in that case...

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Oct 2014 14:33:50 -0700

On 10/23/2014 2:15 PM, John Leslie wrote:
...
> make sense. Of course, the option name should change in that case...

I actually don't hate such tools, as long as we build them for that
purpose. This is a fine example, though I also think it's useful to just
have a payload length option because checksums touch all the data which
can be costly both computationally and from a memory access perspective.

Joe

---

From: John Leslie <[email-masked]>
Date: Thu, 23 Oct 2014 18:05:37 -0400

> can be costly both computationally and from a memory access perspective.

   Checksums certainly can be expensive for middleboxes; but IMHO the
expense for endpoints _usually_ becomes small in comparison to the
round-trip-time. Obviously, YMMV.

   I'm happy to add simple byte-count; but I'm not sure where to add it.
One particular issue is how big the count can grow. Right now, we're
thinking less than 256 bytes of options, but that obviously might grow
to 65536 -- and I'm nervous to say that, with jumbograms, it might not
someday exceed 65536...

   If we're sure it'll never need to exceed 65535, I'd be happy to drop
the three- and four-octet formats, and we could have one bit for length
vs. checksum.

   If we're not sure of that, we could change the "field-covered" bits
to define whether we're talking checksum or byte-count; and I'm not
too worried about running out of possibilities for "fields"...

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Oct 2014 15:28:14 -0700

> to 65536 -- and I'm nervous to say that, with jumbograms, it might not

I'd say at least 1K because the length of options is probably easier to
convey in units of 4-byte words, as DO is already encoded.

Note that we might end up caring about the length of the user data (and
whether it changes), not just the options. E.g., if the header has
TCP-AO, you care whether the rest of the user data was split or not...

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 23 Oct 2014 22:05:46 -0400

> Name:		draft-leslie-tcpm-checksum-option

Thanks for submitting this; I think it's interesting and useful
for some of the issues being discussed currently, as noted in
the draft.

Here are some questions and suggestions:

- Is the "request" mechanism really necessary?  I think this is
  something you either send when doing risky things, or don't,
  but in any case, it's triggered by the sender.  I think we
  would tie a dependency to do this into any other options that
  are presumed to be risky (e.g. EDO).

- If the request mechanism is necessary, then do we really need
  to be able to dynamically request the other side to turn the
  different checksums on and off?  I can't imagine logic doing
  that, but I might just be uncreative or unperceptive of the need.

- In section 5, I was confused ... I had assumed that the 16-bit
  and longer values were computed using the sum of 16-bit or
  longer values (not 8-bit values), but the text here only talks
  about byte-wide inputs.

-- 
Wes Eddy
MTI Systems

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Oct 2014 14:01:31 -0400

> convey in units of 4-byte words, as DO is already encoded.

   I won't object to counting option bytes that way, but I don't advise
it.

   IMHO, 1024 bytes is not a good "forever" limit; nor do I believe
that all the ways option space might be expanded will necessarily
fall on 32-bit boundaries. The easier-to-code argument leaves me cold.

> TCP-AO, you care whether the rest of the user data was split or not...

   Good point. I did include a field-covered value for "TCP payload
intended to go to the application.

---

From: John Leslie <[email-masked]>
Date: Fri, 24 Oct 2014 14:18:55 -0400

Wesley Eddy <[email-masked]> wrote:
> - Is the "request" mechanism really necessary?

   It was a design goal of mine to make it as unnecessary as possible:
that you can never depend upon it being recevied: least of all acted
upon.

   However, I did think it important that there should be a way to
ask the other point to stop sending checksums; and it seemed useful
to switch between always-send and send-once.

>   I think this is something you either send when doing risky things,
>   or don't, but in any case, it's triggered by the sender.

   It certainly will often be triggered by the sender. Just as an
endpoint sending a request can't depend upon it being acted upon,
neither can it depend upon not receiving an unsolicited checksum.

>   I think we would tie a dependency to do this into any other options
>   that are presumed to be risky (e.g. EDO).

   I would suggest that, especially for Bob's version which depends
upon a "magic number".

>   that, but I might just be uncreative or unperceptive of the need.

   I don't envision that for EDO; but I can imagine cases where the
level of paranoia changes during a connection...

>   longer values (not 8-bit values), but the text here only talks

   That is indeed what I intended. It was a fairly major design goal
that it should be easy to _use_ a wrong-length checksum.

   I don't really see much need for three- or four-byte checksums,
but I wanted one- and two-byte checksums to interoperate as simply
as possible.

   I don't trust my memory about comparing two-byte checksums where
one is generated from 8-bit arithmetic while the other is generated
from 16-bit arithmetice -- except that both cases _can_ be reduced
to 8-bits and then compared. (Somebody may wish to refresh my
memory there.)

   I wouldn't _object_ to comparing two-byte checksums that way;
but it seemed unwise while I was writing this...