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

"Polk, William T." <william.polk@nist.gov> Wed, 22 September 2010 13:23 UTC

Return-Path: <william.polk@nist.gov>
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 0BCF13A69DA; Wed, 22 Sep 2010 06:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.534
X-Spam-Level:
X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 R7KPz4hp0eoP; Wed, 22 Sep 2010 06:23:06 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id A13833A69C9; Wed, 22 Sep 2010 06:23:05 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o8MDN5L2024652; Wed, 22 Sep 2010 09:23:06 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 22 Sep 2010 09:23:05 -0400
From: "Polk, William T." <william.polk@nist.gov>
To: Fernando Gont <fernando@gont.com.ar>, Dave Cridland <dave.cridland@isode.com>
Date: Wed, 22 Sep 2010 09:23:03 -0400
Thread-Topic: SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06
Thread-Index: ActVeWYs8zn5Bzk5TdCwDvjeBWZXwwE3+Kfw
Message-ID: <C8BF7B77.1CBD7%wpolk@nist.gov>
In-Reply-To: <4C91C9EE.1000200@gont.com.ar>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: william.polk@nist.gov
Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" <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 13:23:07 -0000

Hi Fernando,

My comments inline, text pruned to those issues I am responding to...


On 9/16/10 3:40 AM, "Fernando Gont" <fernando@gont.com.ar>; wrote:

 
>> 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.
> 
> The security considerations does mention the problem of NIDS-evasion,
> although it only focuses on the semantics of the UP (but does not
> consider the OOB vs. in-band thing). Would re-writing the SecCons as
> follows address this point?:
> 
> ---- cut here ----
> Multiple factors can affect the data flow that is actually delivered to
> an application when the TCP urgent mechanism is employed; namely, the
> two possible interpretations of the semantics of the Urgent Pointer in
> current implementations (e.g., depending on the value of the tcp_stdurg
> sysctl), the possible implementation of the urgent mechanism as an
> Out-Of-Band (OOB) facility (vs. in-band as intenteded by the IETF
> specifications), and middle-boxes (such as packet scrubbers) or the
> end-systems themselves that could cause the "urgent data" to be
> processed "in band". This might make it difficult for a Network
> Intrusion Detection System (NIDS) to track the application-layer data
> transferred to the destination system, and thus lead to false negatives
> or false positives in the NIDS [CPNI-TCP] [phrack].
> ---- cut here ----
> 
I think this is a helpful change.

> 
>> 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.
> 
> This wouldn't help for the challenge that NIDS face. This just helps in
> terms of interoperability: i.e., applications should still work if those
> "urgent data" are delivered in-band (whether because of setting
> SO_OOBINLINE or because a packet scrubber cleared the URG bit).
> 
> 
> 
>> 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)
> 
> How about if I replace this sentence of the SecCons:
> 
> ---- cut here ----
> However, this
>    might cause interoperability problems or undesired behavior in the
>    applications running on top of TCP.
> ---- cut here ----
> 
> with this one:
> 
> ---- cut here ----
> However, this might cause interoperability problems or undesired
> behavior in those applications that rely on the TCP urgent mechanism,
> such as Telner [telnet] and FTP [ftp]
> ---- cut here ----
> 
> ?
I think this is also a helpful change.
> 
> 
>> 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?
> 
> 
It might be worth highlight FTP and TELNET in Section 5, since these are
evidently common applications that use the urgent data feature.
> 
>> - 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?
> 

At a minimum, I think the implications of this document and any impact on
SeolMa are needed to complete the security considerations section.

> 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
> 
> 
> 
> 
> 

Thanks,

Tim