[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
- [secdir] (no subject) Eric Rescorla
- Re: [secdir] [Sipping] draft-wing-sipping-srtp-ke… Hadriel Kaplan
- Re: [secdir] [Sipping] draft-wing-sipping-srtp-key Dan Wing
- [secdir] (no subject) Sandra Murphy
- [secdir] (no subject) Hilarie Orman
- Re: [secdir] SecDir review of draft-ietf-l3sm-l3v… kathleen.moriarty.ietf