lp (134.222.35.2)?

I'm sure some of you will have seen this, so sorry to toss logs on the
listburn fire; still, it seemed worth reposting to CP--no, it's not
entirely crypto-related, but nor is it a completely vague allegation.

>From GovAccess.183.snoops:

>  The following is the transcript of an actual communications trace that a
>  friend ran, while I was sitting next to him, watching -- reprinted here
>  with his permission.
>  
>  He did a "traceroute" of two messages that he sent from his machine in
>  Switzerland (he'd telneted into it while we were at a computer conference
>  in California).
>  
>  Traceroute automatically reports each Internet node through which a message
>  passes, as it proceeds from origin to destination.
>  
>  He did two traceroutes.  The first was from Switzerland to an addressee at
>  Netcom in San Jose, California.  The second was from Switzerland to an
>  addressee in Israel.
>  
>  
>  Date: Fri, 21 Apr 95 02:54:58 +0200
>  From: kelvin@fourmilab.ch (John Walker)
>  To: jwarren@well.com
>  Subject: Traceroute
>  
>  > /usr2/kelvin> traceroute netcom11.netcom.com
>  traceroute to netcom11.netcom.com (192.100.81.121), 30 hops max, 40
byte packets
>   1  eunet-router (193.8.230.64)  2 ms  2 ms  2 ms
>   2  146.228.231.1 (146.228.231.1)  326 ms  345 ms  307 ms
>   3  Bern5.CH.EU.NET (146.228.14.5)  447 ms  408 ms  364 ms
>   4  146.228.107.1 (146.228.107.1)  127 ms  37 ms  36 ms
>   5  Zuerich1.CH.EU.NET (146.228.10.80)  37 ms  38 ms  175 ms
>   6   (134.222.9.1)  65 ms  109 ms  252 ms
>   7  lp (134.222.35.2)  196 ms  179 ms  405 ms
>   8  Vienna1.VA.ALTER.NET (137.39.11.1)  191 ms  179 ms  313 ms
>   9  fddi.mae-east.netcom.net (192.41.177.210)  336 ms  204 ms  303 ms
>  10  t3-2.dc-gw4-2.netcom.net (163.179.220.181)  182 ms  251 ms  187 ms
>  11  t3-2.chw-il-gw1.netcom.net (163.179.220.186)  305 ms  586 ms  518 ms
>  12  t3-2.scl-gw1.netcom.net (163.179.220.190)  537 ms  693 ms  797 ms
>  13  t3-1.netcomgw.netcom.net (163.179.220.193)  698 ms  549 ms  754 ms
>  14  netcom11.netcom.com (192.100.81.121)  890 ms  1922 ms  1696 ms
>  
>  > /usr2/kelvin> traceroute jerusalem1.datasrv.co.il
>  traceroute to jerusalem1.datasrv.co.il (192.114.21.101), 30 hops max, 40
>  byte packets
>   1  eunet-router (193.8.230.64)  2 ms  3 ms  2 ms
>   2  146.228.231.1 (146.228.231.1)  933 ms  853 ms  874 ms
>   3  Bern5.CH.EU.NET (146.228.14.5)  1040 ms  450 ms  525 ms
>   4  146.228.107.1 (146.228.107.1)  453 ms  424 ms  188 ms
>   5  Zuerich1.CH.EU.NET (146.228.10.80)  64 ms  61 ms  47 ms
>   6   (134.222.9.1)  80 ms  312 ms  84 ms
>   7  lp (134.222.35.2)  270 ms  400 ms  216 ms
>   8  Vienna2.VA.ALTER.NET (137.39.11.2)  660 ms  1509 ms  886 ms
>   9  dataserv-gw.ALTER.NET (137.39.155.38)  1829 ms  1094 ms  1306 ms
>  10  orion.datasrv.co.il (192.114.20.22)  1756 ms  1280 ms  1309 ms
>  11  ...
>  
>  
>  Notice that both messages went through an unnamed site -- 134.222.9.1 and
>  then a strangely-named site, "lp (134.222.35.2)" -- then through the same
>  Vienna, Virginia (USA) site ... and thereafter, on to their destination.
>  I.e., the second message went through Virginia to get from Switzerland to
>  Israel.
>  
>  The whois servers at the InterNIC and at nic.ddn.mil for MILNET Information
>  report, ``No match for "134.222.9.1". '' and `` No match for
>  "134.222.35.2".''
>  
>  Now let me see ... which spy agencies are located in or near Virginia?
>  
>  --jim

