To: sipb-office@MIT.EDU
Cc: sipb-discussion@MIT.EDU
Reply-To: sipb-discussion@MIT.EDU
mail-copies-to: never
mail-followups-to: sipb-discussion@mit.edu
Subject: SIPB role in advocacy sane network diagnostic advocacy
Message-Id: <20020521184442.5B51F151EBE@industrial-algebra.mit.edu>
Date: Tue, 21 May 2002 14:44:42 -0400 (EDT)
From: hartmans@MIT.EDU (Sam Hartman)


According to discussion on -c sipb -i network, the network group and
the RCCs are apparently taking a significant  stand against people
sniffing the network for diagnostic purposes:

Instance: network Time: Tue May 21 14:25:44 2002 Host: MULTICS.MIT.EDU
From: Keith <keithw>

My RCC just came by to complain about my reporting people
(like on -i network yesterday) whose computers are flooding
the network, saying the only permissible information in
complaints are "pings to the router," and that running ntop
or similar tools to obtain the names of the actual flooding
machines is "illegal." Does this reflect a change in
network policy?


Instance: network Time: Tue May 21 14:27:15 2002 Host: PROWLER.MIT.EDU
From: Devil in the Shape of a Woman <sly>

it is against the rules of use, and network is prepared to be much more
serious about it -- if you had come to the town meetings you would know that

Instance: network Time: Tue May 21 14:29:10 2002 Host: central-air-conditioning.toybox.cambridge.ma.us
From: Marc Horowitz <marc>

and what does network intend as a punishment for those who break this
rule?

Instance: network Time: Tue May 21 14:29:17 2002 Host: PROWLER.MIT.EDU
From: Devil in the Shape of a Woman <sly>

a visit to the CoD


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

To me this seems like a really bad trend for the following reasons:

1) Network does not currently have in place a mechanism to collect the
   diagnostic data needed to resolve problems and benefits
   significantly from people running ntop and in some cases tcpdump.  

2)  Even  if network were to suddenly have this capability available,
    network has not demonstrated to its customers that their help is
    not needed.

3)  Being able to debug problems on the network is useful both from
    the standpoint of learning siklls and the standpoint of
    determining whether your own machines are causing a problem.

4) Most of the data in question is not actually private, or at least
   giving the impression that the data is private leads to a false
   sense of security/privacy.


5)  It seems unlikely that the policy will actually cause people to
    decrease network sniffing ; it will just decrease people's
    willingness to talk about it and  to provide useful conclusions
    they have learned.

6)  The threatened punishment does not fit the crime even a little
    bit.

I propose that interested parties within SIPB (and I am not such a
party--I'm not a student any more) consider getting together and
trying to point out why this is a bad idea.  I suggest:

1) Presenting a case about the benefits of network sniffing.

2) Demonstrating cases in the past where network or net-security
   staffersl have specifically asked for network sniffing from
   students.

3) Comparing policies with other schools and if it helps the case
   including  the appropriate details.

Etc.