November 1999 - NANOG - lists.nanog.org

bgp blackhole lists and transit providers
by Mike Tancsa 10 Nov '99

10 Nov '99

Lately, we have been running into this problem more and more. One of our upstreams AT&T buys transit from Teleglobe. Teleglobe it seems subscribes to the maps.vix.com realtime blackhole list via BGP. Now, I am all for limiting SPAM and such, but its starting to be an operational headache having to deal with customers asking our support staff why they cannot get to a certain web site. The one that hit our support lines the most was 24.0.0.200 which was members.home.com. It can be a challenge explaining the simplest of issues to end users, let alone upstream transit providers using bgp to blackhole a host. The customer just wants to get to the granny's knitting guild! At least with SMTP blocking, one end gets a message stating "their mail is unwelcome, see .... for details", where as when an intermediary is dropping all data, the end user just gets a vague error. My questions is, if you were buying transit from an upstream, and that upstream decided to partake in some sort of content filtering, how would you feel ? Do you think its right for transit providers to do so ? Its one thing if I choose to use this facility, but I feel a little helpless if two ASs away from me uses it... i.e. upstream says, "this way to 24.0.0.0/12", but then drops data going to 24.0.0.200/32. I dont want to have to fill me router with a bunch of /32s so I can exit out UUnet to get around this. Yes, sure I want a proactive upstream to stop network abuse... particularly abuse issues, where I need their cooperation such as smurf attacks and such. But on issues, where I have all the necessary tools and choice to deal with said issue (in this case SPAM), I would prefer it be left up to me on how I deal with foreign SPAM sites. ---Mike ********************************************************************** Mike Tancsa, Network Admin * mike(a)sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada *

2 1

Listserver Address
by Twan 10 Nov '99

10 Nov '99

Greetings, I hate posting this here, but I'm changing Email addresses and need to know the address to the list server so I can contact it and let it know my new address. Any help is appreciated. Thanks. (Email direct to me, btw) - Chris

1 0

ARIN's New E-commerce System
by Member Services 09 Nov '99

09 Nov '99

ARIN is now offering its customers the option of submitting payment for the registration of Autonomous System Numbers (ASNs) by credit card. If your organization submits a request to ARIN and is approved to receive an ASN, you can select to either: 1) receive an invoice and pay by check, or 2) make your remittance on-line by providing your credit account number. The on-line ASN Billing Account Form located on our web site has been revised to accommodate E-commerce transactions using secure protocols. Plus, a new ASN Maintenance Fee Payment Form has been developed for paying ASN annual maintenance fees specifically by credit card. Customers may choose to pay this fee for 1 or 2 years. We trust that this new service will simplify your invoicing and payment process. If you have any questions regarding any fees, please review ARIN's Fee Schedule. ARIN's ASN Billing Account Form can be found at: http://www.arin.net/asnform.htm ARIN's new ASN Maintenance Fee Payment Form can be found at: http://www.arin.net/maintpayform.htm If you have any further questions, comments, or concerns, please do not hesitate to contact member-services(a)arin.net Regards, David R Huberman, Membership Services Coordinator American Registry for Internet Numbers

3 2

Re: Possible DoS attack (?)
by Martin Cooper 09 Nov '99

09 Nov '99