Anonymous writes:
> >  Notice that both messages went through an unnamed site -- 134.222.9.1 and
> >  then a strangely-named site, "lp (134.222.35.2)"
[...]
> >  Now let me see ... which spy agencies are located in or near Virginia?

The existance of MAE East in Virginia is far more significant.

I'm sure the spooks are spying, but they are likely just tapping
lines. Machines that don't have proper reverse maps show up every day
in large networks and aren't something to worry about. Your posting is
based on the premise that this unnamed machine is of significance --
and it almost certainly isn't of any significance.

Quit looking for the spooks where they aren't. You should always
assume your line is being tapped if you are saying something you don't
want heard, anway.

Perry

On Sun, 5 Nov 1995, Anonymous wrote:

> >  Notice that both messages went through an unnamed site -- 134.222.9.1 and
> >  then a strangely-named site, "lp (134.222.35.2)" -- then through the same
> >  Vienna, Virginia (USA) site ... and thereafter, on to their destination.
> >  I.e., the second message went through Virginia to get from Switzerland to
> >  Israel.
> >  
> >  The whois servers at the InterNIC and at nic.ddn.mil for MILNET Information
> >  report, ``No match for "134.222.9.1". '' and `` No match for
> >  "134.222.35.2".''

Yes, you've finally cottoned on to the secret NSA routing trick to 
cleverly tap all traffic. Really clever the way they use two hosts in the 
132.222 Class B network. Strange that traffic from EUNET should be using 
that network, especially since it happens to be listed in the whois 
database as being NET-EUNET-X25.

::chivalry:ses$ whois -h rs.internic.net 134.222
::European Unix Users Group (NET-EUNET-X25)
::   Kruislaan 413
::   NL-1098 SJ Amsterdam
::   NETHERLANDS

In article <199511050620.HAA14046@utopia.hacktic.nl>,
Anonymous <nobody@REPLAY.COM> wrote:
> I'm sure some of you will have seen this, so sorry to toss logs on the
> listburn fire; still, it seemed worth reposting to CP--no, it's not
> entirely crypto-related, but nor is it a completely vague allegation.

It's specious.

> >  Notice that both messages went through an unnamed site -- 134.222.9.1 and
> >  then a strangely-named site, "lp (134.222.35.2)"

Belonging to the EUnet backbone, apparently run by people who don't care
much about DNS.

Actually, I resolve 134.222.9.1 as `Amsterdam4.NL.EU.net'.  I can ping
it, but not 134.222.35.2.  134.222.35/24 also does not appear in the
RIPE registry.  I'm going to conclude that it was a temporary thing EUnet
set up for some reason.  It seems to have been replaced by amsterdam6,
134.222.228.13.

> > -- then through the same
> >  Vienna, Virginia (USA) site ...

...a major router at a major interconnect run by UUNET, a major provider.
datasrv appaently contracted with UUNET for traffic.  Naturally it would
go through their network, which is centered in the US.

Why isn't the NSA tapping biu.ac.il, a central Israeli news site?
Routing from Net99 to them is through IBM.

> >  The whois servers at the InterNIC and at nic.ddn.mil for MILNET Information
> >  report, ``No match for "134.222.9.1". '' and `` No match for
> >  "134.222.35.2".''

They are not comprehensive.  You need to look up the network.

This is silly.  If the NSA were monitoring traffic with the consent of
EUnet and UUNET (and note that EUnet is owned by UUNET rival PSI), they
wouldn't need to play these routing games; they'd just eavesdrop at an
interconnect or on the leased lines leading into it, run a rough filter
over it to cut down volume, and tunnel the traffic home through other
channels (probably satellite).  And if they were monitoring without the
consent of UUNET and EUnet, they still wouldn't play these games because
the providers would be upset about the unexpected load on the expensive
and overloaded transatlantic pipes.

Finally, we all know how easy sniffing is at the local (LAN, ISP LAN,
and especially telco) level.  And we know that end-to-end encryption
is the way to go.  So what would we have learned if we knew the NSA
was eavesdropping?

Just *assume* the NSA is out to get you, design systems that resist
attack, and then you can stop caring about whether you're the target.

And tell your vendor you want Kerberos or IPSEC.
-- 
Shields.