- NANOG - lists.nanog.org

Re: How to secure the Internet in three easy steps
by Paul Vixie 27 Oct '02

27 Oct '02

> Source address validation, or more generally anti-spoofing filters, do > not require providers maintain logs, perform content inspection or > install firewalls. But source address validation won't stop attacks, > viruses, child porn, terrorists, gambling, music sharing or any other > evil that exists in the world. So the proposal "1" gets extended to > include other stuff. It gives better ROI when more than SAV is included. i can see how this could happen. however, i do not think that it is the reason why SAV is not gettign deployed.

1 0

Some sort of outage going on with AOL or their peers?
by Gil Cohen 26 Oct '02

26 Oct '02

I can't reach AOL's mailservers at all from Cogent, and a ping from MAE-East looking glass ( http://nitrous.digex.net/mae/mae-lg.html ) shows that it's not working either It seems to work from the PAIX looking glass though. What a fun day.... Oct 26 14:33:33 lostgeeks postfix/smtp[54035]: connect to mailin-04.mx.aol.com[64.12.136.153]: Operation timed out (port 25) Oct 26 14:34:48 lostgeeks postfix/smtp[54035]: connect to mailin-01.mx.aol.com[64.12.137.89]: Operation timed out (port 25) Oct 26 14:35:31 lostgeeks postfix/smtp[54193]: connect to mailin-03.mx.aol.com[64.12.136.249]: Operation timed out (port 25) Oct 26 14:36:03 lostgeeks postfix/smtp[54035]: connect to mailin-01.mx.aol.com[152.163.224.26]: Operation timed out (port 25) Oct 26 14:36:46 lostgeeks postfix/smtp[54193]: connect to mailin-04.mx.aol.com[64.12.137.121]: Operation timed out (port 25) --from cogent-- traceroute 64.12.137.121 traceroute to 64.12.137.121 (64.12.137.121), 64 hops max, 44 byte packets 1 yoda.saturnbandwidth.net (66.250.215.1) 61.467 ms 0.251 ms 0.164 ms 2 f29.ba01.b002802-1.mia01.atlas.cogentco.com (38.112.0.1) 0.680 ms 0.660 ms 0.675 ms 3 g0-2.core01.mia01.atlas.cogentco.com (66.28.6.41) 0.642 ms 0.468 ms 0.415 ms 4 p5-0.core01.jax01.atlas.cogentco.com (66.28.4.65) 8.241 ms 8.361 ms 8.578 ms 5 p5-0.core01.atl01.atlas.cogentco.com (66.28.4.138) 14.867 ms 31.769 ms 14.649 ms 6 g3-0.pr1.atl01.netrail.net (66.28.28.202) 14.365 ms 14.383 ms 14.427 ms 7 66.185.150.1 (66.185.150.1) 14.602 ms 14.283 ms 14.404 ms 8 bb2-atm-P0-0.atdn.net (66.185.147.197) 14.819 ms 14.696 ms 14.599 ms 9 bb2-cha-P6-0.atdn.net (66.185.152.31) 19.706 ms 19.489 ms 19.615 ms 10 * * * ---- Thanks, Gil -- Gil Cohen <gcohen(a)saturnbandwidth.net> | SENIOR NETWORK ENGINEER | SATURN BANDWIDTH & FIBER, INC. | (o) 954-438-7000x124 (c) 954-347-0615 |

1 1

Re: Sugestions for a colocation equipment check-list
by JC Dill 26 Oct '02

26 Oct '02

On 07:11 PM 10/23/02, Mike (meuon) Harrison wrote: > >On Wed, 23 Oct 2002, Dan Lockwood wrote: > >> Does anyone have a list of criteria that is collected when a customer >> brings equipment into a colocation facility? Things may include make >> and model, number of power supplies, serial number, etc. Any comments >> on this type of operation are greatly appreciated. > >On the paranoid side: On the practical side: A single line on a form, with fields for: Make and model of item Description of item or its use Serial number Inventory/ID tag (maybe) Example: Cisco 2501 Router SN# 123123123123 ID# 1234 At the top or bottom of the form are fields for the date, the company that owns the equipment (name, address, phone numbers etc.), the name and signature of person bringing it in (or removing it) and a place and for the Colo security person's signature who verifies the data against the equipment (sometimes). This has been the standard procedure for all colos that I've installed equipment in to or taken equipment out of, including: Above.net (several locations) PAIX (several locations) Exodus (several locations) Equinix (several locations) NTT in Tokyo I've never been asked to open a case. I've never been asked to list internal parts (power supplies, ram, hard drives, etc.) or external pieces (cables etc.). I *have* had them paw thru my laptop bag looking for "suspicious items". I have always had a wireless card with me (with my laptop) and never had anyone give it a second look. Many colos require that you unbox your equipment before bringing it into the colo, and box it after removing it out of the colo (and of course they don't have provide any facility for you to do this on the outside of the security wall). They *really* need better systems for handling boxing and IDing of equipment. jc

1 0

More federal management of key components of the Internet needed
by Sean Donelan 26 Oct '02

26 Oct '02

Its starting already. I don't mean to diss any of the root server operators, they all do a great job. But in the past it seemed the federal agency sysadmins had the most difficult job getting the budget approval for upgrades, and seemed to always be behind the performance curve. I don't understand how giving the US federal government management control of key components of the Internet will make it more secure. What steps could the US federal government take which non-governmental organizations aren't or couldn't do? Putting a root name server on a military base isn't really going to protect it from DDOS attacks. Should root servers be located in the "middle" of backbones, instead of stub networks? Or do networks naturally "grow" towards root servers? http://www.idg.net/ic_958962_1793_1-1681.html "More federal management of key components of the Internet infrastructure is needed, Julian and Brady agreed. That could include tax incentives or direct federal funding for private companies and public organizations managing key DNS servers to secure their systems, all of which are currently operated as a free service by companies, government entities and non-profit organizations. "This showcases a specific vulnerability that requires the government to get involved," Julian said. "If you run a DNS server what is your monetary incentive to secure it? There is none. This is the number one area of focus that the government should have."

14 14

Re: How to secure the Internet in three easy steps
by Michael Lamoureux 26 Oct '02

26 Oct '02

"batz" == batz <batsy(a)vapour.net> writes: batz> Assuming you are referring to "securing" as the balance of the batz> holy triuvirate of Confidentiality, Integrity and Availability, batz> there are other options than the modest proposals you made. batz> The ISP doesn't have to manage the firewall, but like I said batz> earlier, if they provided a configurable filter in the form of a batz> web interface to altering access-lists applied to the customers batz> connection, this would solve most problems. Just to make sure I understand what you are suggesting, you are saying that the solution to most of the Internet's security problems is for ISPs to set up webservers with applications running on them that allow customers to alter the ACLs on the ISP's routers for the interfaces that have that customer's connections? I must be misreading that somehow. ;-) IMHO, Michael

