Re: AW: Odd policy question.

2006-01-14 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Joe Abley wrote:
 That's a little over-broad considering the number of registries there 
 are (and have been, for a long time). I think it's fair to say that 
 even if this was once the case for COM/NET/ORG registries, there are 
 many more registries where this was never close to being true.
 
 It seems to me that if someone else chooses to insert 32- or 128-bit 
 integers of their choice into their zone files, then there's properly 
 very little I can or should be able to do about it. But that's just me.

You are indeed correct. There is also no good efficient way to know if
someone is allowed to use a particular IP address, or will have the
right for the life of an extended contract (like a 10 year DNS
registration).

As an engineer, I believe we would need a protocol that would permit
someone to query an IP address to ask what DNS domains it may be an NS
for. A simple client server response protocol. Lack of a response would
mean all are welcome here. Sort of the analogue of robots.txt for
webservers. Then if you wanted to disclaim a domain, you setup a server
and notify the registrar of the offending domain.

Now as a practical matter, I don't see this happening any time soon.
This is simply because this is a lot of mechanism for a problem that I
doubt many people have.

-Jeff
- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDyXCg8CBzV/QUlSsRAon/AKD6k5Qd1p8jUqGxWEHKYbLec9GgtgCg6bTN
GMITL/Fk0qm9sWu4A/M4suA=
=88Yt
-END PGP SIGNATURE-


Re: AW: Odd policy question.

2006-01-14 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Foolish me. Indeed all that is required is a way to detect that the
delegation is lame (hopefully in a secure fashion) and remove the lame
delegations. Of course that does leave the problem of what to do if all
of the delegations are lame, as Randy has alluded to.

-Jeff

Randy Bush wrote:
As an engineer, I believe we would need a protocol that would
permit someone to query an IP address to ask what DNS domains
it may be an NS for.
 
 
 this addresses neither the issue of longevity nor that of
 whether it is authoritative for a particular domain which
 is proposed to be, or has been, delegated to it.
 
 and please note that delegation is not to an ip address, but
 rather to an fqdn.  the only time the two are bound is when a
 delegatee is within the zone being delegated, so the delegator
 needs to insert a glue a rr.
 
 i run a very small registry for some cctlds.  my scripts do
 specifically check that all servers to which a delegation is
 proposed are actually serving the zone, and will not delegate
 if they are not.  i also check for 2182 compliance in a crude
 manner.  i also check that the ns rrset held by the servers is
 that to which delegation is requested.
 
 i would gladly re-run the delegation checks against the zone
 files periodically.  but i do not as i don't know what to do
 when (not if) i find lamers.  it seems a bit drastic to just
 remove delegation.  but i know from experience that email to
 the pocs will get no useful response.
 
 randy
 


- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDyXXb8CBzV/QUlSsRAh97AJ41jM/8ys9Bf3YT/nb7KpnwDuDyygCfXNqc
xxfbv+A2ccN9mjLzzLo1N/o=
=iKOl
-END PGP SIGNATURE-


Re: AW: Odd policy question.

2006-01-14 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Randy Bush wrote:
 could you amplify?

If registrars regularly checked for lame delegations (or checked on
demand). Then a way to attack a domain would be to forge DNS responses
to cause the registrar to remove the domain because it is lame. So
DNSSEC would be needed to be sure...

-Jeff

- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDyXuu8CBzV/QUlSsRAnAGAJ0WhItRG6VHtHj1QM21NFw+BYxxoQCgyjcy
fCQ3B4rYRxosPl40/Z/kSBw=
=OMSE
-END PGP SIGNATURE-


Re: AW: Odd policy question.

2006-01-13 Thread Jeffrey I. Schiller

Let me attempt to bring this back to the policy question.

Does someone have the *right* to put one of your IP addresses as an NS
record for their domain even if you do not agree?

Registrar policies imply that this is so, and has been this way for a
long time.

A number of years ago (like 8-10 or so) I had a student host a domain on
my campus that I rather they not host. When I requested the registrar
(or registrar equivalent at the time) to remove the domain, or at least
the NS record pointing at my IP address, they refused. Their position
was that if I didn't like the domain, I should block access to the IP
address. I solved the problem another way...

Presumably this would work today, but it takes the effected IP address
out of action and Drew's goal, presumably, is to get the IP address back
in use without cruft heading its way.

Is this a good policy? I can argue it either way myself...

-Jeff
-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]



Re: Wifi Security

2005-11-21 Thread Jeffrey I. Schiller

Steven M. Bellovin wrote:
 I frequently take the train to Washington; I've occasionally noticed 
 other PCs that appear to be looking for an access point.  I've been 
 tempted to put my machine into host AP mode (or use my travel access 
 point -- these trains generally have AC power), run a dhcp server, and 
 see what passwords I get.  But I've never been able to convince myself 
 that it would be legal, let alone ethical.
 
   --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

