[secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06
Dave Cridland <firstname.lastname@example.org> Mon, 13 September 2010 08:52 UTC
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-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74]
Received: from mail.ietf.org ([188.8.131.52]) 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 [184.108.40.206]) by core3.amsl.com (Postfix) with ESMTP id 214EB3A67EC; Mon, 13 Sep 2010 01:52:20 -0700 (PDT)
Received: from puncture ((unknown) [220.127.116.11]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TI3l=wBIEKiC@rufus.isode.com>; Mon, 13 Sep 2010 09:51:12 +0100
Date: Mon, 13 Sep 2010 09:51:06 +0100
From: Dave Cridland <email@example.com>
To: The IESG <firstname.lastname@example.org>, <email@example.com>, Apps Area Review List <firstname.lastname@example.org>, Security Area Directorate <email@example.com>
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Subject: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:email@example.com?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.
- [secdir] SecDir/Apps Review of draft-ietf-tcpm-ur… Dave Cridland
- Re: [secdir] SecDir/Apps Review of draft-ietf-tcp… Fernando Gont
- Re: [secdir] SecDir/Apps Review of draft-ietf-tcp… Polk, William T.
- Re: [secdir] SecDir/Apps Review of draft-ietf-tcp… Andrew Yourtchenko