Re: React to ICMP administratively prohibited ? - commit candidate ?

[Jesper Skriver]

On Fri, Nov 17, 2000 at 09:10:13PM +0100, Jesper Skriver wrote:

As said before, I've not got this code working, when the sysctl 
'net.inet.tcp.icmp_admin_prohib_like_rst' is set to 1, we'll treat a
ICMP administratively prohibited (icmp type 3 code 9, 10 and 13) as if
we recived a TCP RST, but only if the TCP session is in SYN_SENT state.

This is actually required by rfc1122 (Requirements for Internet Hosts)
section 3.2.2.1

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.

Because of this, I suggest that we by default enable this feature, but
it would be a change of current behaviour, so if people prefer to leave
it disabled by default, at least for now, this would be ok for me, the
attached diff actually have the sysctl set to 0 by default.

The only difference from the attached diff, to the one I mailed
yesterday is comments.

Does anyone have any objections to this being committed ? If no, who
will do it ?

/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.


diff -ru sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c
--- sys/netinet.old/ip_icmp.c   Thu Nov  2 10:46:23 2000
+++ sys/netinet/ip_icmp.c   Mon Nov 20 22:33:43 2000
@@ -328,6 +328,11 @@
 
case ICMP_UNREACH_NET_UNKNOWN:
case ICMP_UNREACH_NET_PROHIB:
+   if (icp->icmp_ip.ip_p == IPPROTO_TCP) {
+   code = PRC_UNREACH_PORT;
+   break;
+   }
+
case ICMP_UNREACH_TOSNET:
code = PRC_UNREACH_NET;
break;
@@ -335,11 +340,21 @@
case ICMP_UNREACH_HOST_UNKNOWN:
case ICMP_UNREACH_ISOLATED:
case ICMP_UNREACH_HOST_PROHIB:
+   if (icp->icmp_ip.ip_p == IPPROTO_TCP) {
+   code = PRC_UNREACH_PORT;
+   break;
+   }
+
case ICMP_UNREACH_TOSHOST:
code = PRC_UNREACH_HOST;
break;
 
case ICMP_UNREACH_FILTER_PROHIB:
+   if (icp->icmp_ip.ip_p == IPPROTO_TCP) {
+   code = PRC_UNREACH_PORT;
+   break;
+   }
+
case ICMP_UNREACH_HOST_PRECEDENCE:
case ICMP_UNREACH_PRECEDENCE_CUTOFF:
code = PRC_UNREACH_PORT;
diff -ru sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c
--- sys/netinet.old/tcp_subr.c  Fri Oct 27 13:45:41 2000
+++ sys/netinet/tcp_subr.c  Tue Nov 21 21:16:27 2000
@@ -134,6 +134,15 @@
 SYSCTL_INT(_net_inet_tcp, OID_AUTO, pcbcount, CTLFLAG_RD, 
 &tcbinfo.ipi_count, 0, "Number of active PCBs");
 
