April 2014 - Test - lists.nanog.org

DNS Issue with proofpoint.com
by Jaren Angerbauer 16 Apr '14

16 Apr '14

All, Sending this out (to multiple lists -- apologies for the potential duplicates) in the hopes to proactively resolve any mail flow issues to / from Proofpoint customers. Earlier this evening, we had some DNS issues with our domain (proofpoint.com) We've resolved the main problem, however, due to old cached DNS information, the fall out now is that *many* (i.e. hundreds at this point) customers are are seeing major email delays. For any DNS operators, it would be much appreciated if you could flush your DNS servers for proofpoint.com. Among other providers, we are still seeing delays with mail flow to ATT Wireless and Verizon Wireless. Thanks in advance for your assistance on this. Jaren Angerbauer Deliverability & ISP Relations Manager Proofpoint

6 6

Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
by Larry Sheldon 16 Apr '14

16 Apr '14

On 4/16/2014 4:34 PM, Jason Iannone wrote: > I can't cite chapter and verse but I seem to remember this zeroing > problem was solved decades ago by just introducing a bit which said > this chunk of memory or disk is new (to this process) and not zeroed > but if there's any attempt to actually access it then read it back as > if it were filled with zeros, or alternatively zero it. > > Isn't that a result of the language? Low level languages give that > power to the author rather than assuming any responsibility. Hacker > News had a fairly in-depth discussion regarding the nature of C with > some convincing opinions as to why it's not exactly the right tool to > build this sort of system with. The gist, forcing the author of a > monster like OpenSSL to manage memory is a problem. I dropped out of the discussion because I couldn't get a foot-hold, but I would like to know this: If the hardware (as has been suggested) or the OS does any of this, how do diagnostic routine in or running under the OS work? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

Re: badly behaved subsciber
by Andrew Koch 16 Apr '14

16 Apr '14

On Wed, Apr 16, 2014 at 11:43AM -0500, William Herrin wrote: > By the way, can we do something about this joker? I'm tired of > receiving his notice every time I post to NANOG. Hi Bill and the NANOG mailing list, The NANOG Communications Committee, reachable at admins(a)nanog.org, is the appropriate place to bring mailing list concerns to. We may not always be aware of these types of troubles, so please do let us know. Best Regards, Andrew Koch NANOG Communications Committee > > Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu > [140.247.35.201]) by magic.dirtside.com (8.14.3/) with ESMTP id > s3GFgisL026781 for <bill(a)herrin.us>; Wed, 16 Apr 2014 11:42:45 -0400 > X-Really-To: <bill(a)herrin.us> > Received: from hudce7.harvard.edu (hudce7.harvard.edu [140.247.198.27]) > by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 96D581D839B > for <bill(a)herrin.us>; Wed, 16 Apr 2014 11:42:44 -0400 (EDT) > Message-id: <fc.0066410e0938c8803b9aca007ca76832.938c881(a)hudce7.harvard.edu> > Date: Wed, 16 Apr 2014 11:42:33 -0400 > Subject: NDN: Re: DNS Issue with proofpoint.com > From: Post Office > > ----=_--0938c881.0938c880.cf745569 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > Sorry. Your message could not be delivered to: > > Rich Borroff (Mailbox or Conference is full.) > > > > > > -- > William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004

2 1

Re: badly behaved subsciber
by Larry Sheldon 16 Apr '14

16 Apr '14

On 4/16/2014 11:17 AM, Andrew Koch wrote: > On Wed, Apr 16, 2014 at 11:43AM -0500, William Herrin wrote: > >> By the way, can we do something about this joker? I'm tired of >> receiving his notice every time I post to NANOG. > > > Hi Bill and the NANOG mailing list, > > The NANOG Communications Committee, reachable at admins(a)nanog.org, is > the appropriate place to bring mailing list concerns to. We may not > always be aware of these types of troubles, so please do let us know. I sent notice to that address--not clear that it did any good. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

Re: AT&T / Verizon DNS Flush?
by Hank Nussbacher 16 Apr '14

16 Apr '14

