Date: Mon, 3 Jan 2005 01:31:29 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: net@freebsd.org Subject: Fixing "Slipping in the window" before 4.11-release Message-ID: <20050103012325.A62262@odysseus.silby.com>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-127286633-1104737489=:62262 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed With re's permission, I'm going to commit FreeBSD's fix for the RST part of the slipping in the window attack to 4.11 in the next few days. That's not a big deal, we seem to have an acceptable solution there. (See tcp_input.c rev 1.235 for more info.) The SYN side of the equation, however, is a bit more tricky. The proposed RFC recommends ACKing SYN packets in the window, just like we do to SYN packets to the left of the window right now. For the life of me, I can't figure out why SYN packets (other than delayed retransmissions of the original SYN) would ever show up once a connection is in the ESTABLISHED state. So, I'm proposing the attached patch, which simply ignores any packet with the SYN flag on it while a connection is in the ESTABLISHED state. This means that SYN packets left of the window will no longer receive an ACK, and SYN packets in the window will no longer reset the connection. In all states other than ESTABLISHED, SYN packets are handled as they were before, in case there's some edge case where that could happen. What are people's thoughts on this? I'm especially interested how stateful firewalls like IPF or PF would handle such a situation. How do they respond to unexpected SYN packets? Mike "Silby" Silbersack --0-127286633-1104737489=:62262 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="tcp_input.c-insecure_syn.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20050103013129.F62262@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="tcp_input.c-insecure_syn.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQvdGNwX2lucHV0 LmMgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lucHV0LmMNCi0tLSAvdXNy L3NyYy9zeXMub2xkL25ldGluZXQvdGNwX2lucHV0LmMJTW9uIEphbiAgMyAw MToxMTo0MCAyMDA1DQorKysgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lu cHV0LmMJTW9uIEphbiAgMyAwMToxNzowMyAyMDA1DQpAQCAtMTM2LDYgKzEz NiwxMSBAQA0KICAgICAmdGNwX2luc2VjdXJlX3JzdCwgMCwNCiAgICAgIkZv bGxvdyB0aGUgb2xkIChpbnNlY3VyZSkgY3JpdGVyaWEgZm9yIGFjY2VwdGlu ZyBSU1QgcGFja2V0cy4iKTsNCiANCitzdGF0aWMgaW50IHRjcF9pbnNlY3Vy ZV9zeW4gPSAwOw0KK1NZU0NUTF9JTlQoX25ldF9pbmV0X3RjcCwgT0lEX0FV VE8sIGluc2VjdXJlX3N5biwgQ1RMRkxBR19SVywNCisgICAgJnRjcF9pbnNl Y3VyZV9zeW4sIDAsDQorICAgICJGb2xsb3cgdGhlIG9sZCBjcml0ZXJpYSBh bGxvd2luZyBTWU4gcGFja2V0cyB0byByZXNldCBhIGNvbm5lY3Rpb24uIik7 DQorDQogU1lTQ1RMX05PREUoX25ldF9pbmV0X3RjcCwgT0lEX0FVVE8sIHJl YXNzLCBDVExGTEFHX1JXLCAwLA0KIAkgICAgIlRDUCBTZWdtZW50IFJlYXNz ZW1ibHkgUXVldWUiKTsNCiANCkBAIC0xNTYwLDYgKzE1NjUsMTMgQEANCiAJ CQl9DQogCQl9DQogCQlnb3RvIGRyb3A7DQorCX0NCisNCisJaWYgKHRoZmxh Z3MgJiBUSF9TWU4pIHsNCisJCWlmICh0cC0+dF9zdGF0ZSA9PSBUQ1BTX0VT VEFCTElTSEVEICYmDQorCQkgICAgdGNwX2luc2VjdXJlX3N5biA9PSAwKSB7 DQorCQkJZ290byBkcm9wOw0KKwkJfQ0KIAl9DQogDQogCS8qDQo= --0-127286633-1104737489=:62262--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050103012325.A62262>