- NANOG - lists.nanog.org

Re: Full Internet ASN <--> AS Name resolution
by Martin J. Levy 08 Jun '03

08 Jun '03

Mourad, Don't forget LACNIC... ftp://ftp.lacnic.net/pub/stats/lacnic/ ftp://ftp.lacnic.net/pub/stats/lacnic/lacnic.20030601 Martin --- At 04:00 PM 6/6/2003 +0200, Mourad BERKANE wrote: > >Hi NANOGers, > >Could someone forward me a .txt file including FULL INTERNET (ARIN + RIPE + APNIC) ASN <--> AS Name resolution table? > >I don't want to compile following regional dbase :-) > >ftp://ftp.arin.net/netinfo/asn.txt >ftp://ftp.apnic.net/pub/apnic/dbase/data/rpsl >ftp://ftp.ripe.net/ripe/dbase/ > >Thanks in advance >Mourad >

6 6

DDoS tracking / accounting tools
by Mike Tancsa 08 Jun '03

08 Jun '03

It appears someone started a DDoS (~ 500 hosts involved) attack against a customer IP in our network this morning at 6am EDT (~ 250Mb/s coming in on 3 links). None of the IP addresses are spoofed as there is a fixed set of about 500 hundred and all are coming in via paths that make sense from a bgp perspective. Also doing a quick sample of the ones still blasting at me across my private peers that have not null routed the /32 its clear that they are still pushing out packets as quick as possible judging by response times from those hosts. I now want to contact the individual network abuse departments of said networks so that they can take appropriate action against the 'owned' hosts involved. Does anyone know of or have a tool that can quickly take a list of IP addresses and summarize / generate the appropriate network contact info ? What about a tool to quickly summarize by AS ? Doing a quick random sample of the hosts involved 6 out of 10 were all windows type boxes and 4 had no ports open or were either firewalled or behind some home router. The boxes all seem to be blasting out packets 445 bytes long and the protocol appears to be randomized in the header 09:35:57.243330 0:a:f3:a5:c8:bc 0:d0:b7:27:55:43 ip 459: 211.135.33.199 > 64.7.138.8: ip-proto-253 425 (ttl 109, id 9477, len 445) 0x0000 4500 01bd 2505 0000 6dfd 66e1 d387 21c7 E...%...m.f...!. 0x0010 4007 8a08 0000 0000 0000 0000 0000 0000 @............... 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0040 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050 0000 and .. 18:23:59.553908 0:4:de:56:d:80 0:1:80:38:46:37 ip 459: h24-77-1-84.gv.shawcable.net > 64.7.138.8: icmp: echo reply 0x0000 4500 01bd 74e3 0000 7801 e8ac 184d 0154 E...t...x....M.T 0x0010 4007 8a08 0000 0000 0000 0000 0000 0000 @............... 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0040 0000 0000 0000 0000 0000 0000 0000 0000 ................ 18:28:32.069714 0:4:de:56:d:80 0:1:80:38:46:37 0800 459: 24.77.1.84 > 64.7.138.8: truncated-udplength 0 (ttl 120, id 15668, len 44 5) 0x0000 4500 01bd 3d34 0000 7811 204c 184d 0154 E...=4..x..L.M.T 0x0010 4007 8a08 0000 0000 0000 0000 0000 0000 @............... 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030 0000 0000 0000 0000 0000 0000 0000 0000 ................ Anyone recognize this DOS signature ? trinity v3 seems to have these capabilities but I have not seen it mentioned in some time... An oldie but a goodie, or something new ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

1 0

Re: Best Practices for Loopback addressing (Core routers & VPN CPE)
by Marc Binderberger 08 Jun '03

08 Jun '03

