Re: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06
Andrew Yourtchenko <ayourtch@cisco.com> Wed, 22 September 2010 22:32 UTC
Return-Path: <ayourtch@cisco.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 3D3A63A6918; Wed, 22 Sep 2010 15:32:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 uDE8KHUmBcBt; Wed, 22 Sep 2010 15:32:24 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8AD2C3A6835; Wed, 22 Sep 2010 15:32:24 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o8MMT4Pa027524; Thu, 23 Sep 2010 00:29:04 +0200 (CEST)
Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o8MMSxnw014263; Thu, 23 Sep 2010 00:29:00 +0200 (CEST)
Date: Thu, 23 Sep 2010 00:28:59 +0200
From: Andrew Yourtchenko <ayourtch@cisco.com>
To: Fernando Gont <fernando@gont.com.ar>
In-Reply-To: <4C91C9EE.1000200@gont.com.ar>
Message-ID: <Pine.GSO.4.64.1009222300180.26448@sweet-brew-5.cisco.com>
References: <2234.1284367866.672579@puncture> <4C91C9EE.1000200@gont.com.ar>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700
Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, Apps Area Review List <apps-review@ietf.org>, The IESG <iesg@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [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: Wed, 22 Sep 2010 22:32:27 -0000
Hi David, sorry for the delay with the reply - I was off the grid for a couple of weeks due to vacation. On Thu, 16 Sep 2010, Fernando Gont wrote: [snip] >> 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. >> I comment on this below at [*] >> 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. Could you unicast me the URL where you saw it, so I can work to get it fixed ? The ones in the command reference for the ASA talk about tcp/513, which is rlogin, e.g.: http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/uz.html#wp1591004 > > I leave this one for Andrew to answer ;-) > > I'd just note that the reason for which Cisco Pix is referenced is > probably because it's a widely deployed device that scrubs urgent > indications. (i.e., "this thing is widely deployed"). > Exactly. [*] - given the contents of the command reference above - would it correspond to what you had in mind if we give e.g. the link above to one of the command references ? > >> 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. > > Would the re-written text I indicated above do, or do you think we > should get into the specifics of what the urgent mechanism is used for > in FTP and telnet? > > > >> - A more detailed description of SeolMa, and its implications, would be >> useful, and I think required in the Security Considerations section. > > Please let me know if the change indicated above would do. > > >> - I feel that further consideration of the proposed solution to SeolMa >> is warranted. > > You mean what we propose to fix this NIDS evasion technique? SeolMa was in fact one of the initial triggers of this work, though we deemed the NIDS problem as not something practically solvable in a clean way. I'll include the logic below: First the "classic" NIDS: The setup is as follows: Alice --+-- Eva | Nick Eva is trying to exploit Alice using the SeolMa technique. Regardless of the setup, Nick can not do a lot anyway to help - maybe send a reset based on some heuristic, however the damage is possibly already done, might depend on the timing. So we consider a more interesting case of an "inline" setup: Alice -- Nick -- Eva Here, Nick can have the power to reliably do something. But he needs to consider the following degrees of freedom that Alice has: * /proc/sys/net/ipv4/tcp_stdurg setting. This alters the behaviour box-wide, and Nick would need to know the value of this setting (manual configuration), to understand in which of the two ways to interpret the data. * The timing also plays a role, so Nick would need to somehow normalize the timing of the packets before passing them on to Alice. This can either impact the TCP connection itself (if done with bigger safety margins), or be again unreliable. Or the packets need to be sanitized. * Meantime, Alice might have learned about the SO_OOBINLINE and added that to the code of the next version of the application - which gives another point of manual configuration for Nick. Based on that, there are some approaches to tackling this: * Nick manually configures his behavior to match the Alice's and then does the analysis based on that, trying to guess what Alice's stack would do - and then pass the "sanitized" packets to Alice. ==> while technically this looks sound, I think expecting the end user en masse to know about the details about SO_OOBINLINE/tcp_stdurg is impractical. Even if the "security" folks might know it, in a lot of organizations they are different from "application" folks - the latter not possessing the low-level transports knowledge. Side effect of this is the increase of the complexity of the task that Nick would do, therefore increasing the chances of it not emulating the Alice's behaviour correctly. * Nick can evade the evasion by clearing the URG flag - breaking the assumptions of Eve about the processing of the data by Alice. ==> This requires zero configuration, creates loud noise in the logs of Alice due to incorrect input, but breaks the apps that rely on URG mechanism during the legitimate operation. * Nick can be aggressive on those streams that he knows would not use urgent mechanism (e.g. HTTP), and try to handle the ones that may use it, in a more graceful manner. ==> This looks like a possibly ideal scenario, however, from the security point of view for the applications that use the urgent mechanism, it would need to be treated as the first one - i.e. require explicit manual configuration. So the approach with simply clearing the URG looks like the simplest of all from several viewpoints (reliability, and maintenance overhead). Hopefully this gives more details, would be very useful to know your opinion on the above. Thank you very much! kind regards, andrew > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > >
- [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