From owner-freebsd-net@FreeBSD.ORG Mon Jan 3 07:31:31 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BA0B16A4CE for ; Mon, 3 Jan 2005 07:31:31 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 17E7643D3F for ; Mon, 3 Jan 2005 07:31:31 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 99572 invoked from network); 3 Jan 2005 07:31:30 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 3 Jan 2005 07:31:30 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 3 Jan 2005 01:31:29 -0600 (CST) From: Mike Silbersack To: net@freebsd.org Message-ID: <20050103012325.A62262@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-127286633-1104737489=:62262" Subject: Fixing "Slipping in the window" before 4.11-release X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2005 07:31:31 -0000 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--