1 0

Re: How to secure the Internet in three easy steps
by Paul Vixie 25 Oct '02

25 Oct '02

> > > 1. Require all providers install and manage firewalls on all subscriber > > > connections enforcing source address validation. > > > > i can see how the end to end principle applies in cases 2 and 3, but not 1. > > I didn't make any of these up. They've all been proposed by serious, > well-meaning people. i recommend caution with your choice of words. apparently not everyone treats "well meaning" as the compliement that it is. > If you have 2 and 3, why do you need to waste global addresses on 1. i don't believe that 2 or 3 will ever happen, for simple market reasons -- it is harder to make money if you do 2 or 3. however, 1 only costs a small bit of ops expense, and has no market impact at all, so it's practical in simple economic terms. > Its a mis-understanding of what source address validation is. Some folks > think it should work like ANI, where the telephone company writes the > "correct" number on the call at the switch. ouch. i guess you're right. perhaps a copy of BCP38 should come with every router sold?

5 4

Re: DNS issues various
by Randy Bush 25 Oct '02

25 Oct '02

> Future attacks will be stronger and more organized. So how do we protect > the root servers from future attack? protecting the servers is not the *critical* point. protecting the service is. don't obsessed up on silly boxes. of course, box/link protection is *one* aspect of protecting the service. randy

18 25

RE: Ameritech/SBC DSL?
by Ethan Blodgett 25 Oct '02

25 Oct '02

NOC(a)SWBell.net is your best bet. -----Original Message----- From: Spencer.Wood(a)dot.state.oh.us [mailto:Spencer.Wood@dot.state.oh.us] Sent: Friday, October 25, 2002 7:24 AM To: nanog(a)merit.edu Subject: OT: Ameritech/SBC DSL? I was wondering, does anyone have a good contact at Ameritech/SBC on the DSL side of the house???? We lost quite a few of our DSL VPN sites earlier this week, and it appears that Ameritech changed there PPPoE authentication method??? Spencer ************************************************************ Spencer Wood, Network Manager Ohio Department Of Transportation 1320 Arthur E. Adams Drive Columbus, Ohio 43221 E-Mail: Spencer.Wood(a)dot.state.oh.us <mailto:Spencer.Wood@dot.state.oh.us> Phone: 614.644.5422/Fax: 614.887.4021/Pager: 866.591.9954 *************************************************************

1 0

anycast dns servers
by Randy Bush 25 Oct '02

25 Oct '02

i am a bit confused here. seems to be that the major differences between smb's scheme, for which you personally attacked me, and yours are o yours has centralized control, you, instead of isp control. this is known not to have good layer nine properties, see marinara del roi. o we get to pay you for that privilige, though at 'cost', mighty kind of you, but we're silly enough to also think we know how to run services. though it might be fun to talk about how to automate testing for the relevant parts of rfc 2870. i.e. they are not technically much different. as smb said, the hard problems are at layer nine. but, first focusing on the technology, let's talk about the hard part of the problem first, the gtld servers, hard because of the size of the data and the frequency of change. so a large isp lets the registries (verisign et alia) put a honkin' hidden primary server near _big_ backbone links. other large (i.e. can handle moving that kind of data) isps set up ipsec or tsig secondary cluster off of it. of course, the isps' secondary clusters use a well-known anycast address for serving queries. the isps which have secondaries might not accept announcements of the anycast prefix from eachother, or they might, point to disucss. i could elaborate further, but it might be more fun to let others have a say too. especially how this can safely support all the non-oc48++ isps. randy

1 0

Re: DNS issues various
by Michael.Dillon＠radianz.com 25 Oct '02

25 Oct '02

> you might remember or look up smb's presentation on 'pushback' at > some nanog or another (those anonymous hotel rooms kinda blur, > especially before first coffee). that's not perfect, but it > scales. and it's an engineering approach to a technology problem, > always a good sign. I find citeseer to be a useful tool for finding this sort of technical information. Go to http://citeseer.nj.nec.com/cs and type in "pushback" then click the search button. Voila! You do have to be careful about what you do with the information you find there. Since these are mostly papers produced by academics the quality can be variable, i.e. a masters course project versus a paper produced by someone who is a leader in their field. If people like what they see in the papers discussing "pushback" then why not push this issue back into the lap of Cisco and Juniper?

1 0