At 10:21 16/04/2014 -0600, Steven Briggs wrote: Been discussed and nothing has been done: http://www.ietf.org/proceedings/87/slides/slides-87-dnsop-8.pdf https://www.dns-oarc.net/files/workshop-201005/DNS-Emergency-Alert-System.p… Will keep happening until someone decides to act. -Hank >Yeah...I know. Unfortunately, the domain was "mishandled" by our >registrar, who imposed their own TTLs on our zone, THEN turned it back over >to us with a 48HR TTL. Which is very bad. > >I really appreciate all of your help, guys! >á§ > > >On Wed, Apr 16, 2014 at 10:14 AM, Laszlo Hanyecz <laszlo(a)heliacal.net>wrote: > > > The generally accepted and scalable way to accomplish this is to advertise > > your freshness preferences using the SOA record of your domain. It would > > be pretty tricky to make this work with a swivel chair type system for > > every domain and host on the internet. You would have to contact every > > user and ask them to invalidate the caches, after asking their recursing > > server operator to do the same. > > > > -Laszlo > > > > > > On Apr 16, 2014, at 6:15 AM, Steven Briggs <stevenbriggs(a)gmail.com> wrote: > > > > > Hello, > > > > > > Not sure where to point this... I was wondering if anybody knows an > > inroad > > > to reach AT&T and Verizon systems people to flush their caches for " > > > proofpoint.com"? > > > > > > Any help is greatly appreciated! > > > > > > Steven Briggs > > > á§ > > > >

2 1

badly behaved subsciber
by William Herrin 16 Apr '14

16 Apr '14

By the way, can we do something about this joker? I'm tired of receiving his notice every time I post to NANOG. Received: from us25.unix.fas.harvard.edu (us25.unix.fas.harvard.edu [140.247.35.201]) by magic.dirtside.com (8.14.3/) with ESMTP id s3GFgisL026781 for <bill(a)herrin.us>; Wed, 16 Apr 2014 11:42:45 -0400 X-Really-To: <bill(a)herrin.us> Received: from hudce7.harvard.edu (hudce7.harvard.edu [140.247.198.27]) by us25.unix.fas.harvard.edu (Postfix) with ESMTP id 96D581D839B for <bill(a)herrin.us>; Wed, 16 Apr 2014 11:42:44 -0400 (EDT) Message-id: <fc.0066410e0938c8803b9aca007ca76832.938c881(a)hudce7.harvard.edu> Date: Wed, 16 Apr 2014 11:42:33 -0400 Subject: NDN: Re: DNS Issue with proofpoint.com From: Post Office ----=_--0938c881.0938c880.cf745569 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sorry. Your message could not be delivered to: Rich Borroff (Mailbox or Conference is full.) -- William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

1 0

Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
by Larry Sheldon 15 Apr '14

15 Apr '14

On 4/14/2014 7:50 PM, John Levine wrote: > In article <534C68F4.305(a)cox.net> you write: >> On 4/14/2014 9:38 AM, Matthew Black wrote: >>> Shouldn't a decent OS scrub RAM and disk sectors before allocating >>> them to processes, unless that process enters processor privileged >>> mode and sets a call flag? I recall digging through disk sectors on >>> RSTS/E to look for passwords and other interesting stuff over 30 >>> years ago. >> >> I have been out of the loop for quite a while but my strongly held >> belief is that such scrubbing would be an enormous (and intolerable) >> overhead ... > > It must be quite a while. Unix systems have routinely cleared the RAM > and disk allocated to programs since the earliest days. > > Pre-VM OS/360 may not have. HP-UX did not. Exec8 (OS1100) did not. What ever it was we ran on the 1401s and 360/30s (and 9300s) did not. We manually zeroed core on the 707xs but even then we knew it was a wasted 3 minutes because that was only done before the firs run of the day and might not happen again for several days (because each daily cycle took several days in some offices). MS-DOS and Windows (even still?) were notorious for not hurting "deleted" files. Is the heartbleed bug not proof positive that it is not being done today? -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

2 1

Pearl Harbor
by Donald Eastlake 14 Apr '14

14 Apr '14

