Skip to main content

Last Call Review of draft-ietf-tcpm-urgent-data-

Request Review of draft-ietf-tcpm-urgent-data
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-09-21
Requested 2010-09-11
Authors Fernando Gont , Andrew Yourtchenko
I-D last updated 2010-09-15
Completed reviews Secdir Last Call review of -?? by Dave Cridland
Assignment Reviewer Dave Cridland
State Completed
Request Last Call review on draft-ietf-tcpm-urgent-data by Security Area Directorate Assigned
Completed 2010-09-15
I have reviewed this document as part of the security directorate's  

ongoing effort to review all IETF documents being processed by the  

IESG.  These comments were written primarily for the benefit of the  

security area directors.  Document editors and WG chairs should treat  

these comments just like any other last call comments.

In addition, I have been selected as the Apps Reviewer for this  

document. These comments are similarly written for the benefit of  

apps area directors, and document editors and WG chairs should treat  

these comments just like any other last call comments.

I have not made any distinction between the comments.


Whilst I agree with the essential premise - that TCP URG is  

implemented in a different way to that specified, and should be  

homogenized in favour of the deployed implementations - I feel that  

both SeolMa and the proposed solution needs to be expanded upon.

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.

Specific recommendations are at the bottom.


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

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)

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  



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.

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.

- A more detailed description of SeolMa, and its implications, would  

be useful, and I think required in the Security Considerations  


- I feel that further consideration of the proposed solution to  

SeolMa is warranted.