Re: [tcpm] tcpsecure recommendations

Mark Allman <mallman@icir.org> Mon, 11 February 2008 03:54 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 98C973A69FC; Sun, 10 Feb 2008 19:54:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.422
X-Spam-Level:
X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 c7WfILF-qvbs; Sun, 10 Feb 2008 19:54:21 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A0BE3A68EB; Sun, 10 Feb 2008 19:54:21 -0800 (PST)
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 1146C3A68EB for <tcpm@core3.amsl.com>; Sun, 10 Feb 2008 19:54:20 -0800 (PST)
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 vnH0+SIiKNcH for <tcpm@core3.amsl.com>; Sun, 10 Feb 2008 19:54:19 -0800 (PST)
Received: from pork.ICSI.Berkeley.EDU (pork.ICSI.Berkeley.EDU [192.150.186.19]) by core3.amsl.com (Postfix) with ESMTP id 197633A698D for <tcpm@ietf.org>; Sun, 10 Feb 2008 19:54:19 -0800 (PST)
Received: from guns.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by pork.ICSI.Berkeley.EDU (8.12.11.20060308/8.12.11) with ESMTP id m1B3tjRV016252; Sun, 10 Feb 2008 19:55:45 -0800
Received: from lawyers.icir.org (adsl-69-222-35-58.dsl.bcvloh.ameritech.net [69.222.35.58]) by guns.icir.org (Postfix) with ESMTP id 0F29814FD881; Sun, 10 Feb 2008 22:55:40 -0500 (EST)
Received: from lawyers.icir.org (localhost [127.0.0.1]) by lawyers.icir.org (Postfix) with ESMTP id 7551C36A3CC; Sun, 10 Feb 2008 22:54:41 -0500 (EST)
To: "Anantha Ramaiah (ananth)" <ananth@cisco.com>, "Joe Touch" <touch@ISI.EDU>, tcpm@ietf.org
From: Mark Allman <mallman@icir.org>
In-Reply-To: <0C53DCFB700D144284A584F54711EC5804AC0A08@xmb-sjc-21c.amer.cisco.com>
Organization: International Computer Science Institute (ICSI)
Song-of-the-Day: It's Money That Matters
MIME-Version: 1.0
Date: Sun, 10 Feb 2008 22:54:41 -0500
Message-Id: <20080211035441.7551C36A3CC@lawyers.icir.org>
Subject: Re: [tcpm] tcpsecure recommendations
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mallman@icir.org
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <http://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: <http://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1561016644=="
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

Folks-

We do not need more unending debate on this subject.  We need to make a
collective decision about how strongly to recommend these mitigations.
I want to encourage folks to please poke their head up and voice their
opinion on this question (my original request is below for reference).
And, I would also like to ask folks to hold off on re-debating the
issues again.  Certainly, if you feel you have a *new* opinion to offer
or the AS has brought something *new and different* to the fore of your
thinking, by all means please raise the issue.

Thanks,
allman





Folks-

It'd be good to get some opinions on the new tcpsecure version and get
it finished.  The sticking point on this document is how strongly to
recommend TCP stacks implement / use the three mitigations in the draft
(to spoofed RSTs, SYNs and data segments).  We had a discussion about
this in Chicago and also on the list.  Since it seemed that we were not
converging because there was not WG-wide agreement on the scope of the
document we asked the authors to generate an applicability statement.
They did that, per a previous email from Anantha.  The AS reads:

    The mitigations presented in this document talks about some known
    in-window attacks and the solutions to the same. The mitigations
    suggested in this draft SHOULD (RECOMMENDED) be implemented in
    devices where the TCP connections are most vulnerable to the attacks
    described in this document.  Some examples of such TCP connections
    are the ones that tend to be long-lived where the connection end
    points can be determined, in cases where no auxiliary anti-spoofing
    protection mechanisms like TCP MD5 can be deployed. TCP secure MAY
    (OPTIONAL) be implemented in other cases.

We can recommend each of mitigations with a MAY, SHOULD or MUST.  In
Chicago we winnowed the proposals to three three:

    (1) RST spoofing mitigation: MAY
        SYN spoofing mitigation: MAY
        data injection mitigation: MAY

    (2) RST spoofing mitigation: SHOULD
        SYN spoofing mitigation: SHOULD
        data injection mitigation: SHOULD

    (3) RST spoofing mitigation: SHOULD
        SYN spoofing mitigation: SHOULD
        data injection mitigation: MAY

Nobody has advocated for other permutations of recommendations
(although, clearly if people like some different combination they should
advocate away!).  

Can folks please weigh in on their feeling about how strongly we should
recommend these mitigations given the AS above?  It'd be great to get
this document moving and we're sort of stuck here.

Thanks,
allman




_______________________________________________
tcpm mailing list
tcpm@ietf.org
http://www.ietf.org/mailman/listinfo/tcpm