TCP socket receives strange packet

TCP socket receives strange packet

[Yurij M. Plotnikov]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

Connected TCP socket receives packet without timestamps option which 
exists in SYN, SYNACK and ACK. It is packet 4 in attached tcpdump output.

tcpdump output description: The host has address 10.208.10.1 (server) 
and the peer host has address 10.208.10.2 (client).

Establishing connection: Timestamps option exists in SYN, SYNACK and ACK 
(packets 1, 2 and 3 in attached file), so accepted socket should receive 
packets only with timestamps option.

Sending packet: the socket receives the packet without timestamps option 
(packet 4 in attached file), i.e. recv() function called on the socket 
receives the data from the packet. The "strange" packet is generated 
using PCAP.

I see this behaviour on 2.6.26 and on 3.14 kernels.

[-- Attachment #2: pcap_with_bad_packet --]
[-- Type: application/octet-stream, Size: 866 bytes --]

Re: TCP socket receives strange packet

[Eric Dumazet]

On Tue, 2014-10-14 at 18:09 +0400, Yurij M. Plotnikov wrote:
> Connected TCP socket receives packet without timestamps option which 
> exists in SYN, SYNACK and ACK. It is packet 4 in attached tcpdump output.
> 
> tcpdump output description: The host has address 10.208.10.1 (server) 
> and the peer host has address 10.208.10.2 (client).
> 
> Establishing connection: Timestamps option exists in SYN, SYNACK and ACK 
> (packets 1, 2 and 3 in attached file), so accepted socket should receive 
> packets only with timestamps option.

Can you point the RFC paragraph stating so ?

I have wondering if this behavior was correct some time ago, and could
not find a definitive answer.

RFC 1323 4.2.1 seems to suggest it is valid to accept a segment without
TS.

R1) If there is a Timestamps option in the arriving segment...


 There is no : Else drop the segment.

Re: TCP socket receives strange packet

[John Heffner]

On Tue, Oct 14, 2014 at 11:00 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2014-10-14 at 18:09 +0400, Yurij M. Plotnikov wrote:
>> Connected TCP socket receives packet without timestamps option which
>> exists in SYN, SYNACK and ACK. It is packet 4 in attached tcpdump output.
>>
>> tcpdump output description: The host has address 10.208.10.1 (server)
>> and the peer host has address 10.208.10.2 (client).
>>
>> Establishing connection: Timestamps option exists in SYN, SYNACK and ACK
>> (packets 1, 2 and 3 in attached file), so accepted socket should receive
>> packets only with timestamps option.
>
> Can you point the RFC paragraph stating so ?
>
> I have wondering if this behavior was correct some time ago, and could
> not find a definitive answer.
>
> RFC 1323 4.2.1 seems to suggest it is valid to accept a segment without
> TS.
>
> R1) If there is a Timestamps option in the arriving segment...
>
>
>  There is no : Else drop the segment.


I can't think of a good reason to drop unless you're trying to use the
timestamp fields as extra security against off-path injection attacks.
  (It doesn't currently help much for that.)

  -John

Re: TCP socket receives strange packet

[Christoph Paasch]

Hello,

On 14/10/14 - 11:40:44, John Heffner wrote:
> On Tue, Oct 14, 2014 at 11:00 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Tue, 2014-10-14 at 18:09 +0400, Yurij M. Plotnikov wrote:
> >> Connected TCP socket receives packet without timestamps option which
> >> exists in SYN, SYNACK and ACK. It is packet 4 in attached tcpdump output.
> >>
> >> tcpdump output description: The host has address 10.208.10.1 (server)
> >> and the peer host has address 10.208.10.2 (client).
> >>
> >> Establishing connection: Timestamps option exists in SYN, SYNACK and ACK
> >> (packets 1, 2 and 3 in attached file), so accepted socket should receive
> >> packets only with timestamps option.
> >
> > Can you point the RFC paragraph stating so ?
> >
> > I have wondering if this behavior was correct some time ago, and could
> > not find a definitive answer.
> >
> > RFC 1323 4.2.1 seems to suggest it is valid to accept a segment without
> > TS.
> >
> > R1) If there is a Timestamps option in the arriving segment...
> >
> >
> >  There is no : Else drop the segment.
> 
> 
> I can't think of a good reason to drop unless you're trying to use the
> timestamp fields as extra security against off-path injection attacks.
>   (It doesn't currently help much for that.)

there was a long discussion whether for the updated version of RFC1323 (now
published as RFC 7323) a segment must be dropped if it does not contain a
timestamp. The rationale (defended by Joe Touch) was that it must be there to
protect against wrapped sequence numbers while others argued that mandating
a drop might result in stalling connections if (for one reason or another) a
host sends a segment without TS (or a middlebox removed it).

The RFC now says that a host SHOULD drop segments without timestamps.



Cheers,
Christoph

Re: TCP socket receives strange packet

[David Miller]

From: Christoph Paasch <christoph.paasch@gmail.com>
Date: Tue, 14 Oct 2014 09:41:44 -0700

> there was a long discussion whether for the updated version of RFC1323 (now
> published as RFC 7323) a segment must be dropped if it does not contain a
> timestamp. The rationale (defended by Joe Touch) was that it must be there to
> protect against wrapped sequence numbers while others argued that mandating
> a drop might result in stalling connections if (for one reason or another) a
> host sends a segment without TS (or a middlebox removed it).
> 
> The RFC now says that a host SHOULD drop segments without timestamps.

There are too many middle-boxes that drop timestamps for that to be a tenable
way to behave, especially by default.

If you want to be disconnected from various parts of the internet, feel free
to follow that RFC's recommendations.

Re: TCP socket receives strange packet

[Christoph Paasch]

On 14/10/14 - 12:50:04, David Miller wrote:
> From: Christoph Paasch <christoph.paasch@gmail.com>
> Date: Tue, 14 Oct 2014 09:41:44 -0700
> 
> > there was a long discussion whether for the updated version of RFC1323 (now
> > published as RFC 7323) a segment must be dropped if it does not contain a
> > timestamp. The rationale (defended by Joe Touch) was that it must be there to
> > protect against wrapped sequence numbers while others argued that mandating
> > a drop might result in stalling connections if (for one reason or another) a
> > host sends a segment without TS (or a middlebox removed it).
> > 
> > The RFC now says that a host SHOULD drop segments without timestamps.
> 
> There are too many middle-boxes that drop timestamps for that to be a tenable
> way to behave, especially by default.
> 
> If you want to be disconnected from various parts of the internet, feel free
> to follow that RFC's recommendations.

I'm completely with you. We actually argued against Joe Touch, who wanted to
have a  "MUST" for dropping these segments without TS.


Cheers,
Christoph

Re: TCP socket receives strange packet

[David Miller]

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 14 Oct 2014 08:00:52 -0700

> On Tue, 2014-10-14 at 18:09 +0400, Yurij M. Plotnikov wrote:
>> Connected TCP socket receives packet without timestamps option which 
>> exists in SYN, SYNACK and ACK. It is packet 4 in attached tcpdump output.
>> 
>> tcpdump output description: The host has address 10.208.10.1 (server) 
>> and the peer host has address 10.208.10.2 (client).
>> 
>> Establishing connection: Timestamps option exists in SYN, SYNACK and ACK 
>> (packets 1, 2 and 3 in attached file), so accepted socket should receive 
>> packets only with timestamps option.
> 
> Can you point the RFC paragraph stating so ?

There is no requirement that timestamps be present just because they
were successfuly negoatiated during the handshake.

This has been brought up before several times.