nanog mail looping.

["Forrest W. Christian" <forrestc () iMach com>]

It looks like we've got a nanog mail loop going on here.  Haven't seen 
one of these in quite a while.

In any case, I have included the full headers below, and cc'd the 
relevant postmasters at (apparently) netscape and mcom.com

-forrestc () imach com

---------- Forwarded message ----------
Return-Path: owner-nanog () merit edu
Received: from merit.edu (merit.edu [35.1.1.42]) by IMgate.iMach.com (8.6.12/8.6.12) with ESMTP id VAA20161 for 
<forrestc () imach com>; Fri, 23 Aug 1996 21:03:03 -0600
Received: from localhost (daemon@localhost) by merit.edu (8.7.5/merit-2.0) with SMTP id WAA25979; Fri, 23 Aug 1996 
22:37:18 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 23 Aug 1996 22:37:15 -0400
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id WAA25965 for nanog-outgoing; Fri, 23 Aug 1996 
22:37:15 -0400 (EDT)
Received: from littlewing.mcom.com (h-205-217-255-33.netscape.com [205.217.255.33]) by merit.edu (8.7.5/merit-2.0) with 
ESMTP id WAA25960 for <nanog () merit edu>; Fri, 23 Aug 1996 22:37:12 -0400 (EDT)
Received: (from root@localhost) by littlewing.mcom.com (8.7.3/8.7.3) id TAA11467; Fri, 23 Aug 1996 19:39:35 -0700 (PDT)
Received: from maleman.mcom.com (maleman.mcom.com [198.93.92.3]) by tera.mcom.com (8.6.12/8.6.9) with ESMTP id WAA10758 
for <mcom.list.nanog () tera mcom com>; Thu, 22 Aug 1996 22:36:06 -0700
Received: from ns.netscape.com (ns.netscape.com.mcom.com [198.95.251.10]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP 
id WAA05229 for <list-nanog () netscape com>; Thu, 22 Aug 1996 22:32:52 -0700
Received: from merit.edu (merit.edu [35.1.1.42]) by ns.netscape.com (8.7.3/8.7.3) with ESMTP id WAA27127 for 
<list-nanog () netscape com>; Thu, 22 Aug 1996 22:31:57 -0700 (PDT)
Received: from localhost (daemon@localhost) by merit.edu (8.7.5/merit-2.0) with SMTP id BAA02728; Fri, 23 Aug 1996 
01:26:26 -0400 (EDT)
Received: by merit.edu (bulk_mailer v1.5); Fri, 23 Aug 1996 01:25:34 -0400
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id BAA02706 for nanog-outgoing; Fri, 23 Aug 1996 
01:25:33 -0400 (EDT)
Received: from gw.quake.net (gw.quake.net [140.174.86.11]) by merit.edu (8.7.5/merit-2.0) with ESMTP id BAA02701 for 
<nanog () merit edu>; Fri, 23 Aug 1996 01:25:28 -0400 (EDT)
Received: from quest.quake.net (avg () l24 ip Quake Net [198.68.224.24]) by gw.quake.net (8.7.4/8.7.4) with ESMTP id 
WAA02853; Thu, 22 Aug 1996 22:24:56 -0700 (PDT)
Received: (from avg@localhost) by quest.quake.net (8.6.9/8.6.9) id WAA02453; Thu, 22 Aug 1996 22:22:03 -0700
Date: Thu, 22 Aug 1996 22:22:03 -0700
From: Vadim Antonov <avg () quake net>
Message-Id: <199608230522.WAA02453 () quest quake net>
To: curtis () ans net, nanog () merit edu
Subject: Re: Access to the Internic Blocked
Sender: owner-nanog () merit edu

Curtis Villamizar wrote:

> Not at all.  LSRR is a nice tool to mount practically untraceable
> flooding attack (hint -- just forge source address and spread
> intermediate points evenly across the network).  Shutting you
> down may be exactly what the attacker wants.

> Oh come on.  Like they're not going to get caught stuffing an entire
> T1 with LSRR packets.  Face it.  You're grabbing at straws.

Ugh.  To kill multiple DS-3s you don't even need a full T-1
(you need one LS address for every loop), and you can kill multiple
DS-3s and an IXP to boot, with the single stream of bogons routed
in a loop with many hops.  And there's a lot of big name Us with
DS-3 connectivity and no security whatsoever.

Now, throw in randomized first hop and forged source address,
and i'll wish you good luck catching the perpetrator.  A careful
attacker would also randomize destinations and make it to look like
regular TCP traffic.

(And did anybody think of IP stacks which reverse the source
routes, just to make things funnier).

> Besides the fact that with your suggestion of traceroute using ICMP
> echo requests they'd just send a T1s worth of ICMP echo requests with
> LSRR and accomplish the same thing.

Ok, with only one intermediate point allowed.  _That_ should
take care of all diagnostic needs.

> LSRR is just too useful for diagnosing network problems to shut down
> on a backbone.

I sometimes wonder if the threat of hackers is exaggregated.
They certainly missed a nice opportunity to crash the Internet
with TCP resets on iBGPs.  Now nobody cares about the creative
potential of LSRR-anonymized denial of service attacks.  They
must be stupid or something.

Should i write a backbone-crasher and post it to USENET just to
make a point about LSRRs?  Note that a provider which won't
shut LSRR will be the threat to others...

--vadim

--WAA10774.840778792/tera.mcom.com--


- - - - - - - - - - - - - - - - -