RE: [tcpm] TCP Secure
"Mitesh Dalal \(mdalal\)" <mdalal@cisco.com> Wed, 23 May 2007 17:46 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 1Hquuu-00063i-Sw; Wed, 23 May 2007 13:46:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hquut-00063d-Jb for tcpm@ietf.org; Wed, 23 May 2007 13:46:31 -0400
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hquut-0000z7-1J for tcpm@ietf.org; Wed, 23 May 2007 13:46:31 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 23 May 2007 10:46:30 -0700
X-IronPort-AV: i="4.14,570,1170662400"; d="scan'208,217"; a="487979213:sNHT295208744"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4NHkUYq006264; Wed, 23 May 2007 10:46:30 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4NHkB2Y020512; Wed, 23 May 2007 17:46:30 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 10:46:26 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] TCP Secure
Date: Wed, 23 May 2007 10:46:26 -0700
Message-ID: <13D1EAB852BE194C94773A947138483D0380DD7E@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <BAB4DC0CD5148948A86BD047A85CE2A702DBB54F@E03MVZ4-UKDY.domain1.systemhost.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] TCP Secure
Thread-Index: AceZVNkemAiLQ7iLRQKC0/WDRCqdNgEDQeRw
From: "Mitesh Dalal (mdalal)" <mdalal@cisco.com>
To: toby.moncaster@bt.com, tcpm@ietf.org
X-OriginalArrivalTime: 23 May 2007 17:46:26.0662 (UTC) FILETIME=[495E4860:01C79D62]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5998; t=1179942390; x=1180806390; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mdalal@cisco.com; z=From:=20=22Mitesh=20Dalal=20\(mdalal\)=22=20<mdalal@cisco.com> |Subject:=20RE=3A=20[tcpm]=20TCP=20Secure |Sender:=20; bh=+pJfYyZCKtzkaGRBU7ecQq1hZr0uJIQ0bZALGiNXWLk=; b=aUtKZsjwgdB4Lbwn1vAmZqPVW973qRNsH1KpMiy2FSH2i/Nt4Kunm23KESf3QsMHW2lV522f vVH+r08zHenQdxzYNEwkstXI8TtRb/LwU2ql+obF0kNMxrpNUyzk5vCY;
Authentication-Results: sj-dkim-4; header.From=mdalal@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc:
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>
Content-Type: multipart/mixed; boundary="===============0716728146=="
Errors-To: tcpm-bounces@ietf.org
Hi Toby, Please see inline. ________________________________ From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] Sent: Friday, May 18, 2007 7:00 AM To: tcpm@ietf.org Subject: [tcpm] TCP Secure 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. Mitesh: yes, they are processed as normal as if the RST didnt arrive. 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) Mitesh: you mean the other side send bunch of data followed by a RST, however we received the RST followed by the data ? In that case, we send an ACK for the RST and process the following data and hopefully when we get the RST for the ACK that we had send, we will flush the connection. 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 Thanks. We will get them in. Mitesh
_______________________________________________ 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)