This is getting pretty far afield so I thought I should at least change the subject. There was no initial withdrawal of the Japanese ambassador - it was the Japanese withdrawing from negotiations with the USA over USA demands -- essentially Japan declaring that it had given up on finding compromise and would not accede to USA demands for Japanese troop withdrawals. There were two messages related to the negotiations from the Japanese government to their embassy in Washington. The first was so long and meandering, that it has to be broken into 14 parts for transmission. Only in the final and 14th part, which was transmitted more than 24 hours after the first 13 parts were sent, did it direct the withdrawal from negotiations. This was considered within the Japanese government as tantamount to a declaration of war and it was felt that the attack would be dishonorable if it was not communicated to the USA government before the attack. Thus, there was a second much shorter message that specifically directed that the withdrawal be communicated to the US Government, if possible to the US Secretary of State, no later than 1pm later that day, Sunday December 7th. (It was immediately apparent to the American's reading this message that 1pm in Washington was dawn in Hawaii and probably the time of an attack.) There were some other messages sent about the same time including one ordering the Japanese embassy to destroy all cipher machines and codes. There were delays in USA decryption and translation of all of these messages. Then there was delay in getting what was clearly a threat of war to someone in Washington high enough to take action. But those were accomplished more than two hours before the attack. (The Japanese embassy in Washington was by no means immune to bureaucracy and delay and did not read the messages in time to implement then before the attack.) The fastest way to communicate with the US military in Hawaii would have been analog scrambled telephone which was, correctly, considered to be insecure and inappropriate for information derived from a Purple intercept. Such scrambled calls had been unscrambled by other countries before. So, it was given to the War Department's message center, who said that it would be delivered directly within a half an hour, after they encrypted it and sent it by radio. However, atmospheric conditions blocked that method and the encrypted message was given by the message center to a commercial wire carrier to send. It arrived and was printed out at the carrier's office in Honolulu at 7:33am local time, 22 minutes before the first bomb fell. Although obviously encrypted, it was apparently not marked for any special urgent handling -- remember the sender had though it would arrive directly at the military authorities in Hawaii over an hour earlier. As a result, it was not actually delivered to those authorities until 2:40pm, after the attack was over, and not read until 20 minutes later after decryption. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3(a)gmail.com On Mon, Apr 14, 2014 at 6:09 PM, Matthew Black <Matthew.Black(a)csulb.edu> wrote: > > IIRC, the message was sent via courier instead of cable or telephone to prevent interception. Did the military not even trust its own cryptographic methods? Or did they not think withdrawal of the Japanese ambassador was not very critical? > > > > matthew black > > california state university, long beach > > > > From: Donald Eastlake [mailto:d3e3e3@gmail.com] > Sent: Monday, April 14, 2014 8:28 AM > To: Matthew Black > Cc: William Herrin; nanog(a)nanog.org > > > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > > > > Matthew, > > > > On Mon, Apr 14, 2014 at 10:48 AM, Matthew Black <Matthew.Black(a)csulb.edu> wrote: > > Also on this same idea, in his book "The Puzzle Palace," James Bamford claims that we knew of the pending attack on Pearl Harbor but did nothing, because that would compromise we broke the Japanese Purple Cipher. > > > > I assume you refers to pages 36 through 39 of "The Puzzle Palace" which is almost entirely a recounting of bureaucratic fumbling and delay. The sensitivity of a Purple Cipher decode did cause the intercepted information to be sent by a less immediate means to the US Naval authorities in Hawaii. Nevertheless, it was sent with every expectation that those authorities would receive it before the time of the attack. We do not know what those authorities would have done it they had received the intercept information as expected, instead of receiving it about 6 hours after the first bomb struck Pearl Harbor. Your implication that Bamford says "we decided to do nothing" bears no relationship to what Bamford actually wrote. > > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3(a)gmail.com > > > > matthew black > california state university, long beach > > > -----Original Message----- > > From: William Herrin [mailto:bill@herrin.us] > Sent: Friday, April 11, 2014 2:06 PM > To: nanog(a)nanog.org > Subject: Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years] > > On Fri, Apr 11, 2014 at 4:10 PM, Niels Bakker <niels=nanog(a)bakker.net> wrote: > > Please go read up on some recent and less recent history before making > > judgments on what would be unusually gutsy for that group of people. > > > > I'm not saying this has been happening but you will have to come up > > with a better defense than "it seems unlikely to me personally". > > Let me know when someone finds the second shooter on the grassy knoll. > As for me, I do have some first hand knowledge as to exactly how sensitive several portions of the federal government are to the security of the servers which hold their data. They may not hold YOUR data in high regard... but the word "sensitive" does not do justice to the attention lavished on THEIR servers' security. > > In WW2 we protected the secret of having cracked enigma by deliberately ignoring a lot of the knowledge we gained. So such things have happened. But we didn't use enigma ourselves -- none of our secrets were at risk. And our adversaries today have no secrets more valuable than our own. > > -Bill > > >

1 0

Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
by Larry Sheldon 14 Apr '14

14 Apr '14

On 4/14/2014 3:05 PM, William Herrin wrote: > I thought vendors existed primarily as a place to hang the blame when > dealing with a manager or customer who just doesn't get it. Truth value very high. Humor value, less than none. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0

Re: [[Infowarrior] - NSA Said to Have Used Heartbleed Bug for Years]
by Larry Sheldon 14 Apr '14

14 Apr '14

On 4/14/2014 2:59 PM, Patrick W. Gilmore wrote: > Or we can flame anyone who tries, then wonder why no one is trying. Amen. I was just thinking, after reading the umpteenth message here about spam, about the times in the 1990's that I was literally driven away because I was trying to get ahead of the spam problem (which was then a drop in the bucket as compared to now). -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

1 0