[tcpm] TCP Secure
<toby.moncaster@bt.com> Fri, 18 May 2007 14:00 UTC
Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp306-0007FH-0P; Fri, 18 May 2007 10:00:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp304-0007Ey-PQ for tcpm@ietf.org; Fri, 18 May 2007 10:00:08 -0400
Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp304-0001ge-9R for tcpm@ietf.org; Fri, 18 May 2007 10:00:08 -0400
Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 15:00:07 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C79954.D70FD775"
Date: Fri, 18 May 2007 15:00:10 +0100
Message-ID: <BAB4DC0CD5148948A86BD047A85CE2A702DBB54F@E03MVZ4-UKDY.domain1.systemhost.net>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Thread-Topic: TCP Secure
Thread-Index: AceZVNkemAiLQ7iLRQKC0/WDRCqdNg==
From: toby.moncaster@bt.com
To: tcpm@ietf.org
X-OriginalArrivalTime: 18 May 2007 14:00:07.0614 (UTC) FILETIME=[D78F3DE0:01C79954]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Subject: [tcpm] TCP Secure
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org
Hi, I was just wanting a couple of bits of clarification about TCP Secure: Top of page 10: It isn't clear what happens to other segments after you drop the RST? Are they just processed as normal? This is what is implied but it would be useful if it were made explicitly clear. What happens if there is any re-ordering before a valid RST or SYN is sent? Can you clarify how your mitigations react to this. From my understanding, the reason for originally accepting any RST or SYN in the valid receive window was to allow for data reordering (as explicitly stated in RFC793) Finally: spotted three typos: Page 5 para 3) "...before succeeding in his mischieve." --> "... before succeeding in his mischief." Page 11 3rd para up from bottom "...would not have a TCB..." --> "...would not have a TCP..." Page 19, para 2. Initial "i" not capitalized Toby ________________________________________________________________________ ____ Toby Moncaster, <toby.moncaster@bt.com> Networks Research Centre, BT Research B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK. +44 1473 648734
_______________________________________________ tcpm mailing list tcpm@ietf.org https://www1.ietf.org/mailman/listinfo/tcpm
- [tcpm] TCP Secure toby.moncaster
- RE: [tcpm] TCP Secure Mitesh Dalal (mdalal)