- Test - lists.nanog.org

Re: [Full-Disclosure] Mydoom DDoS attack time table
by James Edwards 31 Jan '04

31 Jan '04

On Sat, 2004-01-31 at 08:27, Gadi Evron wrote: > I apologize if in my previous email I didn't make it clear, this is an > important issue for system administrators world wide, so I am emailing > again in regard to this subject alone - a time table for the Mydoom DDoS > attack. > > In my post from the 30th of January with the subject: "Refuting > tall-tales and stories about the Mydoom.A and Mydoom.B worms" - > we released an analysis of the Mydoom worms DoS mechanism, refuting > rumors about it not existing (http://www.math.org.il/mydoom-facts.txt) > > You can find a _time_table _for when the DDoS attack will happen, as > calculated by a C program Joe Stewart wrote at: > http://www.math.org.il/mydoom-a-timeline.txt > > Mydoom.B has a time line too, but it can't be predicted as definitely > because of an extra random check. > > For more information about the DoS attack itself performed by the worm, > how and when (including reverse engineering bits) you should check the > above mentioned article. > > Gadi Evron. > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html

1 0

reminder ipv4 allocation 83/8 (IANA to RIPE-NCC)
by Christian Steger 31 Jan '04

31 Jan '04

hello there, i just want to remind you, that IANA has allocated an new block in november 2003 (83/8). the reason why i remind again here is, we (as8514) have received a block within that range (83.64/15 --> RIPE-NCC) in the end of 2003 and customers complains still sites in the state they can´t reach. i kindly ask you to modifiy the BOGON list. thanks! christian steger -- Christian Steger | R & D: Network Fon. 059 999 0 | Inode GmbH, Backbone Austria Fax. 059 999 6699 | Interxion, Shuttleworth Strasse 4-8, 1210 Wien www.inode.at | Raserei verbindet uns.

2 1

RE: CIsco 7206VXR w/NPE-G1 Question
by Michel Py 31 Jan '04

31 Jan '04

> Richard J. Sears wrote: > I am looking at upgrading my current 7507 backbone routers. > Each of my routers has dual RSP4s Keep in mind that dual RSP does _not_ mean load sharing; it's for redundancy, if you can get RPR+ to work the way you want that is. > and I was thinking of upgrading them to RSP8s when I > started reading about the new 7206VXRs with the NPE-G1 engine. > I was wondering if anyone has had experience with this > router/engine combination, how well they perform in comparison > to the RSP8s and actual total traffic capabilities when > utilizing all three gig ports with a mixture of OC3, Gig and > DS3 connections as well. In my experience, no 7507 is capable of this, nor a 7206VXR. As pointed out not too long ago, the RSP8 although intrinsically slower than a NPE-G1 will take more load because a lot of processing can be done by the VIPs in the 7507. The deal is that in a 7200 the NPE does the work of the RSP _plus_ the work of three VIPs; even if it's faster, it might not be that fast. That being said, I don't consider reasonable to get gig+ traffic trough a 7507; in my experience a 7500 will push 500mbps of traffic but will have trouble swallowing a full gig. My limited experience with the 7206 says that it might eventually be able to push _one_ gig from one PA to another, but not aggregate: say you have 4 or 5 OC3s aggregating into a GigE with some ACLs (which would run distributed on a 7500) I don't think that even the NPE-G1 is up to the task. IMHO, if you stay well below a gig, these el-cheapo eBay RSP8 deals are a valid solution but if you go over, GSR or Juniper is your answer. The 7200 has never been a core nor backbone router. Michel.

4 5

RE: CIsco 7206VXR w/NPE-G1 Question
by sthaug＠nethelp.no 31 Jan '04

31 Jan '04

> > PXF is found in the 7400 (old) and 7300 (newer) series. > > Not true. 7401 has a PXF. It's essentially an NSE-1 with GE/IO in a > pizza box. 7301 is based on the NPE-G1 and doesn't have a PXF anywhere > in sight. On the other hand, the (original) 7304 used PXFs, on the NSE-100 forwarding engine. Cisco later introduced the NPE-G100 for the 7304 with a much more powerful CPU, but no PXF. Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

1 0

