It would also make it easier to nuke vital network communications paths. Thanks, but I'll pass.
Well, do have a valid point? Let's see... If we use the condition: sk->state == TCP_SYN_RECV && buf->sk->saddr == icmp->sk->daddr Then any connection in the SYN state receiving an UNREACH that matched one of the active addresses in the queue.... translates to: If you are an attacker and know your target host is about to set up a connection with a particular host address, then if you timed it exactly right you could nuke the connection during one state of the TCP connection, SYN_RCVD. But, if the ICMP UNREACHABLE is set with the same sequence number as the actual bogus SYN/ACK packet then the condition becomes: sk->state == TCP_SYN_RECV && buf->sk->saddr == icmp->sk->daddr && buf->sk=seq_numb == icmp->sk->seq_num Out hero Rich Steven's says in 'The Protocols' the identifier field and the sequence number can be anything the sender wants to match the request and the reply.... pg. 71 aro, So, if you can guess sequence numbers, ip addresses, and the exact state on the connection..... er.. I think we can sleep okay with that security for a little while.... don't you? Thanks for the feedback, BTW. Tim PS; Here are some of my klog stuff that was playing during this email based on a yet to work defense... for those of you who do not have the time to enjoy hacking TCP: Oct 3 19:01:30 linux kernel: TCP CONN: BACKLOG = 7, MAXBACK = 10 Oct 3 19:01:30 linux kernel: TCP DROP: STATE = 3, ADDRESS = 00fbcd34 Q = 6 Oct 3 19:01:30 linux kernel: TCP CONN: BACKLOG = 7, MAXBACK = 10 Oct 3 19:01:30 linux kernel: TCP DROP: STATE = 3, ADDRESS = 00fbcd34 Q = 3 Oct 3 19:02:42 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 10 Oct 3 19:03:21 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5 Oct 3 19:04:29 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5 Oct 3 19:10:09 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 10 Oct 3 19:18:13 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5 Oct 3 19:20:57 linux kernel: TCP CONN: BACKLOG = 0, MAXBACK = 5