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.