I have in fact done this (well something similar). On a train from
Boston to New York I turned on my wireless card in ad-hoc mode, setup a
DHCP server and setup my phone for GPRS. Bingo, I had four other people
get addresses from me and presumably do stuff I didn't sniff their
traffic though. Good 'ole Windows (which they were presumably running, I
wasn't) was happy to go from infrastructure mode to ad-hoc mode and
associate with me.

There is a fundamental security dilemma here. Years ago the original
designers of Privacy Enhanced Mail (PEM) had the notion that users
couldn't be trusted, so the idea was that there would be one root CA and
it would only issue certificates to people who proved who they were.
Software would only trust this one CA. In this fashion, if the software
said This came from Jeff Schiller, of MIT by golly that is where it
came from. No end-user preferences to get wrong, no dialog boxes to
click away unread. I even remember arguments along the lines of if a
signature verification failed, the message would be discarded and the
user not permitted to read the damaged message.

The dilemma is that when you build such a system, the guy who is the
root always turns out to be a reptile (or is eaten by a reptile who
takes her place).

-Jeff

-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]



BGP Security and PKI Hierarchies (was: Re: Wifi Security)

2005-11-21 Thread Jeffrey I. Schiller

Oh, I am quite aware of the BGP RP-Sec work and many people have heard
my opinion on this topic, including some on this mailing list. But I'll
re-iterate.

Hierarchical relationships breed reptiles because of the inherent
asymmetric business relationship that results. The leaves *must* do
business with the root, but the root does *not* have to do business with
the leaves. This results in the root calling the shots, for its own
benefit and profit.

Frankly, I am quite impressed with the address registries. For the most
part they are the exception. I believe this is because they are still
run by or heavily influenced by the wide eyed academics (as I have
been accused of being) who believe in the Internet Dream... (you know
who you are!). However there is also a check and balance in that if
the registries become unreasonable, people will think about ignoring
them, and they have to know this, if not explicitly, implicitly.

However, I fear creating yet another hierarchy which must work for the
Internet to work. One based on a PKI would not have to be reasonable, as
the leaves would have a harder time ignoring it. Piss off the
hierarchy, and forget about being routed.

I would much prefer an arrangement where the PKI for BGP was controlled
by the providers. So an institution would have its certificate signed
by its upstream (or one of its upstream) providers. In such a
transaction the balance of power is much more symmetric and therefore
likely to be reasonable.

The providers could cross-certificate to build a root free (as in
default free zone) mesh (aka Web of Trust.).

-Jeff

Blaine Christian wrote:
 Jeff you hit a hot button grin...  You would love the BGP RP-Sec 
 stuff going on at IETF etc...
 
 I think root authority for live routing protocols is out of the 
 picture.  However, you may want to stay tuned and speak up if you  feel
 a root authority for routing protocols is bad.
 
 Regards,
 
 Blaine
 
 
 

-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]



Re: Very funny: While Bush fiddles, New Orleans dies

2005-09-07 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Church, Chuck wrote:
 Even if the sending server is in a different domain that the users's
 reply-to address?
 
 s48.tribuneinteractive.com   !=  netzero.net

This is what SPF and friends are supposed to do. But they are not a
panacea (not intended to start a thread on the merits of SPF,
MASS(DKIM), etc.).

-Jeff
- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDHxDW8CBzV/QUlSsRApv9AKDyrqtX0ee+GB60ml5tTpv9BBXaigCcDh4N
/hikkb4vROOV5o/9b1kp5gU=
=5TdE
-END PGP SIGNATURE-


Re: Blocking certain terrorism/porn sites and DNS

2005-08-18 Thread Jeffrey I. Schiller

Check out http://tor.eff.org. Of particular interest are hidden services.

If you think you can block the use of the Internet... think again.

-Jeff
-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]



Re: OT: Cisco.com password reset.

2005-08-03 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Adams wrote:
 Odd that lots of people are trying to download new IOS images and then
 CCO locks them out.

I really really like to give people the benefit of the doubt, but I am
having a hard time with this one. Where are the security people at Cisco?

If I was a bad guy my dream shot would be a vulnerable IOS release
mixed with customers being unable to download the fixed release! Tell me
that they didn't think this through...

-Jeff

- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC8TVN8CBzV/QUlSsRAiB7AKDja0ue6BvU+1ChLF2MsJnh64/AxgCeOdq0
7T910b4dDaXeBOrTy7gA9Rg=
=l5HF
-END PGP SIGNATURE-


Re: Cisco and the tobacco industry

2005-07-30 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Folks.

All that is needed is for cisco to put an upgrade command into their
router. The upgrade command determines the routers version (and
current patch level) and requests the download of a version specific
patch file.

