[...]
If exploited, the vulnerability could allow an attacker to create a Denial of Service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the duration of the TCP connection, with a further dependency on knowledge of the network (IP) addresses of the end points of the TCP connection.
The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability.
[...]
There is a potential impact on other application protocols such as DNS (Domain Name System) and SSL (Secure Sockets Layer) in the case of zone transfers and ecommerce transactions respectively, but the duration of the sessions is relatively short and the sessions can be restarted without medium term unavailability problems. In the case of SSL it may be difficult to guess the source IP address.
[...]
The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.
The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.
[...]
TCP also provides a number, called an acknowledgement number, that is used to indicate the sequence number of the next packet expected. The packets are reassembled by the receiving TCP implementation only if their sequence numbers fall within a range of the acknowledgement number (called a "window"). The acknowledgement number is not used in a RST packet because a reset does not expect a packet in return. (To be completely accurate, although the last statement is true for a RST packet without the ACK flag set, used to indicate that a TCP port is closed, a RST/ACK is used to terminate an active connection in the event of error. In a RST/ACK packet an acknowledgement number is included in the packet, although it is not checked by the receiving TCP implementation.)
[...]
In the absence of vendor patching of the TCP implementation, the following are general mitigating steps:
* Implement IP Security (IPSEC) which will encrypt traffic at the network layer, so TCP information will not be visible
* Reduce the TCP window size (although this could increase traffic loss and subsequent retransmission)
* Do not publish TCP source port information
- Sandip
-- Sandip Bhattacharya sandip (at) puroga.com Puroga Technologies Pvt. Ltd. Work: http://www.puroga.com Home: http://www.sandipb.net
GPG: 51A4 6C57 4BC6 8C82 6A65 AE78 B1A1 2280 A129 0FF3
_______________________________________________ ilugd mailinglist -- [EMAIL PROTECTED] http://frodo.hserus.net/mailman/listinfo/ilugd Archives at: http://news.gmane.org/gmane.user-groups.linux.delhi http://www.mail-archive.com/[EMAIL PROTECTED]/