Another argument for public loopback/link addresses: merging networks. Fairly bad when you plan to merge two networks and loopback addresses are not unique anymore ;-) Regarding RIRs we haven't had real problems using public address space. As mentioned by Christopher: talk to them is the solution. Of course they will ask you if you can't use private address space - that's their job! Management in VPN networks: plan for address collisions. Anything else but (your own) public addresses can be used by the customers. 198.18.0.0/15 doesn't help you for all times ("oh, we use that for our extranet as all partners had 10.x.x.x in use like us"). Maybe using a separate management VRF on the CPE and DLCI/PVC/VLAN on the CPE-PE link is an option. Or use management address ranges in all 3 RFC1918 networks to lower the probability of collisions - often customers use only 1 or 2 address ranges. I've also seen NAT on the provider end of the management DLCI/PVC together with management address ranges per customer network. Regards, Marc On Friday, June 6, 2003, at 06:05 PM, m.rapoport(a)completel.fr wrote: > > Hello, > I was wondering what are the choices made by Service Providers on the > loopback addressing. > The context is an IP/MPLS Backbone providing both Internet and BGP-VPN > services. > > I have 2 different cases to address : > > 1) Loopbacks on the backbone routers : > I have the feeling that general practice is to use public IP adresses > for > Core routers. > > However, considering that these loopbacks are only used for routing > protocols (OSPF,BGP, LDP) > and for network management (SNMP, telnet, ...) and that these > addresses > don't need to visible from public Internet > (not seen in traceroute, not seen on Internet BGP announces ...) I am > considering to > use private RFC1918 for a new Backbone deployment. > > N.B. : Assumption is that e-BGP sessions with Internet peers are done > on > public interface IP, not on loopback IP. > > Is there some specific case I am missing where public loopback IP is > required, and therefore > private adressing would break something (maybe some Carrier-to-Carrier > scenario ?) . > > I also plan to use RFC1918 addresses for Internet CPE routers > loopbacks. > > 2) Loopback on CPE routers of the MPLS VPN customers. > For this case, the issue is to assign the adresses in a global range > for > all the CPE of > all the VPN customers. > In fact, all these loopback will need to be part of the Network > Management > VPN for supervision needs. > Using RFC 1918 addresses might create trouble as there is a very high > chance that the VPN customers > are already using 1918 addresses, this might generate addresses > conflicts. > Addresses unicity among all the customers is required due to the > Network > Management VPN common > to all the customers. > Using public address guarantee unicity, but will create issues with > public > registries, considering that > these addresses are used for internal needs. > I am considering to use the 198.18.0.0/15 defined in RFC 2544 and > listed in > RFC 3330 as reserved for > lab testing. > I suppose that no VPN customer uses this prefix for its internal IP > addressing, and as these addresses don't > need to be announced on Internet. > Do you suggest to use an other prefix than 198.18.0.0/15 for this > purpose ? > > If you consider your adressing policy as touchy topic in terms of > security, don't hesitate to reply in private ... > Regards, > > > > -- Marc Binderberger <marc(a)sniff.de> Powered by *BSD ;-)

1 0

RE: ntop and/or sflow
by Temkin, David 08 Jun '03

08 Jun '03

I find ntop crashes quite often under heavy traffic loads, moreso if you're using it realtime versus as a sflow/netflow collector, but even then it still crashes. Also, clicking too quickly on certain pages in ntop will crash the whole thing :-) -----Original Message----- From: Timothy Brown [mailto:tim@tux.org] Sent: Friday, June 06, 2003 3:45 PM To: nanog(a)merit.edu Subject: ntop and/or sflow Is anyone doing work with ntop as an sFlow collector, or with sFlowtool to translate sFlow data into NetFlow data for use with other toolsets? Can anyone speak to the usage of ntop in a production network? Thanks, Tim IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

Internet routes in Gobal Routing Table or in a VRF ?
by m.rapoport＠completel.fr 08 Jun '03

08 Jun '03

Hello again, Another question for BGP VPN experts. If you provide Internet access and VPN service on the same MPLS Core network, what are the pro and cons to transport in the core the public internet routes (the full 120.000 prefixes) as VPN-V4 prefixes and announce them through a VRF rather than as common global routes ? What are the trends in terms of security vs memory vs stability ? Thanks in advance.

2 1

Anybody home at SBC?
by Jeff Workman 08 Jun '03

08 Jun '03

Can somebody from SBC's abuse department please contact me off-list? Calling the phone number I have for the abuse department results in getting forward to a voicemail box to which nobody is subscribed, according to the recording. -- Jeff Workman | jworkman(a)pimpworks.org | http://www.pimpworks.org

