- Test - lists.nanog.org

Gwd: crypted document
by Cmadams 03 Aug '07

03 Aug '07

WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] Message.scr, virus infected: W32/Bagle-CF. Action taken: deleted VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-CF was detected in email attachment [2.2] Message.scr. The infected attachment has been deleted.

9 11

I35 bridge collapse in Minneapolis
by Sean Donelan 03 Aug '07

03 Aug '07

Telephone call gapping by the major long distance carriers into the region seemed to be in effect for a while. I don't believe this is one of the five critical Mississippi River fiber crossing points, so Internet traffic appears mostly unaffected.

9 9

price_03-Aug-2007
by Cmadams 03 Aug '07

03 Aug '07

WARNING!!! (from bach.merit.edu) The following message attachments were flagged by the antivirus scanner: Attachment [2.2] latest_price03-Aug-2007.zip, virus infected: W32/Bagle-RC,W32/Bagle-QW. Action taken: deleted VIRUS WARNING Message (from bach.merit.edu) The virus W32/Bagle-RC,W32/Bagle-QW was detected in email attachment [2.2] latest_price03-Aug-2007.zip. The infected attachment has been deleted.

1 0

Fwd: [Err] Re: Gwd: crypted document
by Hex Star 03 Aug '07

03 Aug '07

Uhhh...what??? ---------- Forwarded message ---------- From: postmaster(a)entum.com <postmaster(a)entum.com> Date: Aug 2, 2007 7:26 PM Subject: [Err] Re: Gwd: crypted document To: hexstar(a)gmail.com Transmit Report: cjw(a)yutc.co.xn--kr-j41ir84f <cjw(a)yutc.co.kr%EC%97%90%EA%B2%8C> 메일 발송을 2번 시도했지만 실패하였습니다. (실패 이유 : 554 Message rejected because it may contain Sober worm virus( 211.48.62.215)) <참고> 실패 이유에 대한 설명 User unknown :메일을 수신할 사용자가 존재하지 않음 Socket connect fail:수신 메일 서버와 연결 실패 DATA write fail :수신 메일 서버로 메세지 송신 실패 DATA reponse fail :수신 메일 서버로부터 메세지 수신 실패 Final-Recipient: rfc822;cjw(a)yutc.co.kr Diagnostic-Code: smtp; 554 error - Message rejected because it may contain Sober worm virus(211.48.62.215) Action: failed Status: 4.0.0 ---------- Forwarded message ---------- From: "Hex Star" <hexstar(a)gmail.com> To: Cmadams <cmadams(a)hiwaay.net>, nanog(a)merit.edu Date: Thu, 2 Aug 2007 19:16:40 -0700 Subject: Re: Gwd: crypted document On 8/2/07, Cmadams <cmadams(a)hiwaay.net> wrote: > > WARNING!!! (from bach.merit.edu) > > The following message attachments were flagged by the antivirus scanner: > > Attachment [2.2] Message.scr, virus infected: W32/Bagle-CF. Action taken: > deleted > > Ok. See attach. > > > > VIRUS WARNING Message (from bach.merit.edu) > > The virus W32/Bagle-CF was detected in email attachment [2.2 ] Message.scr. > The infected attachment has been deleted. > > Why would someone in the ISP industry try to spread a virus? Ironically I suppose a ISP admin may have their own computer infected... :P

1 0

Re: 40Gbit private peer
by Leigh Porter 02 Aug '07

02 Aug '07

