From owner-freebsd-hackers Sun Nov 19 8: 0:49 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from freesbee.wheel.dk (freesbee.wheel.dk [193.162.159.97]) by hub.freebsd.org (Postfix) with ESMTP id 8EED337B479 for ; Sun, 19 Nov 2000 08:00:44 -0800 (PST) Received: by freesbee.wheel.dk (Postfix, from userid 1001) id 0339C3E5B; Sun, 19 Nov 2000 17:00:42 +0100 (CET) Date: Sun, 19 Nov 2000 17:00:42 +0100 From: Jesper Skriver To: Alfred Perlstein Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001119170042.A18095@skriver.dk> References: <20001117211013.C9227@skriver.dk> <20001117142904.T18037@fw.wintelcom.net> <20001118155446.A81075@skriver.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001118155446.A81075@skriver.dk>; from jesper@skriver.dk on Sat, Nov 18, 2000 at 03:54:46PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Nov 18, 2000 at 03:54:46PM +0100, Jesper Skriver wrote: > On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote: > > * Jesper Skriver [001117 12:11] wrote: > > [snip] > > > > > > This timeout could be avoided if the sending mail server reacted to the > > > 'ICMP administratively prohibited' they got from our router. > > [snip] > > > > > > $ telnet nemo.dyndns.dk 25 > > > Trying 193.89.247.125... > > > telnet: Unable to connect to remote host: No route to host > > > $ uname -a > > > Linux xyz.dk 2.0.32 #1 Wed Nov 19 00:46:45 EST 1997 i586 unknown > > > > > > Wouldn't it be a idea to implement a similar behaviour in FreeBSD ? > > > > Probably not, what if one started a stream of spoofed ICMP lying > > about the state of the route between the two machines? I have > > the impression that the Linux box wouldn't be able to connect > > because of this behavior. > > Correct, a attacker could in theory make sure we couldn't connect to > a given remote box, but as I see it, it's mostly in teory. > > We could only react to this if we had a TCP session where we was > waiting for a SYN/ACK from this specific host, this only leaves a very > narrow window for a attacker to abuse, as he had to know both > destination and time. > > Do you agree ? A coworker of mine got into "rfc mode" and found the below, as we both read it, it says that we MUST treat a ICMP unreachable like a TCP RST. ########## ... A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. ########## A more complete quote. ########## RFC1122 (Requirements for Internet Hosts -- Communication Layers): [...] 3.2.2.1 Destination Unreachable: RFC-792 The following additional codes are hereby defined: 6 = destination network unknown 7 = destination host unknown 8 = source host isolated 9 = communication with destination network administratively prohibited 10 = communication with destination host administratively prohibited 11 = network unreachable for type of service 12 = host unreachable for type of service A host SHOULD generate Destination Unreachable messages with code: 2 (Protocol Unreachable), when the designated transport protocol is not supported; or 3 (Port Unreachable), when the designated transport protocol (e.g., UDP) is unable to demultiplex the datagram but has no protocol mechanism to inform the sender. A Destination Unreachable message that is received MUST be reported to the transport layer. The transport layer SHOULD use the information appropriately; for example, see Sections 4.1.3.3, 4.2.3.9, and 4.2.4 below. A transport protocol that has its own mechanism for notifying the sender that a port is unreachable (e.g., TCP, which sends RST segments) MUST nevertheless accept an ICMP Port Unreachable for the same purpose. Again in (experimental) RFC2498 (IPPM Metrics for Measuring Connectivity): [...] 6.6.5. Specific methodology for TCP: A TCP-port-N1-port-N2 methodology sends TCP SYN packets with source port N1 and dest port N2 at address A2. Network traffic incoming to A1 is interpreted as follows: [...] + An ICMP port-unreachable from A2 to A1 indicates temporal connectivity between the addresses (and again a *lack* of service connectivity for TCP-port-N1-port-N2). {Comment: TCP implementations generally do not need to send ICMP port- unreachable messages because a separate mechanism is available (sending a RST). However, RFC 1122 states that a TCP receiving an ICMP port-unreachable MUST treat it the same as the equivalent transport-level mechanism (for TCP, a RST).} /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?" /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message