Subject: [tcpm] TCP checksum issues?

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 2 Aug 2013 10:24:45 +0000

Hi all,

In today's httpbis joint meeting, there was a brief discussion about potential issues related to the TCP checksum.

Since I am not aware of a recent discussion regarding the TCP checksum (it surely has been discussed quite a bit in the past, e.g., RFC 1146), this e-mail tries to trigger a follow-up discussion. I am particularly interested in better understanding any potential issues in the context of HTTP/2.

Thanks

Michael

PS: The TCP offloading issues and RFC 1936 should be obvious.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 9 Aug 2013 12:36:29 -0400

Hi Michael - since this thread has been quiet for a week I'll just chime in
with my understanding of the issue.

I interpreted Allison as reminding the HTTPbis WG that due to the weak TCP
checksum large streams will have a significant chance of containing
undetected errors. This is more relevant to HTTP 2 than HTTP 1 (not to say
it is irrelevant to HTTP 1) because the application protocol of HTTP-2
introduces a couple new stateful mechanisms (e.g. compressed header
dictionaries and credit schemes) that rely on both peers seeing identical
streams to work correctly.

She suggested TLS as an obvious mitigation and I would concur that HTTP/2
should always be carried over TLS (for a variety of reasons).

-Patrick (aka [email-masked])

On Fri, Aug 2, 2013 at 6:24 AM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> Hi all,
>
> In today's httpbis joint meeting, there was a brief discussion about
> potential issues related to the TCP checksum.
>
> Since I am not aware of a recent discussion regarding the TCP checksum (it
> surely has been discussed quite a bit in the past, e.g., RFC 1146), this
> e-mail tries to trigger a follow-up discussion. I am particularly
> interested in better understanding any potential issues in the context of
> HTTP/2.
>
> Thanks
>
> Michael
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 9 Aug 2013 10:33:01 -0700

This paper has some interesting analysis
http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf

""After an analysis we conclude that the checksum will fail to detect
errors for roughly 1 in 16 million to 10 billion packets. From our
analysis of the cause of errors""

It's no longer a small chance given the Web page size today.

On Fri, Aug 9, 2013 at 9:36 AM, Patrick McManus <[email-masked]> wrote:
> On Fri, Aug 2, 2013 at 6:24 AM, Scharf, Michael (Michael)
> <[email-masked]> wrote:
>>
>> Hi all,
>>
>> e-mail tries to trigger a follow-up discussion. I am particularly interested
>> in better understanding any potential issues in the context of HTTP/2.
>>
>> Thanks
>>
>> Michael
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Fri, 09 Aug 2013 11:58:42 -0700

> It's no longer a small chance given the Web page size today.

16 million would be 22 megabytes, but that TCP isn't the only place that 
errors are detected.

There's the link layer on each link, and the application layer. It's not 
clear that we actually do need to rely on TCP to detect such problems.

However, if that's not enough, simply using security (IPsec, TLS) would 
protected much better.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 9 Aug 2013 12:02:00 -0700

On Aug 9, 2013, at 11:58 AM, Joe Touch <[email-masked]> wrote:

> 16 million would be 22 megabytes, but that TCP isn't the only place that errors are detected.

Make that gigabytes. Which I also doubt is a common web anything. 

> There's the link layer on each link, and the application layer. It's not clear that we actually do need to rely on TCP to detect such problems.
> 
> However, if that's not enough, simply using security (IPsec, TLS) would protected much better.
> 
> Joe

---

From: Rick Jones <[email-masked]>
Date: Fri, 09 Aug 2013 12:13:07 -0700

> Make that gigabytes. Which I also doubt is a common web anything.

True, but wouldn't that then be one out of ~22K 1MB web transfers?

rick jones

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 9 Aug 2013 12:16:56 -0700

> Make that gigabytes. Which I also doubt is a common web anything.
Yeah I thought so too. But the fact this is raised in the httpbis/tsv
joint meeting means I was wrong.

This is the exact point of having more joint meeting to bridge httpbis/tsv.

---

From: John Heffner <[email-masked]>
Date: Fri, 9 Aug 2013 15:42:30 -0400

>From the paper:
"Note that many encryption solutions such as IPsec do not provide
additional protection. The encryption is applied
too late in the transmission process, often after the data has passed
through a DMA engine. Rather the application must add the checksum
before handing its data to TCP (ala SSL)."

It's also worth noting that hardware offload of TCP checksum
calculation is commonplace now, which eliminates even the protection
of that weak checksum.

  -John

---

From: Joe Touch <[email-masked]>
Date: Fri, 09 Aug 2013 13:21:51 -0700

> True, but wouldn't that then be one out of ~22K 1MB web transfers?

It's possible, but again it ignores protections at other layers too.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 09 Aug 2013 13:25:09 -0700

> calculation is commonplace now, which eliminates even the protection

Right, but that emphasizes the point - what kind of error is happening, 
and is TCP the only layer that would detect that error or would it have 
been caught elsewhere.

TCP isn't a checksum to the app anyway; it's to the OS in most 
implementations, so the fact that it might not protect between the NIC 
and main memory is only one of a few places that other errors can arise 
(e.g., NIC to main memory, main memory to the destination device [video 
memory, disk interface], etc.).

Joe

Joe