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

[Fernando Gont <[e-mail]>]

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?

Thanks!

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