Re: Impending (mydoom) DOS attack
by Mikael Abrahamsson 31 Jan '04

31 Jan '04

;; ANSWER SECTION: www.sco.com. 60 IN A 216.250.128.12 As far as I can see, someone has taken precation and lowered the TTL on www.sco.com to 60 seconds so any DOS attack towards www.sco.com can be hindered by them changing their DNS information. This wont stop any DoS in progress, or it might, I dont know if the worm will do repeated DNS resolves or only do it once and keep sending data to that IP until reboot. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 0

RE: CIsco 7206VXR w/NPE-G1 Question
by Michel Py 31 Jan '04

31 Jan '04

>> Michel Py wrote: >> That would be where the NPE-G1 would be better than an RSP8; > jlewis(a)lewis.org [mailto:jlewis@lewis.org] > Isn't it somewhat wrong to compare the NPE-G1 to any RSP > since most of the packets, most of the time, are handled > by the processors on the VIPs and never bother the RSP In general, yes indeed. However, you have to place it in the same context as I did, quoted below: >>> alex(a)pilosoft.com wrote: >>> flow-based means router's performance is based on number >>> of flows established, and first packet of each 'flow' is >>> processed differently [slower] from all other within the >>> flow, and things like nachi will kill it. >> Michel Py wrote: >> That would be where the NPE-G1 would be better than an RSP8; In this very case, where a large part of the traffic is a shitload of new flows, dCEF is irrelevant and the NPE-G1 has indeed an advantage over any RSP because it has a 700Mhz processor and the RSP16 is 400Mhz and the RSP8 250Mhz. Of course, this assumes that you are actually doing flow-based routing, which I don't see being that common among ISPs. > If you take a 7500 as far as you can (RSP16, VIP6-80s), > then how does it compare to a 7206VXR/NPE-G1? Ah that's an interesting academic question, and although I will take a shot at it, 1. The question is vague. 2. #include <disclaimer.h> 3. Can't really be answered without testing it. 4. Even when actually testing it with real traffic, your mileage may vary as the traffic patterns being used can indeed greatly the results. That being said, here's my take at it: We have on one side 7206VXR with NPE-G1 and 6x PA-POS-OC3 (or similar) And on the other: 7507MX with RSP16, 3x VIP6-80, 6x PA-POS-OC3 (or similar), 2x GEIP [ this setup is flawed in the first place, as the GEIP is based on the VIP2-50; the correct setup should be: 7507MX with RSP16, 4x VIP6-80, 6x PA-POS-OC3 (or similar), 2x PA-GE. Unfortunately, the VIP6-80 does not support the PA-GE :-( ] On each router: two of the GigE are connected to tier-1 transit, and the DS3s to either big customer or remote pop. I call this a draw. On one hand, if the traffic between the two GigE is not well balanced, the 7507 has a problem with the throughput of the GEIP. On the other hand, the NPE-G1 has a 700 Mhz CPU, but has to deal with all of the following: - two GigE - six PAs - BGP and flows where the 7507 has: - 2x 200Mhz VIP2-50 for the GigE - 3x 400Mhz VIP6-80 for the PAs - 1x 400Mhz RSP16 for BGP and flows My take is: in some situations, the 7507 will be better and in some others the 7206 will be better. The weak point of the 7507 setup is the GEIP, the weak point of the 7206 is that is has only one CPU. Now, _if_ in the 7507 you could replace 2x GEIP with 1x VIP6-80 + 2x PA-GE, I would give a clear advantage to the 7507 setup. In any case, a 7600 will beat the crap out of any 7200. Michel.

1 0

RE: CIsco 7206VXR w/NPE-G1 Question
by Lincoln Dale 31 Jan '04

31 Jan '04

At 03:51 AM 31/01/2004, alex(a)pilosoft.com wrote: >Keep in mind, 72xx is still flow-based 72xx NPE-xxx is NOT flow-based -- unless you explicitly configure it to be. (i.e. disable CEF, enable flow switching). CEF is prefix-based switching - where all possible prefixes (routes/RIB) are already programmed into the forwarding table (FIB). anything not programmed into the FIB doesn't exist in the RIB, ergo there is no route therefore is dropped. i believe the words you're looking for is "NPE-xxx is SOFTWARE-based forwarding". this part is true enough - but a NPE-G1 has far more cpu cycles to switch/route than previous NPE-400/300/225/200/150 et al. software-based forwarding isn't so bad -- it means that platforms such as the 7200 typically have lots of features. this is different to the NSE-xxx which is part software-based forwarding and part PXE-based forwarding. the exact features accelerated by PXE varies depending what code release is used. your said: flow-based means router's performance is based on number of flows established, and first packet of each 'flow' is processed differently [slower] from all other within the flow, and things like nachi will kill it. no, this isn't true. (at ieast, it isn't unless you explicitly configure it that way). for a service-provider, you wouldn't want to use it in any forwarding mode other than CEF, unless there is very good reason to. to provide you with a summary of forwarding paths and their uses: CEF switching: prefix-based pre-populated FIB dCEF switching: distributed version of CEF - typically each linecard has its own FIB and therefore switching decisions are distributed per linecard Fast switching: destination-based demand switching. a 'route cache' exists of destinations to be forwarded to. the first packet to a destination is "process switched", which installs the route-cache entry. subsequent packets are switched in the "fast" (aka interrupt) path. Process switching: all packets received (at interrupt level) are queued for process-level to route. then there's Flow Switching, whose definition has changed over time: Flow Switching: a variation on Fast-switching, but where a flow-entry is created based on a 5-tuple (srcip/dstip/proto/srcport/dstport/TOS). first packet is process- switched, which installs the flow entry, subsequent packets are switched at interrupt level now, Flow Switching has changed over time. you can enable both CEF+Flow and Flow simply becomes an accounting method that is useful for netflow - but you continue to have packets switched using CEF. as to the exact level of forwarding used for each packet, that varies -- if you enable a feature that isn't in the CEF path, then the packet is switched using the next-lower-layer that supports the 'feature'. for service-provider type environments, there aren't too many features necessary for /most/ deployments that aren't already covered in CEF on 7200, so you're mostly ok there. this is just a brief description of how a 72xx works - and there are many permutations and differences between different platforms and boxes. if you want the full rundown, Phil Harris normally gives a "Router Architecture" presentation at every Networkers i've ever attended, and it covers all this and more. cheers, lincoln. disclosure: my other email address is ltd(a)cisco.com, but i work in Fibre Channel not IP these days.

1 0

RE: CIsco 7206VXR w/NPE-G1 Question
by Jack.W.Parks＠alltel.com 31 Jan '04

31 Jan '04

Does anyone have definitive speed results on the 3 "built-in" Gig ports on the NPE-G1? I know that they aren't attached to the PCI Buses, and don't consume bandwidth points, but all of that is mute. Can all three of the ports do line rate Gig? The Gig PA is limited to 400Mbps. I have seen posts that allude to the fact the max throughput on the 3 Gigs are 800Mbps. It's is like a big mystery that cannot be solved. With a "J" M7i, I know I'm going to get line rate per port up to the total forwarding capacity of the FPC. We are trying to create a comparison matrix and any info you have would be great. Jack -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Simon Hamilton-Wilkes Sent: Friday, January 30, 2004 9:36 AM To: nanog(a)merit.edu Subject: RE: CIsco 7206VXR w/NPE-G1 Question One more interesting feature - if you need a 4th GigE port, you can add the GigE I/O card which still uses none of the bus bandwidth points. The buses are fine for OC3 and below... Simon ****************************************************************************************** The information contained in this message, including attachments, may contain privileged or confidential information that is intended to be delivered only to the person identified above. If you are not the intended recipient, or the person responsible for delivering this message to the intended recipient, ALLTEL requests that you immediately notify the sender and asks that you do not read the message or its attachments, and that you delete them without copying or sending them to anyone else.

4 3

Fw: Impending (mydoom) DOS attack
by james 31 Jan '04

31 Jan '04

