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.

Summary:



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.

Background:



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  


case.




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.




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  


section.






- I feel that further consideration of the proposed solution to  


SeolMa is warranted.




Dave.