The command takes as arguments the on-disk (flash) version of the core
image and the beginning of a URL where to find the file. The filename
itself can be constructed based on the current version. The upgrade file
itself contains the checksum of the image it should be applied against
as well as the checksum of the final image. Of course it is digitally
signed by cisco (so Cisco will need a public key installed in its images).

The upgrade command then determines if sufficient flash exists to
perform the change and performs the upgrade. It might even be able to
patch in the in-core image (presumably this can be done via code that is
included in the patch itself, I leave this as an exercise for cisco).

The actual patch file can be located in a server at the customer's site
and Cisco can distribute them via BitTorrent :-)

Important points:

* Upgrade is initiated by the user. If the necessary arguments are
stored in the system configuration, perhaps the upgrade can be triggered
by SNMP even (yeah right).
* All patches are signed.
* Patches know what version they apply to and are careful to ensure they
are being applied to the right version (even if the customer improperly
names the files on their server).

This isn't trivial to do, but it isn't rocket science either!

-Jeff

- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC6+RK8CBzV/QUlSsRAmdAAKDCpvTl0sBIk5v0hX1Wbta1mRHe4ACg5/Or
ONwi+567ZEAdtW7B1J/yDhk=
=GJ2e
-END PGP SIGNATURE-


Re: Cisco and the tobacco industry

2005-07-30 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tony Li wrote:
 True, but you ARE suggesting that Cisco produce a binary patch, to a
 possibly compressed image.

Like I said, it isn't trivial. For example, the patching software (this
would require memory) could uncompress the image, patch it and
recompress the result. As a double check it can verify that the newly
patched compressed image has the correct checksum (because the
compression is completely deterministic, you can do this). But this is
getting into details that I, having no access to source nor the way the
binary is put together, am not competent to go into in any authoritative
way. However I do believe this problem can be solved.

It may indeed be technically easier to distribute a whole new image.
However I suspect this is harder from a management, legal point of view.
A patch tool, when made publically available, doesn't give away as much
information as does a whole image. And you should make security fixes
readily available, to the point that anyone on the planet might download
and examine them.

However my main point is that upgrading, at least for the provision of
security patches needs to be much easier then it is today. Both for the
professionally managed networks as well as the SOHO and residential market.

-Jeff

P.S. I am going out of my way to plain text sign these messages rather
then sending PGP/MIME. PGP/MIME is the more modern technology.
- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7C6x8CBzV/QUlSsRAhQdAKCsIXA6OWSM5HXU50Bbq2DkiyWIwwCeLdhF
BcCk2LBE6fzCgfT4qndUik8=
=wK9y
-END PGP SIGNATURE-


Re: Cisco and the tobacco industry

2005-07-30 Thread Jeffrey I. Schiller

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ivan Groenewald wrote:
 ..
 and Cisco can distribute them via BitTorrent :-)
 That's equivalent to saying the internet is safe enough to do your
 corporate banking via plain text email.
 my 2 pence,

Actually BitTorrent is a very good technology for this sort of thing. It
scales well for a large file to be downloaded by a large number of
people. Another important feature is that the .torrent file contains a
cryptographic hash of the file to be obtained (as well as the individual
pieces of the file). So as long as you can securely obtain the .torrent
file (say from an SSL protected Cisco operated website) you can relay on
the final delivered file to also be correct.

-Jeff
- --
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC7DOd8CBzV/QUlSsRAuApAJ9VPJAtUFx0zKWlOUgbcvWW/z1wJwCfT37x
E7skOVQeFrqjLB+N/xjYva0=
=/4vN
-END PGP SIGNATURE-


Re: Vonage Selects TCS For VoIP E911 Service

2005-07-20 Thread Jeffrey I. Schiller


[EMAIL PROTECTED] wrote:


On the other hand, maybe all you want to do is to route the
call to the right E911 center. In that case, as long as you
are in the right county you are probably OK.
 


This is actually more important then it sounds. Not long ago I was
driving around in Northern New Hampshire on I93 and saw a situation I
believed should be reported to the police. I used my cell phone to dial
*SP (which I saw on many signs in Massachusetts claiming it was how
you called the State Police).

Well, someone answers State Police and I begin to describe where I am.
Much confusion results until I realize that I am talking to the
MASSACHUSETTS State Police even when in Northern New Hampshire!

-Jeff

---
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]







NOC-DBA Phone (was Re: Comcast Contact)

2005-04-13 Thread Jeffrey I. Schiller

I have one, and its cool. However the time I *really* needed it was
because I couldn't reach a particular AS... and of course neither could
my INOC-DBA phone (sigh...).

-Jeff

On Wed, 2005-04-13 at 23:12, Suresh Ramasubramanian wrote:
 On 4/13/05, Ross Hosman [EMAIL PROTECTED] wrote:
  Could someone from Comcast please email me off list.
  
  Ross Hosman
  [EMAIL PROTECTED]
 
 If you have an AS, get yourself an inoc-dba phone. Easiest way to
 contact network operators that I know of.