I hope they have good peering :) Blake Pfankuch wrote: > I would be interested to see how a torrent reacts on a line like that :D > > -Blake > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of > Leigh Porter > Sent: Thursday, August 02, 2007 12:36 PM > To: Peter Lothberg > Cc: nanog(a)nanog.org > Subject: Re: 40Gbit private peer > > > Hey, > > BEcause you really need it ;-) > > 30 second input rate 77849000 bits/sec, 7236 packets/sec > 30 second output rate 17464000 bits/sec, 5023 packets/sec > > Very nice though, it'll be great for all the P2P. > > -- > Leigh > > > > Peter Lothberg wrote: > >> SUnet (AS1653) and STUPI (AS1880) want to announce that >> we have brought up what we believe is the first private >> peer at 40G between two independent networks. >> >> It speaks IPv4, IPv6 both unicast and multicast. >> >> -Peter >> >> >> > ------------------------------------------------------------------------ > >> RP/0/RP0/CPU0:HFR1-F#sh int pos 0/3/0/0 >> POS0/3/0/0 is up, line protocol is up >> Interface state transitions: 2 >> Hardware is Packet over SONET/SDH >> Description: OC768 Private Peering to Sunet <ip(a)nordu.net> >> Internet address is 193.11.20.146/30 >> MTU 4474 bytes, BW 39813120 Kbit >> reliability 255/255, txload 0/255, rxload 0/255 >> Encapsulation HDLC, crc 32, controller loopback not set, keepalive >> > set (10 sec) > >> Last clearing of "show interface" counters 1d00h >> 30 second input rate 77849000 bits/sec, 7236 packets/sec >> 30 second output rate 17464000 bits/sec, 5023 packets/sec >> 115627177 packets input, 155140727534 bytes, 0 total input drops >> 0 drops for unrecognized upper-level protocol >> Received 0 runts, 0 giants, 0 throttles, 0 parity >> 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort >> 78946374 packets output, 34499886901 bytes, 0 total output drops >> 0 output errors, 0 underruns, 0 applique, 0 resets >> 0 output buffer failures, 0 output buffers swapped out >> >> RP/0/RP0/CPU0:HFR1-F#sh controllers soNET 0/3/0/0 >> Port SONET0/3/0/0: >> >> Status: Up >> >> Loopback: None >> >> SECTION >> LOF = 0 LOS = 0 BIP(B1) = 0 >> LINE >> AIS = 0 RDI = 0 FEBE = 0 BIP(B2) = 0 >> PATH >> AIS = 0 RDI = 0 FEBE = 0 BIP(B3) = 0 >> LOP = 0 NEWPTR = 0 PSE = 0 NSE = 0 >> PLM = 0 TIM = 0 >> Detected Alarms: None >> Asserted Alarms: None >> Mask for Detected->Asserted: None >> Detected Alerts: None >> Reported Alerts: None >> Mask for Detected->Reported: None >> Alarm reporting enabled for: SLOS SLOF SF_BER PLOP >> Alert reporting enabled for: B1-TCA B2-TCA B3-TCA >> >> Framing: SONET >> SPE Scrambling: Enabled >> C2 State: Stable C2_rx = 0x16 (22) C2_tx = 0x16 (22) / Scrambling >> > Derived > >> S1S0(tx): 0x0 S1S0(rx): 0x0 / Framing Derived >> >> PATH TRACE BUFFER : STABLE >> Remote hostname : c1sth-re1 so-7/0/0 >> Remote interface: >> Remote IP addr : >> >> APS >> No APS Group Configured >> Protect Channel 0 DISABLED >> Rx(K1/K2) : 0x00/0x00 >> Tx(K1/K2) : 0x00/0x00 >> Remote Rx(K1/K2): 1/ Remote Tx(K1/K2): 1/ >> >> >> BER thresholds: SF = 10e-3 SD = 10e-6 >> TCA thresholds: B1 = 10e-6 B2 = 10e-6 B3 = 10e-6 >> >> Optics type: VSR2000-3R2 (2km) >> Clock source: internal (actual) internal (configured) >> >> Optical Power Monitoring (accuracy: +/- 1dB) >> Rx power = 1.3796 mW, 1.4 dBm >> Tx power = 1.7380 mW, 2.4 dBm >> Tx laser current bias = 58.3 mA >> >>

1 0

Questions about populating RIR with customer information.
by Drew Weaver 02 Aug '07

02 Aug '07

Up until recently, we were only providing the RIR database with information about our larger allocations /24 or larger. We have noticed however that many anti-spam organizations such as Spamhaus, and Fiveten will use the lack of information regarding an IP allocation as a blank check to blacklist entire /24s when they are really targeting a single /30 or a /29. As such we are examining publishing information for all allocations in the RIR database (/30s, /29s, etc). My question, mostly is related to the privacy of the customer whom the space is being allocated to. Has anyone ever had an issue where they have published a user's information and the user had an issue with it? Is there some way that we can 'proxy' the information so that it simply states that the /29 has been allocated to a customer but it doesn't provide their contact information? Most of our customers are co-location and dedicated hosting customers and we are simply unsure whether or not there are implications (legal or otherwise) in publishing our customer data in a public RIR database. Does anyone have any thoughts on this? Sorry if this is the wrong place to ask. Thanks, -Drew

