Re: [tcpm] Tcpsecure draft

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 17 March 2008 04:01 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: ietfarch-tcpm-archive@core3.amsl.com
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D7C3A6B1E; Sun, 16 Mar 2008 21:01:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.378
X-Spam-Level:
X-Spam-Status: No, score=-101.378 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlHCJfnXKUjV; Sun, 16 Mar 2008 21:01:09 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876093A689D; Sun, 16 Mar 2008 21:01:09 -0700 (PDT)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D51673A6830 for <tcpm@core3.amsl.com>; Sun, 16 Mar 2008 21:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfY+vsUc8BYv for <tcpm@core3.amsl.com>; Sun, 16 Mar 2008 21:01:07 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2FB713A689D for <tcpm@ietf.org>; Sun, 16 Mar 2008 21:01:07 -0700 (PDT)
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2008 20:58:51 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2H3wob7012401; Sun, 16 Mar 2008 20:58:50 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2H3wouR009707; Mon, 17 Mar 2008 03:58:50 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 20:58:50 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sun, 16 Mar 2008 20:58:25 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC5804DDA0A6@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <a3d0ecf70803161948i298cb631kc6ca418e7874f7e0@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Tcpsecure draft
Thread-Index: AciH2VzwL6hKegJqRyiPAkz1XrhlGAAApleA
References: <a3d0ecf70803161948i298cb631kc6ca418e7874f7e0@mail.gmail.com>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: "Patrick Collison" <patrick@collison.ie>
X-OriginalArrivalTime: 17 Mar 2008 03:58:50.0567 (UTC) FILETIME=[358ABD70:01C887E3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3870; t=1205726330; x=1206590330; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco .com> |Subject:=20RE=3A=20Tcpsecure=20draft |Sender:=20; bh=8fqAXQh4PtKUjz/ySkLE30e9jC0hW9RX8OenfjZcPWQ=; b=SYuOMJGWpLyaJb94FooiGYwL5HrrXd/6dXEvhiLwKeJdGXfWTo2aZgTE/A +hl9qS5qqVy79v2bS4m53BLjAXfEkpt54VJv+/XQiXlui63yLw3iIqGXler5 BtnXk9vHVQ;
Authentication-Results: sj-dkim-3; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>
Subject: Re: [tcpm] Tcpsecure draft
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.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://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Patrick,

   Pl see some comments inline to your queries.. 

> -----Original Message-----
> From: Patrick Collison [mailto:patrick@collison.ie] 
> Sent: Sunday, March 16, 2008 7:48 PM
> To: Anantha Ramaiah (ananth)
> Subject: Tcpsecure draft
> 
> Hi,
> 
> I just read the latest tcpsecure draft
> (http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure
> -09.txt),
> and have a question. I'm sure where the best place to ask is; 
> feel free to tell me to go elsewhere!

The mailing list is tcpm@ietf.org. Some ietf lists have the requirement
that you have to be subscribed to the list to send questions or else the
emails would be on hold before until some verification is done. I am not
sure about tcpm.

> 
> In section 3.2 B, it's stated that a valid sequence number 
> attached to a RST packet MUST reset the connection without 
> further transmission.

Yes this is just the default behaviour anyway since the valid seq# would
RST the connection. (ie., without the draft being implemented)

> 
> This has the problem that an attacker with very good 
> information (for example, where intermediate routers are 
> somehow colluding with the attacker -- as with Audible Magic 
> being deployed at ISPs,
> http://w2.eff.org/share/audible_magic.php) can trivially 
> guess the correct sequence number range, and send a couple of 
> RSTs that are all-but guaranteed to trigger a reset.

Yep, all bets are lost if the attacker can guess the correct sequence #
unless other protection mechanisms (which the draft talks about) are in
place.

> 
> I raise this because I'm in the process of implementing RST 
> spoofing protection in xnu, and saw that the draft has a very 
> similar solution to what I'd ended up with (zero-length ACKs 
> on receipt of RST, plus throttling). To mitigate the above 
> case, where the attacker can easily guess the correct 
> sequence number, I plan to either 1) send an ACK for all RSTs 
> (within the bounds of the ACK throttling) or 2) send an ACK 
> for all RSTs once a single bad RST packet has been received 
> for a particular TCP.

Couple of issues, I can see :-

#1 The attacker can send 2 consecutive RST's (with some random delay
between those) with exact sequence number, with your soluton you will
respond with ACK for the first RST segment, and suppose you receive the
second RST (again from the attacker), you will tear down the connection.

#2 you are penalizing a well behaving host which sends the exact seq#,
in other words, with your solution an RST would always incur a extra RTT
to tear down the connection. 

> 
> Both solutions have their drawbacks, so this will probably be 
> solved by means of a tuneable parameter, with 2 likely being 
> the default.

Sure, but see above corner case. 

> 
> Have the authors considered this situation? (And if so, was 
> it decided that the changes that mitigating this would require are too
> extensive?)

No, if the sequence # of the incoming RST = RCV.NXT, TCP would tear down
the connection, that's what we have. One of the main objections by some
people was that this solution "adds" an "arc' in the TCP state diagram
and if we would have proposed sending an ACK for all RST's (including
the ones matching the seq#) then it would have invited even more
resistance. But you are free to propose this :-)  

> 
> Lastly, is there a public mailing list where the discussion 
> surrounding these drafts has taken place?

Yes, the working version of this draft is -09- and that should give you
a clue on the age of this draft :-)

Your second question is already answered above. I am also taking the
liberty to cc the mailing list to keep them in the loop.

-Anantha
> 
> Cheers,
> 
> Patrick
> 
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm