[Snort-users] RE: Castor's use of "ECN" shut-off
Novak, Judy H.
Judy.Novak at ...383...
Fri Sep 15 08:49:09 EDT 2000
As far as the false positives for the 2 high-order TCP reserved bits due to
Explicit Congestion Notification (ECN) - looking at RFC 2481, it appears
some validation can be done to determine if this is really ECN traffic and
not "stealth" scanning. In order for ECN to work, the ECN-Capable Transport
(ECT) bit has to be set by the sender to indicate that the endpoints are ECN
capable. This bit is found in the TOS byte (0x02 bit - previously minimize
cost bit). So, when a TCP reserved bit is set, this IP bit should also be
set in order for this to be a valid ECN indication.
Also, a couple of other conditions must exist too for this to be ECN. The
only time that both TCP reserved bits would be set is on the initial SYN.
This indicates that the transport layer is ECN-capable. After the three-way
handshake, the 0x40 bit should be set alone to alert the sender that
congestion was detected, and the 0x80 bit should be set alone to inform the
receiver that the congestion window was reduced in response to the
congestion notification. So, these are additional conditions that could be
used to determine if the reserved bits are set because of ECN or "stealth"
Johns Hopkins University Applied Physics Lab
Phil Wood wrote:
> Folks, the included message explains why I was getting some alerts from
> portscan due to RESERVEDBITS set:
> Sep 8 00:19:40 x.x.x.x:1760 -> y.y.y.y:80 SYN 21S***** RESERVEDBITS
> I had read the source for tcpdump and found reference to RFC2481 which
> mentioned the reserved bits. But, I didn't know it was in "production"
> So, should one ignore these, at least at the "email/paging" level?
> Phil Wood, cpw at ...440...
> Subject: Castor's use of "ECN" shut-off
> Date: Mon, 11 Sep 2000 17:16:14 -0500 (CDT)
> From: "B. Galliart" <bgallia at ...442...>
> To: "Hammerle, Tye F." <Tye.F.Hammerle at ...443...>
> CC: Phil Wood <cpw at ...440...>, bmontes at ...444...,
> Richard Riehle <rriehle at ...442...>
> This is the results of my research into the unusual behavior of Castor:
> Last week, as a work-around to problems with the Loyola network, we
> upgraded Castor (one of our mail servers) to Linux kernel version
> 2.4.0-test7. This kernel, by default, includes an implimentation of ECN
> (Explicit Congestion Notification), also known as RFC 2481 . ECN is
> also promoted by Cisco in their _Internet_Protocol_Journal_ as a method of
> improving TCP performance . However, some IDS and firewall systems
> appear to expect strict adherence to RFC 793  which state that the bits
> used for ECN "must be zero" (since they where reserved for future
> use). Among these products includes Cisco's own PIX firewall and while
> Cisco's IPJ promotes the support of ECN, there is nothing in release notes
> for PIX IOS 5.1 or IOS 5.2 that indicate that Cisco itself is supporting
> ECN. The maintainers of the Linux kernel seem to be aware of the problem
> and discussion has already been underway on the kernel developer's mailing
> list . In the mean time, support of ECN/RFC 2481 will remain turned
> off on Castor. Also, there is no reason at this time to believe that
> someone comprised the administrative access needed to forge their own
> non-standard TCP header from Castor.
> Ben Galliart
> Information Technologies
> Loyola University Chicago
>  http://www.faqs.org/rfcs/rfc2481.html
>  http://www.cisco.com/warp/public/759/ipj_3-2/ipj_3-2_tcp.html
>  http://www.faqs.org/rfcs/rfc793.html
>  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0009.1/index.html
roesch at ...421...
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
More information about the Snort-users