8 7

BotHunter
by Marcus H. Sachs 02 Aug '07

02 Aug '07

All, SRI and Georgia Tech have been working on a pretty cool new tool that will quickly locate bot traffic inside a network. A government/military version of this software has been in use successfully for about a month, and a public version was made available this week. BotHunter introduces a new kind of passive network perimeter monitoring scheme, designed to recognize the intrusion and coordination dialog that occurs during a successful malware infection. It employs a novel dialog-based correlation engine (patent pending), which recognizes the communication patterns of malware-infected computers within your network perimeter. BotHunter is available for download at http://www.cyber-ta.org/BotHunter/ and runs under Linux Fedora, SuSE, and Debian distributions. There is also a highly interactive honeynet using BotHunter run by SRI you should look at. The URL is http://www.cyber-ta.org/releases/malware-analysis/public/. We are detecting dozens of new infections each day and this site is very helpful in understanding the behavior of the received malware. Also, it generates a nice list of potentially evil IP addresses and DNS queries. For both the BotHunter software and the honeynet we'd appreciate any feedback on ways to improve them. Contact details are in the download package and on the website. Marc -- Marcus H. Sachs, P.E. <marcus.sachs(a)sri.com> SRI International 1100 Wilson Blvd Suite 2800, Arlington VA 22209 USA tel +1 703 247 8717 fax +1 703 247 8569 mob +1 703 932 3984

1 0

Cisco Interface configuration control
by Sean Figgins 02 Aug '07

02 Aug '07

I'm looking to see if anyone has used the "privilege" configuration options on Cisco routers and switches to control interfaces that users are allowed to configure. I'm looking to allow a certain set of our users to only configure a set of interfaces, while allowing our top-level operations guys to configure all interfaces. Today, we accomplish this through tacacs, but we are looking at some hardware that will have conflicting interfaces. Is anyone doing specific interface configuration control on Cisco devices? -Sean

1 0

Telenor AS8210 and AS8434 technical contact?
by Anonymous List User 01 Aug '07

01 Aug '07

I must apologize for posting this anonymously. Can anybody provide me with a technical contact at Telenor (AS8210 and AS8434) to discuss European Teleport / VSAT network issues? Thanks...

2 1

Re: An Internet IPv6 Transition Plan
by Chad Oleary 31 Jul '07

31 Jul '07

I'm wondering if we should really be considering a "transition" plan at this point? From what I can see, there will be many IPv4 only networks around for many years to come. The technology doesn't have an expiration date. Rather than focusing on "transitioning" every network from v4 to v6, shouldn't this draft focus on how an "initial implementation of v6" is going to interop with v4 as we know it today? Personally, I see v6 as something that needed and desired by the certain groups. However, when looking at the enterprise, for example, better solutions are needed for things like multi-homing, last I checked. IPv4 will get more expensive as time goes on, but some will be willing to pay that price. Perhaps the biggest challenge, IMO, in this much more dynamic network, is DNS. How do I (or my new vendor) readdress every node at my site, and actually know what device has what address? rtadvd doesn't do DNS updates. DHCPv6 doesn't even hand out addresses. I've seen host-based approaches, is that the answer? How does all this happen securely? DNSSEC comes to mind, but that's a whole different story. Add, since a host can have many preferred addresses, which to use? How do deprecated addresses get withdrawn from DNS? I think a more successful approach would be to address how we plan to add v6 to the current network. Perhaps a transition plan is appropriate for some networks. But, I don't think this is a one-size fits all issue. This is the part that I have issue with: 2.3.4 Service Providers area MAY continue to offer IPv4-based Internet connectivity to their customers. Organizations MAY continue to use IPv4-based Internet connectivity. Organizations MAY remove IPv4-based Internet connectivity from Internet-facing servers. If I'm an IPv4 only site outside of this "perfect world", I just lost connectivity to parts those that moved to IPv6. Not everyone will follow this plan, and this will happen. For now, we need to learn how to co-exist. Thanks for your time, Chad

19 41