2 1

Full Internet ASN <--> AS Name resolution
by Mourad BERKANE 07 Jun '03

07 Jun '03

Hi NANOGers, Could someone forward me a .txt file including FULL INTERNET (ARIN + RIPE + APNIC) ASN <--> AS Name resolution table? I don't want to compile following regional dbase :-) <ftp://ftp.arin.net/netinfo/asn.txt> ftp://ftp.arin.net/netinfo/asn.txt <ftp://ftp.apnic.net/pub/apnic/dbase/data/rpsl> ftp://ftp.apnic.net/pub/apnic/dbase/data/rpsl <ftp://ftp.ripe.net/ripe/dbase/> ftp://ftp.ripe.net/ripe/dbase/ Thanks in advance Mourad

2 1

Best Practices for Loopback addressing (Core routers & VPN CPE)
by m.rapoport＠completel.fr 06 Jun '03

06 Jun '03

Hello, I was wondering what are the choices made by Service Providers on the loopback addressing. The context is an IP/MPLS Backbone providing both Internet and BGP-VPN services. I have 2 different cases to address : 1) Loopbacks on the backbone routers : I have the feeling that general practice is to use public IP adresses for Core routers. However, considering that these loopbacks are only used for routing protocols (OSPF,BGP, LDP) and for network management (SNMP, telnet, ...) and that these addresses don't need to visible from public Internet (not seen in traceroute, not seen on Internet BGP announces ...) I am considering to use private RFC1918 for a new Backbone deployment. N.B. : Assumption is that e-BGP sessions with Internet peers are done on public interface IP, not on loopback IP. Is there some specific case I am missing where public loopback IP is required, and therefore private adressing would break something (maybe some Carrier-to-Carrier scenario ?) . I also plan to use RFC1918 addresses for Internet CPE routers loopbacks. 2) Loopback on CPE routers of the MPLS VPN customers. For this case, the issue is to assign the adresses in a global range for all the CPE of all the VPN customers. In fact, all these loopback will need to be part of the Network Management VPN for supervision needs. Using RFC 1918 addresses might create trouble as there is a very high chance that the VPN customers are already using 1918 addresses, this might generate addresses conflicts. Addresses unicity among all the customers is required due to the Network Management VPN common to all the customers. Using public address guarantee unicity, but will create issues with public registries, considering that these addresses are used for internal needs. I am considering to use the 198.18.0.0/15 defined in RFC 2544 and listed in RFC 3330 as reserved for lab testing. I suppose that no VPN customer uses this prefix for its internal IP addressing, and as these addresses don't need to be announced on Internet. Do you suggest to use an other prefix than 198.18.0.0/15 for this purpose ? If you consider your adressing policy as touchy topic in terms of security, don't hesitate to reply in private ... Regards,

6 5

Bugbear.b (worm du jour)
by Eric Anderson 06 Jun '03

06 Jun '03

Is this showing up as an issue for anyone? All I'm looking at is an MSNBC story which gives me the impression that it's a pretty low-bandwidth deal. It sounds like it requires intervention by the end user (or a system reboot) to activate it, so the propagation rate ought to be very low. http://vil.mcafee.com/dispVirus.asp?virus_k=100358 http://www.msnbc.com/news/922529.asp?0cv=CB10 -- +---------------------------------------------------------------------+ | Eric W. Anderson E-Mail: anderson(a)cs.uoregon.edu | | Computer and Information Science / Phone: (541)346-1381 | | Advanced Network Technology Center USPS: CIS Department | | University of Oregon University of Oregon | | Eugene, OR 97403-1202 | | | | http://www.cs.uoregon.edu/~anderson/ | +---------------------------------------------------------------------+

3 3

ntop and/or sflow
by Timothy Brown 06 Jun '03

06 Jun '03

Is anyone doing work with ntop as an sFlow collector, or with sFlowtool to translate sFlow data into NetFlow data for use with other toolsets? Can anyone speak to the usage of ntop in a production network? Thanks, Tim

1 0