Fernando Gont wrote:
At 09:49 17/02/2005 -0800, Joe Touch wrote:
I still, however, disagree in principle with TCP processing the header
in the context of a connection, since in many cases (excepting only the
port error case, MAYBE), it is not generated by TCP on the other end,
and so it isn't issued in the context of a connection necessarily.
For hard errors, this would amplify the impact of the ICMP attacks, and
would make life much harder by not allowing us to do the TCP SEQ check.
Not to mention the PMTUD attack. If you are not allowed to perform the
TCP SEQ, then performing the PMTUD attack is a trivial issue. You should
not be surprised about having script kiddies attacking BGP connections
from core routers.
(Also, IMHO, ICMP "don't fragment" are issued in the context of a
connection. Think about per-flow load-sharing, etc.)
FWIW, keep in mind that the recent RST attacks basically show that this
SEQ num checking is a stopgap, and anyone who really wants to shut you
down doesn't have to send many ICMPs to do so.
I.e., source/dest IP addresses and port numbers provide more protection
already than the seq space does, since the seq space can be effectively
flooded for the kind of connections that are susceptible:
those that we can guess the src IP, dst IP, src port, dst port
Far as we know right now, these are basically BGP attacks, for which E2E
encrypted tunnels provide ICMP protection anyway.
This last point, IMO, can be summarized as:
we're not going to force ICMPs to be at the end of the RCV
window (regardless of whether we do so with RSTs, we can't here)
if we don't, and if that means unsecured BGPs are still
vulnerable, why do we NEED this mod?
tcpm mailing list