Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard
"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 13 April 2009 23:22 UTC
Return-Path: <ananth@cisco.com>
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 7B29828C146; Mon, 13 Apr 2009 16:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 NI5+AJUlVAgp; Mon, 13 Apr 2009 16:22:45 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F38053A6765; Mon, 13 Apr 2009 16:22:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.40,182,1238976000"; d="scan'208";a="71832337"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 13 Apr 2009 23:23:56 +0000
Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3DNNuoI011078; Mon, 13 Apr 2009 16:23:56 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n3DNNuhr025577; Mon, 13 Apr 2009 23:23:56 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); Mon, 13 Apr 2009 16:23:56 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 13 Apr 2009 16:23:55 -0700
Message-ID: <0C53DCFB700D144284A584F54711EC58070763E3@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <49E3ADA4.1090402@gont.com.ar>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard
Thread-Index: Acm8fmx67kSpMh0eQy6uvI7c9DmPJAAAs1uA
References: <20090402150706.EC83D28C222@core3.amsl.com> <49E3ADA4.1090402@gont.com.ar>
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Fernando Gont <fernando@gont.com.ar>, ietf@ietf.org
X-OriginalArrivalTime: 13 Apr 2009 23:23:56.0028 (UTC) FILETIME=[EA5F93C0:01C9BC8E]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8559; t=1239665036; x=1240529036; c=relaxed/simple; s=sjdkim1004; 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=20[tcpm]=20Last=20Call=3A=20draft-ietf-tc pm-tcpsecure=20(Improving=20TCP's=20Robustness=20to=20Blind= 20In-Window=20Attacks)=20to=20Proposed=20Standard |Sender:=20; bh=W4TnDhGkfo4/yNzocGYS8jG4SM5azoQ4BD+4yVqYf2Q=; b=ARcD9u1fQ79xrHa1gt+QdUwurAlPKIMbVGPCUs6IBzIyBRNpRjPUMgIpga D8o2W/qsKiH078VJthjcH7h5N51mGcvbwuACHx2cZJ4isIRi53LFpyhEd7pn OFsujw0eZUN6sF7VfH4iWki6zXlD3NytLGIqwX/r8hCOaLa/SItXI=;
Authentication-Results: sj-dkim-1; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: tcpm@ietf.org
Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Improving TCP's Robustness to Blind In-Window Attacks) to Proposed Standard
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-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
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>
X-List-Received-Date: Mon, 13 Apr 2009 23:22:46 -0000
Fernando, Thanks for you comments. Pl see responses inline :- > -----Original Message----- > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On > Behalf Of Fernando Gont > Sent: Monday, April 13, 2009 2:25 PM > To: ietf@ietf.org > Cc: tcpm@ietf.org > Subject: Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure > (Improving TCP's Robustness to Blind In-Window Attacks) to > Proposed Standard > > Folks, > > Some last call comments: > > * The document never mentions the fact that this document is > IPR-encumbered. As far as I recall, much of the dicussion > within tcpm with respect to the level of requirements of this > document (MAY/SHOULD/MUST, etc.) had to do with this fact. I > believe the document should include a warning mentioning that > there's an IPR on the document, so that implementers can > consider this point in their decision of whether to implement > the described mechanisms or not. I am confused what to do since this is being brought up very late in the game. That said, there are *many* drafts/RFC's that have IPR on them in the whole of ietf. Do all them explicitly state the IPR link ? I'll leave it to the collective wisdom of the group and the chairs to offer guidance on this matter. > > * The document discusses blind attacks, and to some extent > assesses the difficulty in guessing the four-tuple that > identifies a TCP connection. > However, it does not even mention port randomization, which > is probably the most simple and straightforward approach for > mitigating blind attacks against TCP. This was raised by me Well, the point is that source port randomization is something external like Ipsec and nothing specfic to TCP. TCP will work with or without src port randomization. Now the scope of this document is to improve robustness to TCP esp. in cases where the TCP connection is not protected by other means like TCP MD5 or TCP AO etc., Now this point is very clear in the document. That said I have no issues putting a reference to the port randomization in the document. > and other quite a few times in the tcpm wg list, pre and post > wglc, but this comment was never addressed. It's particularly > curious that port randomization is not mentioned when tsvwg > is working on it (draft-ietf-tsvwg-port-randomization). Yes, you did raise this issue last time, but I did defer it to the WG and did not receive any response, so I simply left it at that. > > * Among the factors that determine how easy these attacks be > exploited is the window size. This document should provide, > at the very least, pointers with advice on what to do with > the tcp window. While quickly skimming through RFC 4953, it It does mentions about the window size relationship, For example in the beginning sections of the document we briefly mention the window size and the # of packets that is required to generate a successful attack. > seems it has some advice on the TCP window. We do offer a > lengthy discussion of this and other issues in > draft-gont-tcp-security and > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf > > * Yet another factor is TCP ISN randomization. At the very > least, this document could/should a pointer to RFC 1948. We > do offer a lengthy discussion of this and other issues in > draft-gont-tcp-security and > http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf Why should it talk about ISN randomization since ISN randomization, is somewhat orthogonal to the type of attack here, it is not even one of the attack vector. We could refer this, but the scope of the current document is about the RST/SYN and Data attacks and mitigations, Since this document generally refers RFC 4953 (which came after this document was written. BTW) I think this should suffice, IMO. > > * Just of the top of my head: Hadn't the BGP spec been > updated so that a well-known port was not required as the > *source* port? Not that I am aware of, I can look it up. > > * The counter-measure of for the SYN-based reset attack may > have missed a common heuristics for the handling of SYN > segments. See pages 86 and > 87 of the UK CPNI paper on TCP security. FWIW, we argue that > the processing of SYN segments proposed in [Ramaiah et al, > 2008] should apply only for connections in any of the > synchronized states other than the TIME-WAIT state. We just followed RFC 793 as the base and the changes are made w.r.t that. TIME-WAIT may be an exception but doesn't RFC 793 already has that language correct? > > * When it comes to TCP-based blind-connection reset attacks, > there's a much more trivial -- yet not discussed before? -- > alternative. See Section 11.1.3 and Section 11.1.4 in > draft-gont-tcp-security and the CPNI paper > (http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf) > These variants should, at the very least, be mentioned and a > pointer provided to them as, at least in theory, are much > easier to exploit. Those sounds like some new proposals (security and precedence) different stacks would have taken different measures to address this issue. Anyways this is something new and hence needs more discussion and evaluation. Has these ideas been submitted in a draft to TCPM? (your recent BCP document tcp-security, covers it ?) > > * When it comes to the data injection attack, Michael > Zalewski sketched another attack vector which may be easier > to exploit. We discuss it in Section 16.2 of > draft-gont-tcp-security and the CPNI doc, along with advice. > IMO, this vector should be mentioned, too. This again is an attack which relies on the IP functionality and not TCP. For example the DF bit can be turned on then there is no fragmentation involved, in any case the current document is not intended as a protection for on-path attackers and not a complete solution for all kinds of off-path attacks (pl note the security considerations section). Also FWIW, our stacks already randomize IPID. Anyways these are clearly outside the scope of the current document, IMO. > > Needless to say, I'm in favor of improving the robustness of > TCP and, IPRs-aside, I'm happy with the implementation of the > counter-measures described in the tcpsecure I-D (all three). Thanks. > > I'm also glad that this doc is getting close to publication. > Five years working on a document is quite a lot of time! Agreed. Esp when it has been running in the internet with multiple vendors supporting these mitigations. -Anantha > (yes, it could have been worse, some might argue). > > Thanks! > > Kind regards, > Fernando Gont > > > > > The IESG wrote: > > The IESG has received a request from the TCP Maintenance and Minor > > Extensions WG (tcpm) to consider the following document: > > > > - 'Improving TCP's Robustness to Blind In-Window Attacks ' > > <draft-ietf-tcpm-tcpsecure-11.txt> as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive comments to > > the ietf@ietf.org mailing lists by 2009-04-16. > Exceptionally, comments > > may be sent to iesg@ietf.org instead. In either case, please retain > > the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-11.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTa > > g=11735&rfc_flag=0 > > > > The following IPR Declarations may be related to this I-D: > > > > https://datatracker.ietf.org/ipr/421/ > > > > > > _______________________________________________ > > IETF-Announce mailing list > > IETF-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org PGP > Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm >
- [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (Impr… The IESG
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Fernando Gont
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Anantha Ramaiah (ananth)
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Lars Eggert
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Fernando Gont
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Brian E Carpenter
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Tom Petch
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Lars Eggert
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Anantha Ramaiah (ananth)
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Fernando Gont
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Anantha Ramaiah (ananth)
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Fernando Gont
- Re: [tcpm] Last Call: draft-ietf-tcpm-tcpsecure (… Anantha Ramaiah (ananth)