Re: Anyone notice strange announcements for 174.128.31.0/24
On 14 Jan 2009, at 16:06, Jeroen Massar wrote: Simon Lockhart wrote: (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) Nah, I agree with Randy's experiment too. People should protect their networks better and this is clearly showing that there are a lot of vulnerable places in the core internet structure. The end sometimes justifies the means, and someone in the research community discovering flaws in bgp implementation (software, protocol, or process - at the bgp stack, in my NOC tools, in the community's understanding) before hackers/spammers/fraudsters do, then I count that as a result. Andy
RE: Approach to allocating netblocks
--On onsdag, onsdag 14 jan 2009 10.30.18 -0600 Frank Bulk frnk...@iname.com wrote: But perhaps the BCP is to make the customer renumber, in which case I'm making things more complicated than they need to be. Most customers with PA space (which is what you are giving them) are quite used to renumbering. If not, they will become, given v6 PAishness. Renumbering is not to be avoided at all costs, because: Renumbering cleans cruft and finds mishaps waiting to happen. Renumbering rewards those who have done proper configuration separation. Renumbering rewards those who have automated their systems management. Renumbering thus is good for you. There are economic incentives (keeping the customer because said customer hovers in the Lagrange point between clueless and lazy) to let suboptimal numbering schemes fester. Might alter picture above, but from operational standpoint renumbering is not that bad. -- Måns NilssonM A C H I N A Now my EMOTIONAL RESOURCES are heavily committed to 23% of the SMELTING and REFINING industry of the state of NEVADA!! pgpN3VisGKINP.pgp Description: PGP signature
Re: Anyone notice strange announcements for 174.128.31.0/24
On Jan 14, 2009, at 6:22 PM, kris foster wrote: On Jan 14, 2009, at 2:52 PM, Michienne Dixon wrote: Well, if you really want to pick knits you are welcome to. If I meant prepending, I would have said that. The example that I listed was setting up a router, advertising the ASNs listed and the random IP ranges gleaned from IANA. Sorry if I confused you. The point I believe John is trying to make is that *ASNs are not announced*. There are no advertisements that say this is how to get to ASN X. BGP updates specifically announce network layer reachability. This is an important point in this discussion. There are a lot of comments being made that are just simply wrong and causing confusion because of slips in terminology regarding the path attribute. Thanks Kris - exactly what I was getting to. Kris -Original Message- From: John Payne [mailto:j...@sackheads.org] Sent: Wednesday, January 14, 2009 3:57 PM To: Michienne Dixon Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Jan 14, 2009, at 10:50 AM, Michienne Dixon wrote: Interesting - So as a cyber criminal - I could setup a router, start announcing AS 16733, 18872, and maybe 6966 for good measure and their routers would ignore my announcements and IP ranges that I siphoned from searching IANA? Hm... Would that also prevent them from accessing my rogue network from their network? What do you mean announcing AS 16733... ? Putting 16733 in an AS PATH is not announcing it. - Michienne Dixon Network Administrator liNKCity 312 Armour Rd. North Kansas City, MO 64116 www.linkcity.org (816) 412-7990 -Original Message- From: Simon Lockhart [mailto:si...@slimey.org] Sent: Wednesday, January 14, 2009 2:07 AM To: Hank Nussbacher Cc: NANOG list Subject: Re: Anyone notice strange announcements for 174.128.31.0/24 On Wed Jan 14, 2009 at 09:59:14AM +0200, Hank Nussbacher wrote: What if, by doing some research experiment, the researcher discovers some unknown and latent bug in IOS or JunOS that causes much of the Internet to go belly up? 1 in a billion chance, but nonetheless, a headsup would have been in order. Say we had a customer who connected to us over BGP, and they used some new experimental BGP daemon. Their announcement was odd in some way, but appeared clean to us (a Cisco house). Once their announcement hit the a Foundry router, it tickled a bug which caused the router to propogate the announcement, but also start to blackhole traffic. Oh dear, large chunks of the Internet have just gone belly up. Should we have given a heads up to the Internet at large that we were turning up this customer? Simon (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) -- Simon Lockhart | * Sun Server Colocation * ADSL * Domain Registration * Director|* Domain Web Hosting * Internet Consultancy * Bogons Ltd | * http://www.bogons.net/ * Email: i...@bogons.net *
Re: Which is more efficient?
On 2009-01-14, at 15:56, Murphy, Jay, DOH wrote: In your humble opinion, which transmission method is more efficient, packet or cell? When you say transmission method are you just interested in packet/ cell forwarding, or are you also including the effort involved in segmentation and reassembly? And when you say efficient are you talking about power consumption, or cost per bit, or payload versus header, or minimising jitter for isochronous applications, or something else? If the question is a pragmatic one (e.g. which will allow me to get the most sleep, and spend the least money) then perhaps at low speeds, with Nortel's bankruptcy imminent, you could expect to find a lot of cheap ATM gear on the used market that would be the right short- term answer. It'd have to be pretty cheap though. I have met clueful people who have come to this conclusion, astonishing though it seemed to me at the time. At higher speeds, you might find that ATM gear either doesn't exist, or is so ludicrously expensive compared to ethernet switches that it makes you laugh coffee all over your keyboard. Joe
Re: Anyone notice strange announcements for 174.128.31.0/24
On Jan 15, 2009, at 3:54 AM, Andy Davidson wrote: On 14 Jan 2009, at 16:06, Jeroen Massar wrote: Simon Lockhart wrote: (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) Nah, I agree with Randy's experiment too. People should protect their networks better and this is clearly showing that there are a lot of vulnerable places in the core internet structure. The end sometimes justifies the means, and someone in the research community discovering flaws in bgp implementation (software, protocol, or process - at the bgp stack, in my NOC tools, in the community's understanding) before hackers/spammers/fraudsters do, then I count that as a result. We disagree. The 'researcher' does not get to decide whether the information gained by yelling fire to see how quickly people react is worth the risk of someone getting hurt, or even just missing the rest of the movie. No reputable research institution's ethics committee would allow an experiment to proceed which announced a prefix in such a way that every network engineer on the planet would assume the prefix traveled through $ASN even though the prefix had not, and the researcher did not even notify $ASN of the experiment. -- TTFN, patrick
Re: Anyone notice strange announcements for 174.128.31.0/24
Here's a question that's been bugging me the whole thread, and it's a bit of a newbie one. How is this different than someone faking SMTP headers to make it seem like an email came from my domain when it didn't? I'm talking in terms of morals, obviously; I understand the technique is different. On Thu, Jan 15, 2009 at 9:44 AM, Patrick W. Gilmore patr...@ianai.net wrote: On Jan 15, 2009, at 3:54 AM, Andy Davidson wrote: On 14 Jan 2009, at 16:06, Jeroen Massar wrote: Simon Lockhart wrote: (Yes, I'm in the minority that thinks that Randy hasn't done anything bad) Nah, I agree with Randy's experiment too. People should protect their networks better and this is clearly showing that there are a lot of vulnerable places in the core internet structure. The end sometimes justifies the means, and someone in the research community discovering flaws in bgp implementation (software, protocol, or process - at the bgp stack, in my NOC tools, in the community's understanding) before hackers/spammers/fraudsters do, then I count that as a result. We disagree. The 'researcher' does not get to decide whether the information gained by yelling fire to see how quickly people react is worth the risk of someone getting hurt, or even just missing the rest of the movie. No reputable research institution's ethics committee would allow an experiment to proceed which announced a prefix in such a way that every network engineer on the planet would assume the prefix traveled through $ASN even though the prefix had not, and the researcher did not even notify $ASN of the experiment. -- TTFN, patrick
Radius Tacacs+ Clients
Hi all. Does anyone have any recommendations for Radius and Tacacs+ clients (not servers) to run on Linux and Windows? Thanks, John John Souvestre - Integrated Data Systems - (504) 355-0609
Re: Radius Tacacs+ Clients
take a look at this for your Linux requirements: http://freeradius.org/pam_radius_auth/ On Thu, Jan 15, 2009 at 10:15 AM, John Souvestre jo...@sstar.com wrote: Hi all. Does anyone have any recommendations for Radius and Tacacs+ clients (not servers) to run on Linux and Windows? Thanks, John John Souvestre - Integrated Data Systems - (504) 355-0609 -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy
Re: Radius Tacacs+ Clients
Does anyone have any recommendations for Radius and Tacacs+ clients (not servers) to run on Linux and Windows? Steven Fischer gave you a good pointer to freeradius for tacacs, look at http://shrubbery.net/tac_plus/ randy
Re: Which is more efficient?
On Wed, 14 Jan 2009 13:56:11 MST, Murphy, Jay, DOH said: In your humble opinion, which transmission method is more efficient, packet or cell? In my humble opinion, if you care about actual in-the-field efficiency as opposed to theoretical or in-the-lab results, I think you'll find that there is enough statistical spread between best and worst actual hardware for both packet and cell to swamp the theoretical benefits - there are good packet processors out there that will kick the butt of most cell gear, and there's good cell gear that will outperform some packet gear. And then there's cost issues - if cell is 5% more efficient, but 35% more expensive, is it really a good choice? (Unless of course you *need* that 5% to fit through a non-negotiable bandwidth notch someplace - but then you'll be screwed *anyhow* if your traffic grows 7%). pgpKTWZXAsh8h.pgp Description: PGP signature
Re: Approach to allocating netblocks
--On torsdag, torsdag 15 jan 2009 15.11.48 -0500 William Herrin herrin-na...@dirtside.com wrote: On Thu, Jan 15, 2009 at 5:16 AM, Måns Nilsson mansa...@besserwisser.org wrote: from operational standpoint renumbering is not that bad. Måns, http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.t xt provides 24 pages and growing worth of problems with renumbering. Here's a simple one: Web browsers intentionally violate the DNS TTL with a technique called DNS Pinning. snip Given the small netmasks, I'd guess that most of the browser population behind them is addicted to a proxy. The proxy might not subscribe to pinning. Also, the browsers that run for months typically aren't on end-user PCs, but on the workstations of the clued, if I might be so blunt. It is not that renumbering is painless, not at all. But it is very useful as spring cleaning. I'd rather know what happens by testing it than finding out by being woken up while on call. -- Måns NilssonM A C H I N A Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS ... pgpisEgDIjRvC.pgp Description: PGP signature
Re: Radius Tacacs+ Clients
Hello John - Radiator includes both RADIUS and TACACS+ clients (written in Perl). www.open.com.au/radiator regards Hugh On 16 Jan 2009, at 02:15, John Souvestre wrote: Hi all. Does anyone have any recommendations for Radius and Tacacs+ clients (not servers) to run on Linux and Windows? Thanks, John John Souvestre - Integrated Data Systems - (504) 355-0609
Re: Which is more efficient?
On Wed, Jan 14, 2009 at 12:56 PM, Murphy, Jay, DOH jay.mur...@state.nm.us wrote: In your humble opinion, which transmission method is more efficient, packet or cell? ... Trying to make a decision on the transport mode for cost, delay, jitter, ROI, etcetera. It really depends on what your applications are. I've spent the last decade as the regional ATM specialist (among other things) for an international carrier, and since we can sell you koolaid in ATM, Frame, MPLS, VPLS, IPv4, and IPSEC flavors, I can be fairly neutral about technology recommendations for my customers. The most efficient transmission method is the one for which you know how to set up your router to match the way the carrier's network works, so you'll need to train your people. If that's ATM, you may need to do some ATM-specific things, and they're different for different carriers; if it's Ethernet, you'll need to decide how to handle access line failure detection. And the work you need to do is much different if the ATM/Frame/Ethernet is a Layer 2 end-to-end service or if it's an access line for a routed service such as MPLS. ATM can give you really good control over jitter, but only if you set it up correctly. Dedicated Ethernet access typically has lower jitter than shared switched Ethernet access, but it only comes in a couple of sizes and may cost more if that's bigger than what you need. As far as cost-effectiveness goes, ATM cells have about 10% overhead, but some carriers price their services to charge you for it and some don't, and they have different policies about bursting; what you really care about is what price they're going to charge you for the data circuits you need. Ethernet also has a lot of overhead, if you're carrying lots of small packets; it's very significant if you're carrying VOIP, and trivial on big file transfers. These days circuit costs have decreased enough that router costs can be a significant part of your total cost. ATM cards are traditionally expensive, but if you're buying a VLAN-based switched ethernet access service, ask your router vendor what size router you'll need to handle traffic shaping - even if the Ethernet is built-in, a large teal-colored box costs more than a medium box. My main concerns about ATM, other than whether it matches your applications, are whether it'll scale to the size you need, and how long you'll be able to get good router vendor support. I don't see Frame/ATM interworking going away as a method for handling lots of small endpoints like cash machines reliably, at least until there are good ways to manage thousands of IPSEC sessions, but it's not the technology you're going to want for OC48s. DSL is usually ATM underneath, but that may or may not be how you connect to your DSL carrier. -- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
What ISP's looking for in a BGP Security Solution?
Respected AllI would like to discuss some of the questions related to BGP Security which might be quite helpful in my research.1.What are you using now for BGP Security problems like Prefix hijacking,Path Spoofing,etc?2.What you would be looking for in any BGP Security Solution?3.Are solutions like BGPMon,PHAS,PGBGP are implemented anywhere?4.Are there some new issues related to BGP Security than widely discussed in research/conference/forums?5.Any other points you want to share.Thank You.Akmal Khan
multicast meltdown?
We've detected a large drop in the IPv4 multicast prefix count over the past few days. Anybody know what's going on? Antonio Querubin whois: AQ7-ARIN
smtp.comcast.net self-signed certs
I've been seeing some odd behavior today with some of the servers that respond to smtp.comcast.net on port 587. Some, but not all, of the servers are presenting self-signed certs, causing my own server to balk at making a connection. (The Organization is RTFM, Inc. -- it'd be funny if mail wasn't queueing up on my end). Sometimes I get a server with a legit cert, so I can slowly drain my queue by flushing it over and over and over... openssl s_client output below. I can send a libpcap trace on request. --Jeff ┌─(r...@bookcase)(04:48:06) └─(~)- openssl s_client -CApath /etc/ssl/certs/ -starttls smtp -connect smtp.comcast.net:587 CONNECTED(0003) depth=1 /C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=localhost i:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 1 s:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 i:/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 --- Server certificate -BEGIN CERTIFICATE- MIICGDCCAYECAgEBMA0GCSqGSIb3DQEBBAUAMFcxCzAJBgNVBAYTAlVTMRMwEQYD VQQKEwpSVEZNLCBJbmMuMRkwFwYDVQQLExBXaWRnZXRzIERpdmlzaW9uMRgwFgYD VQQDEw9UZXN0IENBMjAwMTA1MTcwHhcNMDEwNTE3MTYxMDU5WhcNMDQwMzA2MTYx MDU5WjBRMQswCQYDVQQGEwJVUzETMBEGA1UEChMKUlRGTSwgSW5jLjEZMBcGA1UE CxMQV2lkZ2V0cyBEaXZpc2lvbjESMBAGA1UEAxMJbG9jYWxob3N0MIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQCiWhMjNOPlPLNW4DJFBiL2fFEIkHuRor0pKw25 J0ZYHW93lHQ4yxA6afQr99ayRjMY0D26pH41f0qjDgO4OXskBsaYOFzapSZtQMbT 97OCZ7aHtK8z0ZGNW/cslu+1oOLomgRxJomIFgW1RyUUkQP1n0hemtUdCLOLlO7Q CPqZLQIDAQABMA0GCSqGSIb3DQEBBAUAA4GBAIumUwl1OoWuyN2xfoBHYAs+lRLY KmFLoI5+iMcGxWIsksmA+b0FLRAN43wmhPnums8eXgYbDCrKLv2xWcvKDP3mps7m AMivwtu/eFpYz6J8Mo1fsV4Ys08A/uPXkT23jyKo2hMu8mywkqXCXYF2e+7pEeBr dsbmkWK5NgoMl8eM -END CERTIFICATE- subject=/C=US/O=RTFM, Inc./OU=Widgets Division/CN=localhost issuer=/C=US/O=RTFM, Inc./OU=Widgets Division/CN=Test CA20010517 --- No client certificate CA names sent --- SSL handshake has read 1965 bytes and written 375 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 8B976D67A76BBFEF5E46CA9D079C1C1208D037B8F5825049C45B57C05786A891 Session-ID-ctx: Master-Key: 4DC43D803056BF32082F3E35B2818539E33B7321455AD625D3AD124BAD719C12C5903C9F1889EAB7A5F313B9A54D74A6 Key-Arg : None Start Time: 1232081287 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- 250 OK
