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

"Polk, William T." <> Wed, 22 September 2010 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BCF13A69DA; Wed, 22 Sep 2010 06:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.534
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R7KPz4hp0eoP; Wed, 22 Sep 2010 06:23:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A13833A69C9; Wed, 22 Sep 2010 06:23:05 -0700 (PDT)
Received: from ( []) by (8.13.1/8.13.1) with ESMTP id o8MDN5L2024652; Wed, 22 Sep 2010 09:23:06 -0400
Received: from ([fe80::41df:f63f:c718:e08]) by ([]) with mapi; Wed, 22 Sep 2010 09:23:05 -0400
From: "Polk, William T." <>
To: Fernando Gont <>, Dave Cridland <>
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: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en
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
Cc: "" <>, Apps Area Review List <>, The IESG <>, Security Area Directorate <>
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: 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" <>; 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: ||
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1