OK, enough ppl are asking so I will post this public, instead of just sending this to those who asked. Since I do not understand assembly or FORTH I cannot verify what this guy on the full disclosure list said & so far no one on the list is commenting on this persons post. So I make NO claims about this. James Edwards Routing and Security Administrator jamesh(a)cybermesa.com At the Santa Fe Office: Internet at Cyber Mesa Store hours: 9-6 Monday through Friday 505-988-9200 SIP:1(747)669-1965 This is from the full disclosure list: : : : : Here's why people have been getting inconsistent results when setting : : the system date forward and looking for the DoS attack to start: : : : : Begining of DDoS date check subroutine: : : : : 4A3DB0 PUSH EBP ; callCreateSCOddos : : 4A3DB1 MOV EBP,ESP : : 4A3DB3 SUB ESP,10 : : : : : : Get the current system time as a FILETIME struct: : : : : 4A3DB6 LEA EAX,DWORD PTR SS:[EBP-8] : : 4A3DB9 PUSH EAX : : 4A3DBA CALL DWORD PTR DS:[<&KERNEL32.GetSystemTimeAsFileTime>] : : : : : : Convert the stored DoS start date from SystemTime to FileTime: : : : : 4A3DC0 LEA EAX,DWORD PTR SS:[EBP-10] : : 4A3DC3 PUSH EAX : : 4A3DC4 MOV EAX,DWORD PTR SS:[EBP+8] : : 4A3DC7 ADD EAX,214 : : 4A3DCC PUSH EAX ; Feb 1, 2004 : : 4A3DCD CALL DWORD PTR DS:[<&KERNEL32.SystemTimeToFileTime>] : : : : : : Compare high-order dword dwHighDateTime: : : : : 4A3DD3 MOV EAX,DWORD PTR SS:[EBP-4] : : 4A3DD6 CMP EAX,DWORD PTR SS:[EBP-C] : : 4A3DD9 JB SHORT <message.skipDoS> : : : : : : Compare low-order dword wLowDateTime: : : : : 4A3DDB MOV EAX,DWORD PTR SS:[EBP-8] : : 4A3DDE CMP EAX,DWORD PTR SS:[EBP-10] : : 4A3DE1 JB SHORT <message.skipDoS> : : : : : : Start the DoS: : : : : 4A3DE3 CALL <message.createSCOddos> ; DoS_Loop : : 4A3DE8 PUSH 400 : : 4A3DED CALL DWORD PTR DS:[<&KERNEL32.Sleep>] : : 4A3DF3 JMP SHORT <message.DoS_Loop> : : 4A3DF5 LEAVE ; skipDos : : 4A3DF6 RETN : : : : >From MSDN: : : The FILETIME structure is a 64-bit value representing the number of : : 100-nanosecond intervals since January 1, 1601 (UTC). : : : : typedef struct _FILETIME { : : DWORD dwLowDateTime; : : DWORD dwHighDateTime; : : } FILETIME, : : *PFILETIME; : : : : The stored starttime as filetime is: : : 0xbe9ecb00 : : 0x01c3e8dd : : : : Because the dwords are compared independently, the DoS will not start : : anytime the current dwLowDateTime is less than 0xbe9ecb00, no matter : : what the dwHighDateTime is. Obviously, this is close to three-quarters : : of the time. : : : : -Joe : : : : -- : : Joe Stewart, GCIH : : Senior Security Researcher : : LURHQ http://www.lurhq.com/ : : : : _______________________________________________ : : Full-Disclosure - We believe in it. : : Charter: http://lists.netsys.com/full-disclosure-charter.html : : ----- Original Message ----- : : From: "bcm" <bcm(a)inkline.com> : : To: <nanog(a)merit.edu> : : Sent: Friday, January 30, 2004 2:18 PM : : Subject: Impending (mydoom) DOS attack : :

1 0

RE: CIsco 7206VXR w/NPE-G1 Question
by Michel Py 31 Jan '04

31 Jan '04

> alex(a)pilosoft.com wrote: > flow-based means router's performance is based on number > of flows established, and first packet of each 'flow' is > processed differently [slower] from all other within the > flow, and things like nachi will kill it. That would be where the NPE-G1 would be better than an RSP8; however what I don't like is when you rely on the internal switching of the NPE-G1 you end up creating a 1-slot router with the PAs then becoming substandard additions. I understand that money is an issue, but the original question was about backbone use and I would rather go with a 7603 or a 7606 instead of a 7206VXR. Michel.

3 2