[secdir] (no subject)

Sandra Murphy <sandy@sparta.com> Thu, 23 April 2009 18:18 UTC

Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D2793A72E1; Thu, 23 Apr 2009 11:18:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Level:
X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MISSING_SUBJECT=1.762]
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 fyd0Nbj+1y5f; Thu, 23 Apr 2009 11:18:05 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 923D828C133; Thu, 23 Apr 2009 11:17:57 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n3NIJD0i020873; Thu, 23 Apr 2009 13:19:14 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n3NIJC4a025922; Thu, 23 Apr 2009 13:19:12 -0500
Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.126]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Apr 2009 14:19:11 -0400
Date: Thu, 23 Apr 2009 14:19:11 -0400
From: Sandra Murphy <sandy@sparta.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-tcpm-tcpsecure@tools.ietf.org, tcpm-chairs@tools.ietf.org
Message-ID: <Pine.WNT.4.64.0904231357310.900@SANDYM-LT.columbia.ads.sparta.com>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 23 Apr 2009 18:19:11.0578 (UTC) FILETIME=[001F6BA0:01C9C440]
Subject: [secdir] (no subject)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2009 18:18:06 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I know that I am so late with this review as to be make this pro-forma 
only.

I have no serious security considerations with this document.  It presents 
a mitigation technique against a well-known vulnerability in TCP 
processing of RST segments, and the increased concern over that 
the impact of exploits of that vulnerability on Internet infrastructure.

I do have document concerns, which I will mention in general and offer to 
specify more explicitly if deemed valid.

This document is intended to update rfc793.  That means that it should be 
very explicit about what text it is replacing and what the new text is.

The dicussions of interactions between TCP peers are always difficult to 
phrase, as most terms are relative to viewpoint.  The text in some places 
is tough to read - who is the sender, who the receiver, etc.  The text 
also uses a lot of different terms to represent the same entity - remote 
peer, remote end sender, remote TCP endpoint, etc.

The term "initial sequence number" has a special meaning in TCP and should 
be avoided.

The text says that this mitigation SHOULD be used "in devices" which 
typically host apps that are most vulnerable and MIGHT be used elsewhere. 
Is there a suggestion that this would be under application control? 
Chosen by the OS vendor (or device vendor)?  For those who are using 
Quagga routers (routing apps on top of intel boxes running some *ix), 
would this be a socket option?  What's the vision here?

I don't understand some parts of

    All TCP stacks MAY implement the following mitigation.  TCP stacks
    which implement this mitigation MUST add an additional input check to
    any incoming segment.  The ACK value is considered acceptable only if
    it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=
    SND.NXT).  All incoming segments whose ACK value doesn't satisfy the
    above condition MUST be discarded and an ACK sent back.  It needs to
    be noted that RFC 793 on page 72 (fifth check) says: "If the ACK is a
    duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK
    acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an
    ACK, drop the segment, and return."  This mitigation makes the ACK
    check more stringent since any ACK < SND.UNA wouldn't be accepted,
    instead only ACKs which are in the range ((SND.UNA - MAX.SND.WND) <=
    SEG.ACK <= SND.NXT) gets through.

Seems that SEG.ACK could fall between the SND.UNA and SND.UNA - 
MAX.SND.WND, in which case the new code accepts segments that the existing 
text says "it is ignored".  I would read the 793 text as the *ACK* is 
ignored, which means the new text would accept (and act on) ACKs that are 
presently ignored.  But looking at existing TCP code, it looks like people 
have interpreted "it is ignored" as the *segment* is ignored, i.e., 
dropped.  In that case, this new text is accepting segments that in 
existing implementations would be dropped.  Is that the intent?  (Note: I 
could be easily wrong about the tcp_input code.)

There are some language errors (missed words, punctuation, all that sort 
of boring stuff) that I could point out, or you could rely on the RFC 
editor to find.


--Sandy