Ron Buchalski <rbuchals(a)hotmail.com> wrote: > Clifton, I wrote that stuff. Clifton wrote the question about 'no ip directed-broadcast' - I think maybe he's not on nanog-post, which is why the original hasn't appeared (yet?). > Have you verified that operation on the router? I used 'debug ip icmp' both with and without 'ip route-cache same-interface', and saw significantly fewer redirects when it was on. > I believe that if the > stupid or malicious host continued to send packets to the router when they > are really destined for another host (or router) on the subnet, that the > router would continue to send ICMP redirects back to the sending host, and > wouldn't cache this response for future packets, even with 'ip route-cache > same-interface' enabled. The router should only populate it's forwarding > table with next hop information for real data flows, and an ICMP redirect > (which is telling the host that this (through the router) isn't the correct > path for a specific data flow) shouldn't be cached. I haven't verified > this, though... But there is a real data flow (in that the router will actually switch the data packets back out of the same interface, as well as sending redirects). The IOS docs for 11.1 through 12.0 have this to say on the subject... -- quote -- ip redirects To enable the sending of redirect messages if the Cisco IOS software is forced to resend a packet through the same interface on which it was received, use the ip redirects interface configuration command. To disable the sending of redirect messages, use the no form of this command. ip route-cache To control the use of a high-speed switching cache for IP routing as well as the use of autonomous switching, use the ip route-cache interface configuration command. To disable fast switching and autonomous switching, use the no form of this command. ip route-cache [cbus] no ip route-cache [cbus] ip route-cache same-interface no ip route-cache same-interface ip route-cache sse no ip route-cache sse ip route-cache [optimum | flow] no ip route-cache [optimum | flow] ip route-cache distributed no ip route-cache distributed Syntax Description [...] same-interface Enables fast switching packets back out the interface on which they arrived. [...] You can enable IP fast switching when the input and output interfaces are the same interface, using the ip route-cache same-interface command. This normally is not recommended, though it is useful when you have partially meshed media, such as Frame Relay. You could use this feature on other interfaces, although it is not recommended because it would interfere with redirection. -- unquote -- Although there is an 'ip route-cache cef' command in 12.0, it doesn't appear to have any options, so maybe redirects just work under CEF (good news for people who use it on their border routers maybe). M.

1 0

Re: Possible DoS attack (?)
by Ron Buchalski 09 Nov '99

09 Nov '99

Clifton, Have you verified that operation on the router? I believe that if the stupid or malicious host continued to send packets to the router when they are really destined for another host (or router) on the subnet, that the router would continue to send ICMP redirects back to the sending host, and wouldn't cache this response for future packets, even with 'ip route-cache same-interface' enabled. The router should only populate it's forwarding table with next hop information for real data flows, and an ICMP redirect (which is telling the host that this (through the router) isn't the correct path for a specific data flow) shouldn't be cached. I haven't verified this, though... -rb ----Original Message Follows---- From: Martin Cooper <mjc(a)cooper.org.uk> To: "Clifton D. McKinney" <clift(a)alltel.net> CC: nanog(a)merit.edu Subject: Re: Possible DoS attack (?) Date: Tue, 09 Nov 1999 15:03:52 +0000 "Clifton D. McKinney" <clift(a)alltel.net> wrote: > Is this something that the "no ip directed-broadcast" command > would prevent? Nope (unfortunately)... I think I should clarify what the problem is again, since I've had a few private emails that suggest that what I originally wrote was confusing. The route-cache (fast-switching) speeds up switching by building a simple lookup table of IP-prefix/output-interface pairs by doing a routing table lookup (process-switching) for the first packet it sees that is addressed to any destination prefix. The problem is that to implement ICMP redirects, Ciscos have to do process-switching to figure out that the source and destination addresses are both out of the same interface and can therefore talk to each other directly (i.e. without pointlessly bouncing traffic off the router and causing the same traffic to go over the same network twice, wasting bandwidth). This would be fine and dandy if when they sent a redirect, the host that received it listened to it, and stopped bouncing traffic off the router, but if it doesn't (either stupidly or maliciously) then all traffic that is being bounced off the router has to carry on being process-switching, burning CPU cycles like it's going out of fashion. If you turn on 'ip route-cache same-interface' the router will still send a redirect for the first packet addressed to a particular prefix that it sees because it has to process-switch it to figure out what to put in the route- cache, but after that it will use the cache, and not look at the source addresses of packets to that destination at all (try turning on 'debug ip icmp' to see this behaviour). Whether you use the command or not is a trade-off based on whether you want redirects to work properly (stopping traffic being bounced off the router unnecessarily if other hosts listen to them), or if you would rather not burn CPU when other hosts don't listen to them and you have to switch the traffic back out of the same interface anyway. M. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: Possible DoS attack (?)
by Martin Cooper 09 Nov '99

09 Nov '99

"Clifton D. McKinney" <clift(a)alltel.net> wrote: > Is this something that the "no ip directed-broadcast" command > would prevent? Nope (unfortunately)... I think I should clarify what the problem is again, since I've had a few private emails that suggest that what I originally wrote was confusing. The route-cache (fast-switching) speeds up switching by building a simple lookup table of IP-prefix/output-interface pairs by doing a routing table lookup (process-switching) for the first packet it sees that is addressed to any destination prefix. The problem is that to implement ICMP redirects, Ciscos have to do process-switching to figure out that the source and destination addresses are both out of the same interface and can therefore talk to each other directly (i.e. without pointlessly bouncing traffic off the router and causing the same traffic to go over the same network twice, wasting bandwidth). This would be fine and dandy if when they sent a redirect, the host that received it listened to it, and stopped bouncing traffic off the router, but if it doesn't (either stupidly or maliciously) then all traffic that is being bounced off the router has to carry on being process-switching, burning CPU cycles like it's going out of fashion. If you turn on 'ip route-cache same-interface' the router will still send a redirect for the first packet addressed to a particular prefix that it sees because it has to process-switch it to figure out what to put in the route- cache, but after that it will use the cache, and not look at the source addresses of packets to that destination at all (try turning on 'debug ip icmp' to see this behaviour). Whether you use the command or not is a trade-off based on whether you want redirects to work properly (stopping traffic being bounced off the router unnecessarily if other hosts listen to them), or if you would rather not burn CPU when other hosts don't listen to them and you have to switch the traffic back out of the same interface anyway. M.

2 1

This time
by Ben 09 Nov '99

09 Nov '99

FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: You host your site with us and you get free E -Commerce, including a merchant account, real-time software and shopping cart. While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for E-commerce when you sign up for our e-commerce hosting plan. If you wish to stay with your current hosting company you still can get the same deal. Check it out first and make an informed decision. But hurry up: THIS LIMITED OFFER MAY BE WITHDRAWN WITHOUT NOTICE. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS, DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Password generator for membership sites * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 50 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. THIS OFFER IS FOR U.S. BASED COMPANIES ONLY! PLEASE DO NOT REQUEST MORE INFORMATION IF YOU ARE LOCATED OUTSIDE OF THE UNITED STATES. Request our free information package without obligations. by replying to: mailto:mvtom@bigfoot.com?subject=INFO_PLEASE ***************************************************** Remove at mailto:knowmore79@netscape.net?subject=remove *****************************************************

1 0

Possible DoS attack (?)
by Martin Cooper 09 Nov '99

09 Nov '99

Hi, I'm sure you guys (girls?) are all aware of the default option for this, but we have just decided to implement 'ip route-cache same-interface' on our client interfaces since the default option on the Cisco IOS version 11.1 (x) which we use at present is 'off'. The reason this may be a problem is that the default option implies process switching for packets directed at the target address where that destination is reached via the same interface. The trade-off is that ICMP redirects work all the time when the option is disabled, but only for the first packet per destination when it is not. Our particular problem is that we have overlaid IP subnets where many of the hosts on these subnets ignore ICMP redirects. The potential DoS attack I am thinking of involves peer or transit networks forwarding packets with forged source addresses to their next-hop, such that the packets are immediately bounced back to their forged sources via their source router across the exchange, having been process switched. This problem could be avoided by fast switching the packets that are to be bounced back. This may not be a problem for routers using CEF, presuming that such routers do not use their CPUs to switch packets back towards their return-paths where this is via the same interface, but I am uncertain if this is the case. Of course, if everyone did proper source address access-lists on ingress ports, this would not be a problem (but I suspect that everyone does not). Regards, M.

1 0

NAX address
by Tatsuya Kawasaki 08 Nov '99

08 Nov '99

Hello Is there any web site that convert MAC address to manufacturers names? thnx Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki Allegiance Telecom Unlock the Power of the Internet http://www.kivex.com Phone 301.215.6777 Fax 301.215.5991 Affiliation given for identification not representation /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

12 11

RE: NAX address
by Mark Persiko 08 Nov '99

08 Nov '99

http://www.dbs.ucdavis.edu/cgi-bin/mac_find - Mark C. Persiko Network Analyst/Systems Programmer - - Email: persiko(a)bvsd.k12.co.us Boulder Valley School District - -----Original Message----- From: Tatsuya Kawasaki [mailto:tatsuya@kivex.com] Sent: Monday, November 08, 1999 3:06 PM To: nanog ml Subject: NAX address Hello Is there any web site that convert MAC address to manufacturers names? thnx Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki Allegiance Telecom Unlock the Power of the Internet http://www.kivex.com Phone 301.215.6777 Fax 301.215.5991 Affiliation given for identification not representation /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0