[secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06

Dave Cridland <dave.cridland@isode.com> Mon, 13 September 2010 08:52 UTC

Return-Path: <dave.cridland@isode.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 64A9C3A6925; Mon, 13 Sep 2010 01:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level:
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74]
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 QGEDmSGytdbz; Mon, 13 Sep 2010 01:52:20 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 214EB3A67EC; Mon, 13 Sep 2010 01:52:20 -0700 (PDT)
Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TI3l=wBIEKiC@rufus.isode.com>; Mon, 13 Sep 2010 09:51:12 +0100
X-SMTP-Protocol-Errors: NORDNS
Message-Id: <2234.1284367866.672579@puncture>
Date: Mon, 13 Sep 2010 09:51:06 +0100
From: Dave Cridland <dave.cridland@isode.com>
To: The IESG <iesg@ietf.org>, <draft-ietf-tcpm-urgent-data.all@tools.ietf.org>, Apps Area Review List <apps-review@ietf.org>, Security Area Directorate <secdir@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-transfer-encoding: quoted-printable
Subject: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06
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: Mon, 13 Sep 2010 08:52:21 -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.

In addition, I have been selected as the Apps Reviewer for this  
document. These comments are similarly written for the benefit of  
apps area directors, and document editors and WG chairs should treat  
these comments just like any other last call comments.

I have not made any distinction between the comments.

Summary:

Whilst I agree with the essential premise - that TCP URG is  
implemented in a different way to that specified, and should be  
homogenized in favour of the deployed implementations - I feel that  
both SeolMa and the proposed solution needs to be expanded upon.

Simply dropping TCP Urgent data facilities removes an aspect of TCP  
which - whilst not commonly used in most modern protocols - is  
nevertheless still used for useful gain in FTP and TELNET.

Specific recommendations are at the bottom.

Background:

The TCP urgent mechanism, as implemented, means that a single octet  
is lost when the receiver handles the last "Urgent" data section.  
Thus particularly when multiple urgent data segments are "in flight",  
it becomes difficult to guess which octets will be lost by the  
receiver. The SeolMa attack effectively uses these lost octets to pad  
strings used in TCP based application protocols, thus defeating naïve  
NIDS pattern matching.

There is no discussion in the draft about SeolMa, indeed there isn't  
even a mention of it in the Security Considerations. It's not clear  
to me if the recommendation to use SO_OOBINLINE would have an effect  
here - my gut feeling is that it would defeat SeolMa by making these  
"lost" octets part of the normal data flow again.

Cisco's solution relies on simply forcing urgent data to be  
non-urgent, which will have knock-on effects on TELNET and FTP by  
default. It's not clear to me from this document (including reading  
the references)

By instituting a blanket ban, in effect, for TCP Urgent data, this  
effectively deprecates the entire mechanism. This may prove to be the  
only solution, however my general feeling is that this may not be the  
case.

Niggle:

The Cisco-PIX reference does not describe the TCP Urgent behaviour  
except by implication (it mentions adding rules to allow its use for  
TELNET and FTP-PI, but that's it). I have a personal distaste for  
product placement in RFCs, and would prefer that this reference  
pointed at least at a Cisco paper describing default behaviour, etc.

As an aside, the Cisco instructions actually show the user how to  
enable urgent data on FTP-DTP, rather than FTP-PI, which is incorrect.

Specific Recommendations:

- An informative reference to FTP and TELNET, noting how and why the  
URG pointer is used, would make it more obvious what is lost here.

- A more detailed description of SeolMa, and its implications, would  
be useful, and I think required in the Security Considerations  
section.

- I feel that further consideration of the proposed solution to  
SeolMa is warranted.

Dave.