ietf
[Top] [All Lists]

Re: ECN and ISOC... tcptraceroutes needed

2002-08-02 17:56:27
Sally

Would you be kind enough to contact minerva (support(_at_)minerva(_dot_)net) and
ISOC Anne Shroeder (anne(_at_)isoc(_dot_)org) with this information and may be
provide them with some help.

As you are one of the authors of ECN, I think your help would be more
than appreciated and would give a case study on how to fix this...

Thanks in advance
Franck(_at_)sopac(_dot_)org

On Sat, 2002-08-03 at 11:25, Sally Floyd wrote:

    >Minerva, the ISP of ISOC has been alerted and are working on the problem
    >but cannot locate exactly where is the problem, if you have any
    >information on where ECN packets are discarded please provide this
    >information to support(_at_)minerva(_dot_)net add [HelpDeskTicket=12181] 
at the end
    >of the subject.
    >
    >I think you may have more tools htan me to locate the faulty
    >router/firewall/host?
    >
    >Thanks for helping locate the problem.
    
    The "ECN-under-Linux Unofficial Vendor Support Page" web page 
    at "http://gtf.org/garzik/ecn/";  lists the known vendor equipment
    that has problems, with pointers to the bug-fixes provided by those
    vendors.
    
    There is also an internet-draft about this problem,
    "Inappropriate TCP Resets Considered Harmful", at
    "http://www.ietf.org/internet-drafts/draft-floyd-tcp-reset-04.txt";.
    This was approved to become a BCP on June 11.
    
    - Sally
    http://www.icir.org/floyd/
    
    From draft-floyd-tcp-reset-04.txt, for background history:
    
       Unfortunately, misconceived security concerns are one of the reasons
       for the problems described in this document in the first place.  An
       August, 2000, article on "Intrusion Detection Level Analysis of Nmap
       and Queso" described the port-scanning tool Queso as sending SYN
       packets with the last two Reserved bits in the TCP header set, and
       said the following:  "[QUESO] is easy to identify, if you see [these
       two Reserved bits and the SYN bit] set in the 13th byte of the TCP
       header, you know that someone has malicious intentions for your
       network."  As is documented on the TBIT Web Page, the middleboxes
       that block SYNs using the two ECN-related Reserved flags in the TCP
       header do not block SYNs using other Reserved flags in the TCP
       header.
    
       One lesson appears to be that anyone can effectively ``attack'' a new
       TCP function simply by using that function in their publicly-
       available port-scanning tool, thus causing middleboxes of all kinds
       to block the use of that function.
    
    
    
<Prev in Thread] Current Thread [Next in Thread>