Date: Sun, 19 Nov 2000 17:00:42 +0100 From: Jesper Skriver <jesper@skriver.dk> To: Alfred Perlstein <bright@wintelcom.net> Cc: hackers@FreeBSD.ORG Subject: Re: React to ICMP administratively prohibited ? Message-ID: <20001119170042.A18095@skriver.dk> In-Reply-To: <20001118155446.A81075@skriver.dk>; from jesper@skriver.dk on Sat, Nov 18, 2000 at 03:54:46PM %2B0100 References: <20001117211013.C9227@skriver.dk> <20001117142904.T18037@fw.wintelcom.net> <20001118155446.A81075@skriver.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jesper@skriver.dk> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001119170042.A18095>