-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]





MIT Hosed? (anyone from Ebay or Rogers available)

2005-03-24 Thread Jeffrey I. Schiller

Looking for some help...

Net 18/8 seems to be unable to reach significant portions of the
Internet. I suspect that someone is advertising a bogus route for us.
None of the regular looking glasses show any problems though.

If anyone from Ebay or Rogers Cable (AS812) is listening, I would really
like to know what routes (and AS path) you have for net 18 so I can
track this problem down.

Please cc any correspondence so [EMAIL PROTECTED], an e-mail address not
serviced through MIT's infrastructure.

Thanks.

-Jeff

-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]





Re: MIT Hosed? (anyone from Ebay or Rogers available)

2005-03-24 Thread Jeffrey I. Schiller

Problem solved (sort of). Thanks to all who helped. An unamed ISP was
leaking routes they picked up via a biazzare (and apparently
nonfunctional path). The last hop before the path got to us was Sprint
(AS1239) (which we are connected to). We have withdrawn our route from
Sprint which made the bogus routes go away and restored connectivity.
Fortunately I have other connections I can use. We are attempting to
contact unamed to get them to clean up their act.

-Jeff

On Thu, 2005-03-24 at 17:06, Jeffrey I. Schiller wrote:
 Looking for some help...
 
 Net 18/8 seems to be unable to reach significant portions of the
 Internet. I suspect that someone is advertising a bogus route for us.
 None of the regular looking glasses show any problems though.
 
 If anyone from Ebay or Rogers Cable (AS812) is listening, I would really
 like to know what routes (and AS path) you have for net 18 so I can
 track this problem down.
 
 Please cc any correspondence so [EMAIL PROTECTED], an e-mail address not
 serviced through MIT's infrastructure.
 
 Thanks.
 
   -Jeff
-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]





Re: verizon.net and other email grief

2004-12-10 Thread Jeffrey I. Schiller

On Fri, Dec 10, 2004 at 12:26:59PM -0500, Rich Kulawiec wrote:
 One thing that's not clear is whether or not Verizon caches any of
 this information.

It appears that they do some amount of caching.

-Jeff


Re: verizon.net and other email grief

2004-12-10 Thread Jeffrey I. Schiller

On Fri, Dec 10, 2004 at 06:03:11PM -0500, Krzysztof Adamski wrote:
 It does not appear that they are caching it, here is a sample from my log
 file:
 ...

Well when I tested it (3 hours ago) I connected to them manually while
watching my incoming milter log. Indeed they visited immediate and
verified my address (with an rcpt to command) and when that succeeded,
I got the sender ok in my telnet session. I then broke the
connection and tried again. The second time they did not contact my
server and gave me a sender ok.

It is now about three hours later and I just tried again and they did
not contact my server. Now this is the success case where the
mailbox exists. I don't know if they cache the non-existence of a
mailbox.

-Jeff

-- 
=
Jeffrey I. Schiller
MIT Network Manager
Information Services and Technology
Massachusetts Institute of Technology
77 Massachusetts Avenue  Room W92-190
Cambridge, MA 02139-4307
617.253.0161 - Voice
[EMAIL PROTECTED]



Re: dealing with w32/bagle

2004-03-03 Thread Jeffrey I. Schiller

Turns out that the ZIP file format that all of these beasties are
using is a little bit non-standard. Specifically they are all version
1.0 zip archives and the first (and only) component is not
compressed.

At MIT we are matching these two strings to recognize the infected ZIP
files while letting most (actually I have seen no false positives) if
not all real ZIP files. We are matching them anywhere within an
attachment (well, within the first 16K). However you really only need
to see if they are the beginning characters (this is a ZIP file
header).

What follows are the base64 encoded strings. I have put an asterisk
between the first and second character, so my own filters won't reject
this message, do remove that before using...

U*EsDBAoAA   = Matches unencrypted ZIP file
U*EsDBAoAAQAAA   = Matches encrypted version.

-Jeff



Re: IANA down?

2003-12-21 Thread Jeffrey I. Schiller
Not from MIT, I can get to it fine.

			-Jeff

David Lesher wrote:
http://www.iana.org

It appears so from here...and other places..








Re: Tracing where it started

2003-01-25 Thread Jeffrey I. Schiller
Here is what we saw at MIT (names are subnets). These are the times when 
the flooding started to cause us problems.

sloan 00:31:36
oc1-t100:32:07
nox-link  00:32:37
extr2-bb  00:33:13

All are EST.  The numbers are accurate to *at best* a minute because of 
the delay before the Noc is scheduled to test them.

			-Jeff


msg08461/pgp0.pgp
Description: PGP signature