+/*
+ * Treat ICMP administratively prohibited like a TCP RST
+ * as required by rfc1122 section 3.2.2.1
+ */
+ 
+static int icmp_admin_prohib_like_rst = 0;
+SYSCTL_INT(_net_inet_tcp, OID_AUTO, icmp_admin_prohib_like_rst, CTLFLAG_RW,
+   &icmp_admin_prohib_like_rst, 0, "Treat ICMP administratively prohibited 
+messages like TCP RST, rfc1122 section 3.2.2.1");
+
 static voidtcp_cleartaocache __P((void));
 static voidtcp_notify __P((struct inpcb *, int));
 
@@ -961,6 +970,8 @@
 
if (cmd == PRC_QUENCH)
notify = tcp_quench;
+   else if ((icmp_admin_prohib_like_rst == 1) && (cmd == PRC_UNREACH_PORT) && 
+(ip))
+   notify = tcp_drop_syn_sent;
else if (cmd == PRC_MSGSIZE)
notify = tcp_mtudisc;
else if (!PRC_IS_REDIRECT(cmd) &&
@@ -1071,6 +1082,20 @@
 
if (tp)
tp->snd_cwnd = tp->t_maxseg;
+}
+
+/*
+ * When a ICMP unreachable is recieved, drop the
+ * TCP connection, but only if in SYN_SENT
+ */
+void
+tcp_drop_syn_sent(inp, errno)
+   struct inpcb *inp;
+   int errno;
+{
+   struct tcpcb *tp = intotcpcb(inp);
+   if((tp) && (tp->t_state == TCPS_SYN_SENT))
+   tcp_drop(tp, errno);
 }
 
 /*
diff -ru sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h
---

Re: React to ICMP administratively prohibited ?

[Scumley O'Fluffigan]

On Fri, 17 Nov 2000, Alfred Perlstein wrote:

> > This timeout could be avoided if the sending mail server reacted to the
> > 'ICMP administratively prohibited' they got from our router.
> > 
> > $ 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.

I wouldn't be surprised if this was introduced to linux because of
the ridiculously long timeouts they have for connections to ports
other than 23, or at least, used to have back when I experienced
them.

Eliminating this wait for a timeout would shave maybe a minute off
delivery time for most OSen, except for b0rken mailers that will
always try to deliver to the firewalled MX machine instead of
the lower-priority backups.  Not that those will concern me at
all.

It's more of a relatively minor inconvenience that the primary MX
machine isn't reachable for the world any more...

I did work some ten years ago through terminal access um, devices
that did react to ICMP messages received in the middle of an already
established connection.  Very annoying.  You don't want to do this.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Mike Silbersack]

On Sun, 19 Nov 2000, Jesper Skriver wrote:

> 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.
> ##
> 
> 9 = communication with destination network
> administratively prohibited
>  
>10 = communication with destination host
> administratively prohibited

Ok, you've got me convinced, it should be implemented.  

There's a problem, though.  Later RFCs say to use 13 instead of 10, as 10
was supposed to be for darpa use only.  Perhaps you should retest the
other OSes and see if they're only responding to one of the two messages.

Ok, back to MXes.  I've thought about it, and I can't think of any good
ways to do your configuration automatically.  Perhaps you could have some
cgi that would allow you to remove yourself from the firewall ruleset,
assuming you were coming from the IP in question.  Or, coming from the
other direction, the cgi could let you add yourself to the static mail
routing table if you were coming from the IP in question.

I assume you're using sendmail's "relay if I'm listed as a MX" feature
right now?

Mike "Silby" Silbersack



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Louis A. Mamakos]

It would seem more appropriate, somehow, to push the response to the
ICMP message up into the protocols where they can take the appropriate
action.  Of course, the problem is that the PRC_* abstracted codes may
not be rich enough to express all the semantics you'd wish to convey.

So one goal might be to see if this sort of process could get pushed into
netinet/tcp_sub.c:tcp_ctlinput().   Personally, I don't really like the
idea of the icmp_input() function reaching into TCP's private state and
doing stuff.  There's too many potential interactions (e.g., what about
IPSEC security associations?) 

I dunno, some of this is probably a matter of taste.

louie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Sun, Nov 19, 2000 at 10:04:51PM +0100, Jesper Skriver wrote:
> On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote:
> > 
> > This patch seems like it will do the wrong thing for ICMP messages that
> > are associated with non-TCP packets.   It looks like ICMP unreachable
> > messages for UDP packets will never get delivered to UDP sockets.
> 
> Yep - I've come to think of this too, I think I'll make it behave like
> before for non-TCP packets, or do you have a better idea ?

New version attached, this time I check that it's a ICMP unreachable for
a TCP packet, if not this code behaves like the current code.

I still need some hints on the sysctl stuff.

/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.


diff -u -r sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c
--- sys/netinet.old/ip_icmp.c   Thu Nov  2 10:46:23 2000
+++ sys/netinet/ip_icmp.c   Sun Nov 19 22:08:52 2000
@@ -328,6 +328,11 @@
 
case ICMP_UNREACH_NET_UNKNOWN:
case ICMP_UNREACH_NET_PROHIB:
+   if (icp->icmp_ip.ip_p == IPPROTO_TCP) {
+   code = PRC_UNREACH_PORT;
+   break;
+   }
+
case ICMP_UNREACH_TOSNET:
code = PRC_UNREACH_NET;
break;
@@ -335,11 +340,21 @@
case ICMP_UNREACH_HOST_UNKNOWN:
case ICMP_UNREACH_ISOLATED:
case ICMP_UNREACH_HOST_PROHIB:
+   if (icp->icmp_ip.ip_p == IPPROTO_TCP) {
+   code = PRC_UNREACH_PORT;
+   break;
+   }
+
case ICMP_UNREACH_TOSHOST:
code = PRC_UNREACH_HOST;
break;
 
case ICMP_UNREACH_FILTER_PROHIB:
+   if (icp->icmp_ip.ip_p == IPPROTO_TCP) {
+   code = PRC_UNREACH_PORT;
+   break;
+   }
+
case ICMP_UNREACH_HOST_PRECEDENCE:
case ICMP_UNREACH_PRECEDENCE_CUTOFF:
code = PRC_UNREACH_PORT;
diff -u -r sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c
--- sys/netinet.old/tcp_subr.c  Fri Oct 27 13:45:41 2000
+++ sys/netinet/tcp_subr.c  Sun Nov 19 21:17:40 2000
@@ -961,6 +961,8 @@
 
if (cmd == PRC_QUENCH)
notify = tcp_quench;
+   else if ((cmd == PRC_UNREACH_PORT) && (ip))
+   notify = tcp_drop_syn_sent;
else if (cmd == PRC_MSGSIZE)
notify = tcp_mtudisc;
else if (!PRC_IS_REDIRECT(cmd) &&
@@ -1071,6 +1073,20 @@
 
if (tp)
tp->snd_cwnd = tp->t_maxseg;
+}
+
+/*
+ * When a ICMP unreachable is recieved, drop the
+ * TCP connection, but only if in SYN SENT
+ */
+void
+tcp_drop_syn_sent(inp, errno)
+   struct inpcb *inp;
+   int errno;
+{
+   struct tcpcb *tp = intotcpcb(inp);
+   if((tp) && (tp->t_state == TCPS_SYN_SENT))
+   tcp_drop(tp, errno);
 }
 
 /*
diff -u -r sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h
--- sys/netinet.old/tcp_var.h   Sat Jul 22 01:26:37 2000
+++ sys/netinet/tcp_var.h   Sun Nov 19 21:17:55 2000
@@ -387,6 +387,7 @@
 voidtcp_input __P((struct mbuf *, int, int));
 voidtcp_mss __P((struct tcpcb *, int));
 int tcp_mssopt __P((struct tcpcb *));
+voidtcp_drop_syn_sent __P((struct inpcb *, int));
 voidtcp_mtudisc __P((struct inpcb *, int));
 struct tcpcb *
 tcp_newtcpcb __P((struct inpcb *));

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote:
> 
> This patch seems like it will do the wrong thing for ICMP messages that
> are associated with non-TCP packets.   It looks like ICMP unreachable
> messages for UDP packets will never get delivered to UDP sockets.

Yep - I've come to think of this too, I think I'll make it behave like
before for non-TCP packets, or do you have a better idea ?

/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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Louis A. Mamakos]

This patch seems like it will do the wrong thing for ICMP messages that
are associated with non-TCP packets.   It looks like ICMP unreachable
messages for UDP packets will never get delivered to UDP sockets.

louie



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Sat, Nov 18, 2000 at 06:36:32PM +0100, Jesper Skriver wrote:
> I'll see if I can get code together which will do this.

I've now got this working (diff attached), it was actually quite 
simple when I got a grip on what was going on in sys/netinet/, I'm
gratefull for comments.

Now I need to get this under the control of a sysctl, 'man 3 sysctl'
gives some information on how to read the setting of a sysctl, in 
sys/netinet/ip_icmp.c I see how some of the others was implemented,
but should I put this here ?

static int  drop_unreachable = 1;
SYSCTL_INT(_net_inet_icmp, OID_AUTO, drop_unreachable, CTLFLAG_RW,
&drop_unreachable, 0, "");

/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.


diff -u -r sys/netinet.old/ip_icmp.c sys/netinet/ip_icmp.c
--- sys/netinet.old/ip_icmp.c   Thu Nov  2 10:46:23 2000
+++ sys/netinet/ip_icmp.c   Sun Nov 19 21:49:27 2000
@@ -328,6 +328,9 @@
 
case ICMP_UNREACH_NET_UNKNOWN:
case ICMP_UNREACH_NET_PROHIB:
+   code = PRC_UNREACH_PORT;
+   break;
+
case ICMP_UNREACH_TOSNET:
code = PRC_UNREACH_NET;
break;
@@ -335,11 +338,17 @@
case ICMP_UNREACH_HOST_UNKNOWN:
case ICMP_UNREACH_ISOLATED:
case ICMP_UNREACH_HOST_PROHIB:
+   code = PRC_UNREACH_PORT;
+   break;
+
case ICMP_UNREACH_TOSHOST:
code = PRC_UNREACH_HOST;
break;
 
case ICMP_UNREACH_FILTER_PROHIB:
+   code = PRC_UNREACH_PORT;
+   break;
+
case ICMP_UNREACH_HOST_PRECEDENCE:
case ICMP_UNREACH_PRECEDENCE_CUTOFF:
code = PRC_UNREACH_PORT;
diff -u -r sys/netinet.old/tcp_subr.c sys/netinet/tcp_subr.c
--- sys/netinet.old/tcp_subr.c  Fri Oct 27 13:45:41 2000
+++ sys/netinet/tcp_subr.c  Sun Nov 19 21:17:40 2000
@@ -961,6 +961,8 @@
 
if (cmd == PRC_QUENCH)
notify = tcp_quench;
+   else if ((cmd == PRC_UNREACH_PORT) && (ip))
+   notify = tcp_drop_syn_sent;
else if (cmd == PRC_MSGSIZE)
notify = tcp_mtudisc;
else if (!PRC_IS_REDIRECT(cmd) &&
@@ -1071,6 +1073,20 @@
 
if (tp)
tp->snd_cwnd = tp->t_maxseg;
+}
+
+/*
+ * When a ICMP unreachable is recieved, drop the
+ * TCP connection, but only if in SYN SENT
+ */
+void
+tcp_drop_syn_sent(inp, errno)
+   struct inpcb *inp;
+   int errno;
+{
+   struct tcpcb *tp = intotcpcb(inp);
+   if((tp) && (tp->t_state == TCPS_SYN_SENT))
+   tcp_drop(tp, errno);
 }
 
 /*
diff -u -r sys/netinet.old/tcp_var.h sys/netinet/tcp_var.h
--- sys/netinet.old/tcp_var.h   Sat Jul 22 01:26:37 2000
+++ sys/netinet/tcp_var.h   Sun Nov 19 21:17:55 2000
@@ -387,6 +387,7 @@
 voidtcp_input __P((struct mbuf *, int, int));
 voidtcp_mss __P((struct tcpcb *, int));
 int tcp_mssopt __P((struct tcpcb *));
+voidtcp_drop_syn_sent __P((struct inpcb *, int));
 voidtcp_mtudisc __P((struct inpcb *, int));
 struct tcpcb *
 tcp_newtcpcb __P((struct inpcb *));

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

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 <[EMAIL PROTECTED]> [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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Louis A. Mamakos]

> 
> On Sat, 18 Nov 2000, Jesper Skriver wrote:
> 
> > On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
> > > 
> > > 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 ?
> > 
> > /Jesper
> 
> Well, if you honor such messages, don't you have to honor them in the
> middle of a connection too?  Then you could cause a connection drop at any
> time.

No, you don't.

This is a replay of discussions that happened literally 20 years ago
as the first TCP implementations were being done.  I believe the
acceptable practice at the time was to honor an ICMP advisory (e.g.,
pass it to TCP to have it abort the pending connection) while in
SYN-SENT state.  That is, when initially trying to open the connection,
give up sooner based on the ICMP message, rather than waiting for an
ACK timeout.  

If an ICMP message associated with a connection was received after 
the connection passed to ESTABLISHED state, then you could choose 
to pass an advisory to the application, but not abort the connection.
The Berkeley network stack did this, and a variety of applications
would give up and die should they get an error return from a read()
or write() system call on the connection, even though it was still
alive.  I think that behavior may have changed, but I haven't check
anytime recently.

At the time, the anticipated source of ICMP messages were Destination
Unreachable advisories, provoked by either permanant or transient
routing failures to the destination.

> It would seem simpler to have the ISP in question use proper RST
> responses, or just stop filtering totally.

This behavior, while widely implemented, is a hack and a kludge.  An
intermediate network element isn't supposed to spoof source address
and return responses on behalf of some other system.  This only works
for TCP, and only if you can see the headers (e.g., not encrypted with
IPSEC).  

louie




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Sat, Nov 18, 2000 at 03:18:36PM -0600, Mike Silbersack wrote:
> 
> On Sat, 18 Nov 2000, Jesper Skriver wrote:
> 
> > > or just stop filtering totally.
> > 
> > Which is not a option in this case, and in the real world it's that
> > uncommon.
> > 
> > I'll see if I can get code together which will do this.
> > 
> > If we leave this off by default, would people object to putting in
> > this functionality ?
> > 
> > /Jesper
> 
> What's the point?  If people complain about a badly setup MX behind a
> firewall, are you going to respond and tell them to flip a sysctl?

My motivation is primarily to get the code working, and perhaps in the
future get it enabled by default. But until then tell people that a
sysctl can get this behaviour.

> This isn't a case of interoperability with a common TCP stack which needs
> to be lived with.  It's a case of something that is broken even with the
> suggested "fix".

I wouldn't call it broken, why should the routers bother to send a ICMP
access prohibited (or any of the other unreachables) if nobody cares anyway.

My approach is a bit more pragmatic, and as I can see it, the chance
that a attacker can abuse this seems very slim.

> The correct thing to do in this situation is to configure sendmail
> properly so that the MX silliness isn't needed.

Using a static mail routing from a public known MX to the real
mailserver is certainly a better solution if the same people control
both, but in this case it's not like that. 

Let me explain in a bit more detail.

We have lots of ADSL users (potentially hundreds of thousands), lots of
these have open relays(*) that relay via our mailservers, making our
mailservers open for spammers to use.

The best solution we have been able to find, was the filters that block
access to tcp/25 except from the backup-mx host, this eliminated the
open relays once and for all, with very little work.

We have no knowledge of which domains the users have (and this also
changes all the time), and the price structure doesn't leave room
for the hazzle of maintaining (and supporting) such static mail
routing table, it's also significantly easier for the users to 
understand why they should configure

xyz.dk. IN MX 10 xyz.dk.
xyz.dk. IN MX 20 backup-mx.post.tele.dk.

than

xyz.dk. IN MX 10 backup-mx.post.tele.dk.

And then do what ever to get the static mail routing configured.

*) Often a simple "gateway" like WinGate or similar with by default
   seems to give this "functionality" :-(

/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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Mike Silbersack]

On Sat, 18 Nov 2000, Jesper Skriver wrote:

> > or just stop filtering totally.
> 
> Which is not a option in this case, and in the real world it's that
> uncommon.
> 
> I'll see if I can get code together which will do this.
> 
> If we leave this off by default, would people object to putting in
> this functionality ?
> 
> /Jesper

What's the point?  If people complain about a badly setup MX behind a
firewall, are you going to respond and tell them to flip a sysctl?

This isn't a case of interoperability with a common TCP stack which needs
to be lived with.  It's a case of something that is broken even with the
suggested "fix".

The correct thing to do in this situation is to configure sendmail
properly so that the MX silliness isn't needed.

Mike "Silby" Silbersack




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Alfred Perlstein]

* Jesper Skriver <[EMAIL PROTECTED]> [001118 09:36] wrote:
> 
> Which is not a option in this case, and in the real world it's that
> uncommon.
> 
> I'll see if I can get code together which will do this.
> 
> If we leave this off by default, would people object to putting in
> this functionality ?

I wouldn't object as long as it was not the default.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Sat, Nov 18, 2000 at 11:04:55AM -0600, Mike Silbersack wrote:
> 
> On Sat, 18 Nov 2000, Jesper Skriver wrote:
> 
> > On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
> > > 
> > > 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 ?
> > 
> > /Jesper
> 
> Well, if you honor such messages, don't you have to honor them in the
> middle of a connection too?  Then you could cause a connection drop at any
> time.

I cannot see why we should honor them "in the middle of a connection", 
the real problem exist when setting up TCP sessions, if someone configure
a filter when there are existing connections, they will die due to lack
of response, but this would be a one time event.

> It would seem simpler to have the ISP in question use proper RST
> responses

The problem is that the largest router vendor (Cisco) cannot do this.

> or just stop filtering totally.

Which is not a option in this case, and in the real world it's that
uncommon.

I'll see if I can get code together which will do this.

If we leave this off by default, would people object to putting in
this functionality ?

/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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Alfred Perlstein]

* Jesper Skriver <[EMAIL PROTECTED]> [001118 06:54] wrote:
> On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
> > * Jesper Skriver <[EMAIL PROTECTED]> [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 ?

If I agreed I wouldn't have objected in the first place. :(

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Mike Silbersack]

On Sat, 18 Nov 2000, Jesper Skriver wrote:

> On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
> > 
> > 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 ?
> 
> /Jesper

Well, if you honor such messages, don't you have to honor them in the
middle of a connection too?  Then you could cause a connection drop at any
time.

It would seem simpler to have the ISP in question use proper RST
responses, or just stop filtering totally.

Mike "Silby" Silbersack



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Sat, Nov 18, 2000 at 10:19:01AM +0200, John Hay wrote:
> > 
> > I'm currently looking at how various operating systems react to a 'ICMP
> > administratively prohibited'.
> > 
> > My motivation is setup's where access to the primary mailserver is
> > blocked by filters (usually to block open relay's), and all mail has to
> > go via the backup MX, a example from a customer of ours.
> > 
> > jesper@freesbee$ host -t mx nemo.dyndns.dk
> > nemo.dyndns.dk mail is handled (pri=10) by nemo.dyndns.dk
> > nemo.dyndns.dk mail is handled (pri=20) by backup-mx.post.tele.dk
> > 
> > Here we block access to tcp/25 on nemo.dyndns.dk (a ADSL users), but
> > provide a backup MX for him to use, but when a mailserver wants to send
> > mail to him, they will experience a timeout before sending the mail to
> > backup-mx.post.tele.dk, which can send the mail onwards to
> > nemo.dyndns.dk.
> 
> You can also solve the problem another way. You can remove the MX for
> the customer machine, so that your backup-mx is the prefered MX for his
> mail. Then on backup-mx you can add a mailertable entry to direct the
> mail to his machine. Something like:
> 
> nemo.dyndns.dksmtp:[nemo.dyndns.dk]

I know, but this require per-domain/user configuration on backup-mx,
something we want to avoid at any cost, now you're going to ask how we
make sure backup-mx is not a open relay.

This is ensured by a patch(*) I wrote for postfix, from sample-smtpd.cf

# permit_auth_mx_backup: accept mail if all ip address(es) of the primary MX is 
# within $auth_mx_backup_networks, See auth_mx_backup_networks 
#
# The auth_mx_backup_networks parameter specifies a list of networks 
# where Postfix will act as a backup MX host if the primary MX is
# within these networks, and permit_auth_mx_backup is configured.
#
# The list is used by the anti-UCE software. See permit_auth_mx_backup
# in the sample-smtpd.cf file.

> This way you don't have to worry how someone else's machine is going
> to handle those icmp packets.

Your solution is a good one, if the product has a margin that allow
for user specific configuration on the backup-mx, but in this case it's
a ADSL product for home users, with a very little margin ...

*) 

See the postfix.users archive for history (the above patch is the same,
only relative to 20001030 instead of 2531.



/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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Jesper Skriver]

On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
> * Jesper Skriver <[EMAIL PROTECTED]> [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 ?

/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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[John Hay]

> 
> I'm currently looking at how various operating systems react to a 'ICMP
> administratively prohibited'.
> 
> My motivation is setup's where access to the primary mailserver is
> blocked by filters (usually to block open relay's), and all mail has to
> go via the backup MX, a example from a customer of ours.
> 
> jesper@freesbee$ host -t mx nemo.dyndns.dk
> nemo.dyndns.dk mail is handled (pri=10) by nemo.dyndns.dk
> nemo.dyndns.dk mail is handled (pri=20) by backup-mx.post.tele.dk
> 
> Here we block access to tcp/25 on nemo.dyndns.dk (a ADSL users), but
> provide a backup MX for him to use, but when a mailserver wants to send
> mail to him, they will experience a timeout before sending the mail to
> backup-mx.post.tele.dk, which can send the mail onwards to
> nemo.dyndns.dk.

You can also solve the problem another way. You can remove the MX for
the customer machine, so that your backup-mx is the prefered MX for his
mail. Then on backup-mx you can add a mailertable entry to direct the
mail to his machine. Something like:

nemo.dyndns.dk  smtp:[nemo.dyndns.dk]

The square brackets are needed to tell sendmail not to do MX lookups
again. Or if you don't want to use mailertables, you can set the
confTRY_NULL_MX_LIST variable to true.

This way you don't have to worry how someone else's machine is going
to handle those icmp packets.

John
-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: React to ICMP administratively prohibited ?

[Alfred Perlstein]

* Jesper Skriver <[EMAIL PROTECTED]> [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.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message