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

Fernando Gont <> Thu, 16 September 2010 08:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE00C3A68D3; Thu, 16 Sep 2010 01:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.381
X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ikovs6iBZzvn; Thu, 16 Sep 2010 01:29:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 50B7F3A68C0; Thu, 16 Sep 2010 01:29:40 -0700 (PDT)
Received: by gwb11 with SMTP id 11so199710gwb.1 for <multiple recipients>; Thu, 16 Sep 2010 01:30:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=9e/H+/CVfJsWRQroIrwzifStSDjbbxIXrUuTDDAqoY0=; b=NSwApBHsVg5gKDM6U7MNMuPg0BT2C+hIwcvPqU7pm/NU+qUTB7KSo1raYcLU+5omHn TwwLZ3epKXEdusWl0F4Hi7EOJgkF0UQAaq2Pe5UIOQJEvBhti46YVUZedqLTnS7MZKQv zNGFKa9+O73Sid0eBjtnJVlkN3s7N5U0SpYyw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=A5qCvmDgQDgSR/Gz0d3V/WILSK/PLk9KheVrwTWKPdku3jtwZYoL20+te9IqYTeDug P0LTQVtombISe8D7rUZYfwdzTLR8jP7c5HmCnQM3Xb95CBnC3FH1F6nXul5qUdVAlzUV PYyRKbFOEoOM7ctAvvG9eeStPQyMJd/QMrPeg=
Received: by with SMTP id d18mr3309701ybm.277.1284625805197; Thu, 16 Sep 2010 01:30:05 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id t20sm7241104ybm.17.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Sep 2010 01:30:03 -0700 (PDT)
Sender: Fernando Gont <>
Message-ID: <>
Date: Thu, 16 Sep 2010 04:40:30 -0300
From: Fernando Gont <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Dave Cridland <>
References: <2234.1284367866.672579@puncture>
In-Reply-To: <2234.1284367866.672579@puncture>
X-Enigmail-Version: 1.1.1
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc:, Security Area Directorate <>, The IESG <>, Apps Area Review List <>
Subject: Re: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Sep 2010 08:29:42 -0000

Hi, David,

Thanks so much for your feedback!

Please find my comments inline....

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

Actually, support for urgent data is not removed. We simply discourage
its use.

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

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


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

Not that I like it... but in practice, it probably is. As you correctly
mentioned before, when multiple segments are in flight, it becomes
virtually impossible for a NIDS to be able to do its job.

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

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").

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


Kind regards,
Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1