RE: Check Point Firewall Appliances
Watch out for licensing gotchyas. In active/active ClusterXL situations (load sharing multicast mode) be careful of multicast--make sure any traversed switches and routers are compatible with Ethernet Multicast (make sure they don't partition ports due to high broadcast traffic). Active/Active clustering can also make troubleshooting a pain--which unit has state for which flow, etc.. Also, minimize lag time between State Synchronization nodes or suffer myriad hard to isolate problems. I advise you to minimize the number of cluster nodes per vlan or you will effectively DOS your attached network--think broadcast storms. If you use unicast active/active clusterxl, you can run into pivot problems. They are great firewalls, but like all systems they have their opportunities. --Patrick Darden -Original Message- From: Blake Pfankuch [mailto:bl...@pfankuch.me] Sent: Wednesday, December 19, 2012 2:36 PM To: NANOG (nanog@nanog.org) Subject: Check Point Firewall Appliances Howdy, I am just getting into an environment with a large Check Point deployment and I am looking for a little bit of feedback from other real world admins. Looking for what people like, what people don't (why hopefully). Also for those of you who might run Check Point devices in your environments what to dig into first as far as getting more experience on the devices and a better understanding of how not to break them. I am slowly going through all of the official documentation, but would also like to hear a real world opinion. Thanks in advance! Blake
RE: Penetration Test Assistance
Seriously. --p -Original Message- From: Aled Morris [mailto:al...@qix.co.uk] I'd treat this as the first of their pen tests - a social engineering attack to obtain secret information about the network, and refuse. Aled
RE: Penetration Test Assistance
I'm with Barry--a network diagram showing everything from the pov of the pen team should be part of the end report. --p -Original Message- From: Barry Greene [mailto:bgre...@senki.org] Hi Tim, A _good_ pen test team would not need a network diagram. Their first round of penetration test would have them build their own network diagram from their analysis of your network. Barry
RE: Protocols for Testing Intrusion Detection?
nmap has some modes that are useful for this: nmap -sX network#christmas treepackets are sent, nastygram, kamikaze, should light up any IPS nmap -sS network#stealth syn scan, should light up any good IPS nmap -O network #OS scan, should light up any sensitive IPS nmap -o network #udp scan, should light up any very sensitive IPS nmap network#ping + easy check for open ports from 1--1023, should only light up an overly sensitive IPS Lots more modes, and lots more scales of sensitivity. All of these are subjective. DMZs, VMZs, inner networks, and private networks would all have different scales of sensitivity. E.g. in my private network if I detected an nmap network then I would investigate. In my DMZ I probably wouldn't take notice of such a general scan. Does that help? --p -Original Message- From: Bill Stewart [mailto:nonobvi...@gmail.com] Sent: Monday, May 14, 2012 7:53 PM To: NANOG list Subject: Protocols for Testing Intrusion Detection? I'm looking for recommended protocols to use for testing intrusion detection and maybe also firewall logging. Basically I need some kind of protocol that it's ok to discard traffic for in a production network, so I can be sure that the various systems that should be detecting it and generating alarms are up and running. Is there already a standard I should be using? (This doesn't seem to quite match RFC2544.) I'm thinking about things like - TCP and UDP echo protocol - is this sufficiently deprecated that it won't be missed, or are there applications still using it? - Higher-numbered TCP protocol, such as 31337, which appears to have no official current use, and unofficially is for Back Orifice. - http:80 from a well-known test address, such as evil.example.com (probably need both RFC1918 and public IP addresses, so it's somewhat site-dependent. Should I be using 192.0.2.0/24 or 198.18.0.0/15 as long as I'm careful not to leak them out to the real internet?) - Is there any application that can actually set the RFC3514 Evil Bit? -- 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.
RE: whoi modify question
The short answer is you can't. ARIN only cares about /24s or bigger. If the network were a /24 or larger, then your customer would need to get an ASN (autonomous system number) and then you could register the network to them. More info here: https://www.arin.net --Patrick Darden -Original Message- From: Deric Kwok [mailto:deric.kwok2...@gmail.com] Sent: Friday, June 17, 2011 12:34 PM To: nanog list Subject: whoi modify question Hi My boss wants me to resign part of ip /25 to customer For the whois record to this customer, how can I do it? Thank you
RE: VPN over slow Internet connections
There's not that much overhead--your certs should be ok. TCP for SQL would just make sense. I personally wouldn't want to do what you are contemplating. Here's some stuff to think about: 1. your modems will not be able to do compression. You can't easily compress random data (e.g. encrypted). 2. you won't get 33.6 unless your phone lines are pristine. You better plan on 28.8--if you are lucky. 3. I would hone my SQL sharply so it produces the smallest most relevant data sets possible. 4. you might want to give them some kind of termnial/shell access for doing their SQL remotely, instead of from home. Telnet or SSH. If you used SSH you could obviate using a separate VPN, you could use -C for compression, and you could do your SQL on the server side (or the on-site side)--all in all a speedier alternative. --Patrick Darden -Original Message- From: Ben Whorwood [mailto:bw...@mube.co.uk] Sent: Thursday, April 21, 2011 12:56 PM To: nanog@nanog.org Subject: VPN over slow Internet connections Dear all, Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)? We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else. Some initial thoughts include... * How well would the connection handle certificate (= 2048 bit key) based authentication? * Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)? * Is VPN over this type of connection simply a bad idea? Many thanks in advance. Kind regards, Ben Whorwood
Google Op Plz
Could a Google Op get in touch with me off-list please? I have a fairly stupid situation --p
RE: ATT Metro E in Atlanta
It's been up and down since maybe 11am eastern. We have a ticket in with them, but no response as of yet. --Patrick Darden Athens Regional Medical Center -Original Message- From: Raleigh Apple [mailto:rap...@rapidlink.com] Sent: Tuesday, February 09, 2010 3:14 PM To: nanog@nanog.org Subject: ATT Metro E in Atlanta Anybody have any idea whats going on with ATT metro E in Atlanta? r
RE: facebook DNS
I noticed this as well around 11:50 eastern. --Patrick Darden -Original Message- From: Maria Iano [mailto:ma...@iano.org] Sent: Thursday, May 21, 2009 11:56 AM To: nanog@nanog.org Subject: facebook DNS It looks like facebook is having DNS troubles. The www.facebook.com subdomain is delegated to some servers that are no longer answering. Also apps.facebook.com is a cname to www-college.facebook.com which gets no reply. Maria
ATT Having Difficulties--anybody know what they are?
Athens GA, tried to call in a ticket (Metro Ethernet) and was told a master ticket was already in place for my circuits. Other than the ticket # they wouldn't give me any details. Anybody know anything? --p
RE: Dynamic IP log retention = 0?
I think your next step is your lawyer. Put all your missives, your email, your phone conversations, your logs, your auditing results, your detection troubleshooting and sleuthing trails etc. in a folder, create a one page summary including any damages you feel might have been caused (e.g. time, effort, and money spent on this so far) and a timeline, and make an appointment with your lawyer. --Patrick Darden -Original Message- From: Brett Charbeneau [mailto:br...@wrl.org] Sent: Wednesday, March 11, 2009 9:34 AM To: nanog@nanog.org Subject: Dynamic IP log retention = 0? I've been nudging an operator at Covad about a handful of hosts from his DHCP pool that have been attacking - relentlessly port scanning - our assets. I've been informed by this individual that there's no way to determine which customer had that address at the times I list in my logs - even though these logs are sent within 48 hours of the incidents. The operator advised that I block the specific IP's that are attacking us at my perimeter. When I mentioned the fact that blocking individual addresses will only be as effective as the length of lease for that DHCP pool I get the email equivalent of a shrug. Well, maybe you want to ban our entire /15 at your perimeter... I'm reluctant to ban over 65,000 hosts as my staff have colleagues all over the continental US with whom they communicate regularly. I realize these are tough times and that large ISP's may trim abuse team budgets before other things, but to have NO MECHANISM to audit who has what address at any given time kinda blows my mind. Does one have to get to the level of a subpoena before abuse teams pull out the tools they need to make such a determination? Or am I naive enough to think port scans are as important to them as they are to me on the receiving end? -- Brett Charbeneau, GSEC Gold, GCIH Gold Network Administrator Williamsburg Regional Library 7770 Croaker Road Williamsburg, VA 23188-7064 (757)259-4044 www.wrl.org (757)259-4079 (fax)br...@wrl.org
RE: Gigabit Linux Routers
I don't think you will have any troubles with industry standard hardware for the rates you are quoting. When you get in excess of 300Mbps you have to start worrying about PPS. When you are looking at 600Mbps then you should pick out your system more carefully (tcpoe nics, pcie(X), cpu at over Xghz, fast ram if you are doing a lot of BGP, tweaking your linux distribution and kernel, etc.). You should be fine with any recent hardware. A cheap HP dl360 would do a great job. --p -Original Message- From: Chris [mailto:ch...@ghostbusters.co.uk] Sent: Wednesday, December 17, 2008 9:03 AM To: nanog list Subject: Gigabit Linux Routers Hi All, Sorry if this is a repeat topic. I've done a fair bit of trawling but can't find anything concrete to base decisions on. I'm hoping someone can offer some advice on suitable hardware and kernel tweaks for using Linux as a router running bgpd via Quagga. We do this at the moment and our box manages under the 100Mbps level very effectively. Over the next year however we expect to push about 250Mbps outbound traffic with very little inbound (50Mbps simultaneously) and I'm seeing differing suggestions of what to do in order to move up to the 1Gbps level. It seems even a dual core box with expensive NICs and some kernel tweaks will accomplish this but we can't afford to get the hardware purchases wrong. We'd be looking to buy one live and one standby box within the next month or so. They will only run Quagga primarily with 'tc' for shaping. We're in the UK if it makes any difference. Any help massively appreciated, ideally from those doing the same in production environments. Thanks, Chris
RE: EIGRP question...
My first thought for this was: route filtering. My second thought was: use different AS#s. Then I reread your question and thought of something far simpler. It seems to me if you are migrating from provider A to provider B then you should set everything up for B, then shut down the interface to A. If everything works, then you are good, if not then you bring that interface back up in a hurry! Is this more complicated? Are you, for example, moving to B but planning on keeping A as a backup? Or, perhaps your MPLS migration is from non-MPLS to an MPLS based system? So you are keeping A and B? Or perhaps A and B are customers, not really providers? Anyways, not sure of your exact situation, but to answer your question directly: EIGRP uses 5 metrics for weighting paths --delay --bandwidth --reliability --load --MTU It does not use hop count for path weighting. This is a problem, as it would be your easy solution--pretty much auto-solving the condition. 1. You can't really count on delay, and you can't fiddle with it in any easy manner. 2. You could artificially limit bandwidth using your core. I am unsure if this would help you; however, it would answer your stated question. 3. Reliability--calculated dynamically. Not helpful for you. 4. Load--this is the load on the interface I think (0-255). Calculated dynamically. Not helpful for you. 5. MTU--I have no idea how you could use this. Not user configurable in this case, I don't think. I have never used it myself for metrics. It is theoretically used, but never seen it used (in eigrp). Not sure if this helps. --p -Original Message- From: Mike Lyon [mailto:[EMAIL PROTECTED] Sent: Monday, December 01, 2008 2:49 PM To: Nanog Mailing list Subject: EIGRP question... Howdy, So I am working on an MPLS migration from provider A to provider B of which both terminate into my core via customer prem routers. I have a single EIGRP process between my core and the two customer prem routers supplied to me by both providers, of which I don't have access to. My question is, I would like to take the routes that come in from the neighbor A router and apply some kind of metrics to them so they are not preferred over the routes learned by the provider B router. Is this possible or would I need to be running different EIGRP processes between the two customer prem routers and then play around with some redistribution? I am hoping this isn't the case because I don't have access to those CPE routers and redistribution is a nasty thing... Thanks in advance for any enlightnment. Cheers, Mike
RE: How do dialup ISPs allow multiple clients under one access number?
You can do it multiple ways: 1. old fashioned hunt groups for multiple analog lines. 2. getting a PRI with one outward facing number. 3. talk to your local Bell about what would best suit your needs (digital calls? 56K? 64k? 128K? ISDN? Analog? dialout capability, or just dialin? etc. etc.) --Patrick Darden -Original Message- From: John Musbach [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2008 2:15 AM To: nanog@nanog.org Subject: How do dialup ISPs allow multiple clients under one access number? I'm interested in figuring out how dialup ISPs work and have found plenty of info on dialin server setup but not much on how ISPs allow multiple clients under one access number, how do they do it? -- Best Regards, John Musbach
RE: confusing packet data
Or his DSL is set to bridging. --p -Original Message- From: Nathan Ward [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2008 12:47 AM To: nanog list Subject: Re: confusing packet data On 16/09/2008, at 4:43 PM, Hank Nussbacher wrote: Are you running Skype? Have you become a supernode? There is now a registry switch in 3.0 that allows you to disable supernode functionality. This would not cause him to see traffic to and from random addresses. Note that traffic is not going to his IP address, but to AND from addresses that are not his. That, plus the fact that there 'is' traffic on 240/4 and 224/4, and it sounds like a bug. -- Nathan Ward
RE: duplicate packet
Check your ARP tables, local and on intervening switches/routers. Make sure there are no duplicate entries for that IP. If you note the response time, the second packet is always higher which might be indicative. I would also check for a botched MITM a la CA. Even if there is no obvious ARP table manglement, you might try flushing the local and intervening caches. Try the ping from another host, another subnet, another segment, get more info. --p -Original Message- From: chloe K [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 10, 2008 6:46 AM To: nanog@nanog.org Subject: duplicate packet Hi all When I ping the ip, I get the duplicate I check the ip is just one. Why it happens? Thank you 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms 64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms 64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms 64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms 64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!) 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms 64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!) - Yahoo! Canada Toolbar : Search from anywhere on the web and bookmark your favourite sites. Download it now!
RE: interger to I P address
Somebody's going to bring in Emacs now. Then somebody else will claim VI can
do it faster and using less memory
Argh. ;-)
--p
-Original Message-
From: Joe Greco [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 27, 2008 1:29 PM
To: [EMAIL PROTECTED]
Cc: nanog@nanog.org
Subject: Re: interger to I P address
bash# iptoint(){ oct1=`echo $1|awk -F\. '{print $1}'`; oct2=`echo $1|awk -F\.
'{print $2}'`; oct3=`echo $1|awk -F\. '{print $3}'`; oct4=`echo $1|awk -F\.
'{print $4}'`; echo $[($oct124)+($oct216 )+($oct38)+$oct4 ];}
bash# inttoip(){ echo $[$124].$[($116)255].$[($18)255].$[$1255]; }
bash# inttoip 1089055123
64.233.169.147
BASH? Hahaha. Real Admins use sh. More portable(*).
RE: SLAAC(autoconfig) vs DHCPv6
1. I think ARP is effectively a ping for a mac. It verifies connectivity on level 2 between two hosts. You have to be on the same segment though To make it work, you would have to know the mac address of the remote host, clear the arp table the local host, then send the ARP request out. This would still require that each host have IP stacks in place with functioning IP addresses. Although ARP acts under IP, it still requires IP to function. 2. I think you might be able to fudge it using RARP, if you just look for signals sent to that address. 3. A kind of constant ping might be... if you knew the remote's MAC address you could poison the ARP table with an announcement, spoof the MAC locally, then do MITM stuff and relay communications. 4. Ok, after all that craziness I did a google search and found ARPING: http://en.wikipedia.org/wiki/Arping ARPING still seems to rely upon a proper IP stack and address on both hosts. Meh, your best bet might be just to scan your arp tables for the mac you are interested in. I think all NICs broadcast periodically saying I am here. Passive ping. --p -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED] Sent: Monday, August 18, 2008 3:42 PM To: nanog@nanog.org Subject: RE: SLAAC(autoconfig) vs DHCPv6 This was especially a question when L2 was in and routing was out: how do you ping a MAC address?
RE: maybe a dumb idea on how to fix the dns problems i don't know....
Joe makes some good points here. I'd have to add one caveat though: it depends. It depends on the server. Busy email servers definitely depend on having fast DNS, and benefit *greatly* from a caching DNS server using local sockets instead. Web servers generally don't. Centralized logging servers benefit greatly. Usually, for a pocket of servers like Joe describes, you want some local dedicated DNS servers (e.g. ~800 servers, add 2 more just for local DNS) plus you would want caching DNS servers running directly on your email, logging, etc. servers. Yeah, 400-800 extra caching DNS servers would probably be overkill though! I am intrigued by the idea of persistent connections for those 2 dedicated DNS servers--only for upstream though. You wouldn't need so much security locally (for your 800 clients), I expect. You could use UDP for speed, and not worry too much about poisoning. Expecially if you were using some kind of dedicated professional DNS service that required IPSEC pipes, and had engineers only doing DNS: security, updates, patching, uptime, etc. etc. It would be interesting if such professional services came about Companies that do DNS and that is all they do. Dedicated to the reliability and security of one of the cornerstones of the net. We already went through that with Usenet, email, web hosting, and other of the main services. --Patrick Darden -Original Message- From: Joe Greco [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2008 8:10 AM To: Tomas L. Byrnes Cc: [EMAIL PROTECTED] Subject: Re: maybe a dumb idea on how to fix the dns problems i don't know Unix machines set up by anyone with half a brain run a local caching server, and use forwarders. IE, the nameserver process can establish a persistent TCP connection to its trusted forwarders, if we just let it. Organizations often choose not to do this because doing so involves more risk and more things to update when the next vulnerability appears. In many cases, you are suggesting additional complexity and management requirements. A hosting company, for example, might have 20 racks of machines with 40 machines each, which is 800 servers. If half of those are UNIX, then you're talking about 402 nameservers instead of just 2. Since local bandwidth is free, this could be seen as a poor engineering choice, and you still had to maintain those two servers for the other (Windows or whatever) boxes anyways. On the upside, you don't need to use a forwarders arrangement unless you really want to... but the benefit of those 400 extra nameserver instances is a bit sketchy. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
RE: maybe a dumb idea on how to fix the dns problems i don't know....
I think Colin just said everything I said, but in 1/10'th the words. And he posted before me. Drats. --Patrick Darden -Original Message- From: Colin Alston [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2008 8:38 AM To: Joe Greco Cc: [EMAIL PROTECTED] Subject: Re: maybe a dumb idea on how to fix the dns problems i don't know Joe Greco wrote: Unix machines set up by anyone with half a brain run a local caching server, and use forwarders. IE, the nameserver process can establish a persistent TCP connection to its trusted forwarders, if we just let it. Organizations often choose not to do this because doing so involves more risk and more things to update when the next vulnerability appears. In many cases, you are suggesting additional complexity and management requirements. A hosting company, for example, might have 20 racks of machines with 40 machines each, which is 800 servers. If half of those are UNIX, then you're talking about 402 nameservers instead of just 2. [Customers] --/UDP/-- [DNS Cache] --/TCP/-- [DNS servers] Not so? Of course, one shouldn't let the rest of the internet touch your DNS Cache query interface... but that's just obvious. I mentioned this a while ago though, so I demand credit ;P Also, I think there is probably an IETF DNS WG list where this fits on topic (I have no idea what it may be though).
RE: was bogon filters, now Brief Segue on 1918
Hi Jay, Jay Ashworth: Sure. And he's not always right either; none of us are. But he gave cogent arguments to support his point, and you gave us He gave good arguments. You, however, did not. None of which amounts to wants to hurt people, which is what you accused him of. I was out of line here. I apologize to Michael. I don't think he took offense, but if he did I genuinely regret it. And yet I see tha tyou don't yourself bother to try to prove your argument; you merely continue to go after Michael and I on peripheral points. No pun intended. Didn't have to: you didn't address anything other than personal or peripheral stuff. Sure. Online coke machines are just about as cool as coffee-pot webcams. They were in 1995. Back when the first one went online. That was too cool for me to express. But they're orthogonal to the discussion that was at hand, and your returning to that well in the middle of a serious discussion suggests that you, yourself, are not all that serious. Or perhaps that I was trying to cool the discussion down a bit. I had already tried to bring it to a close once It was an extended hyperbole of ridiculousness. Soda machines. Mm. Once is tongue in cheek. Twice or three times is dilettante. No, I think it just proves that saying the same stupid joke three times doesn't make it funny. Doesn't mean I am a dilettante network operator. Just means I'm not funny. ;-) I don't know, Patrick; you seem to be the one emotionalizing the argument. Yeah, I have a sharp tongue too. And I am a dillettante. And everything I say is just so cute and precious. And I am Wrong. I'm out of this one though; we are certainly out of AUP. I'm with you on this, for sure. If you want to address me off-list please feel free. --Patrick Darden
RE: Is it time to abandon bogon prefix filters?
Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
was bogon filters, now Brief Segue on 1918
Was looking over 1918 again, and for the record I have only run into one network that follows: If two (or more) organizations follow the address allocation specified in this document and then later wish to establish IP connectivity with each other, then there is a risk that address uniqueness would be violated. To minimize the risk it is strongly recommended that an organization using private IP addresses choose *randomly* from the reserved pool of private addresses, when allocating sub-blocks for its internal allocation. I added the asterisks. Most private networks start at the bottom and work up: 192.168.0.X++, 10.0.0.X++, etc. This makes any internetworking (ptp, vpn, etc.) ridiculously difficult. I've seen a lot of hack jobs using NAT to get around this. Ugly. --Patrick Darden -Original Message- From: Darden, Patrick S. Sent: Wednesday, August 06, 2008 9:19 AM To: 'Leo Bicknell'; nanog@nanog.org Subject: RE: Is it time to abandon bogon prefix filters? Yes. 1918 (10/8, 172.16/12, 192.168/16), D, E, reflective (outgoing mirroring), and as always individual discretion. --Patrick Darden -Original Message- From: Leo Bicknell [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 9:10 AM To: nanog@nanog.org Subject: Is it time to abandon bogon prefix filters? Bogon filters made a lot of sense when most of the Internet was bogons. Back when 5% of the IP space was allocated blocking the other 95% was an extremely useful endevour. However, by the same logic as we get to 80-90% used, blocking the 20-10% unused is reaching diminishing returns; and at the same time the rate in which new blocks are allocated continues to increase causing more and more frequent updates. Have bogon filters outlived their use? Is it time to recommend people go to a simpler bogon filter (e.g. no 1918, Class D, Class E) that doesn't need to be updated as frequently? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: was bogon filters, now Brief Segue on 1918
Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 11:21 AM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 Darden, Patrick S. wrote: *randomly* from the reserved pool of private addresses, when You're supposed to choose ula-v6 /48 prefixs randomly as well... Any bets on whether that routinely happens? While you're home can probably randomly allocate subnets out of a /8 or /12 for a while without collisions, nobody that's actually building a subnetting plan for a large private network is going to be able to get away with that in v4.
RE: was bogon filters, now Brief Segue on 1918
Well, how about this then: 10.Z.X.Y with Z being continent, X being country name with letters beginning with A assigned 1-10, B 11-20, with any unused letters having their numbers appended as needed, and Y being of course the host/int itself with maybe still 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) continent 1:10.100.x.y/16 provides ~65,000 IP addresses Continent 2:10.101.x.y/16 provides the same continent 3:whoa, asian market is big, better allocate for enterprise growth. 10.102.x.y and 10.103.x.y cont 4: 10.104/16 cont 5: 10.105/16 We have provided for ~400,000 employees here, fairly spread out equally amongst your 5 continents. With lots of room for growth by just adding another 10.Z/16 or two to each continent. Country algeria gets 10.100.1 and 10.100.2, country aguonia (?) gets 10.100.3 and 10.100.4, country bwabistan gets 10.100.11-15 (~1270 usable IPs, room for 150 servers, 250 printers, 500 PCs, 250 simultaneous telecommuters, and 100 switches and routers) because the company is big there. Etc. etc. My off the cuff network scheme isn't very good, but you get the drift. RFC1918 works. Details just have to be worked out on a case by case basis. IPV6 where are you?! --p -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 12:36 PM To: Darden, Patrick S. Cc: nanog@nanog.org Subject: Re: was bogon filters, now Brief Segue on 1918 Darden, Patrick S. wrote: Most organizations that would be doing this would not randomly pick out subnets, if I understand you. They would randomly pick out a subnet, then they would sub-subnet that based on a scheme. I believe this is the intent of RFC 1918. Not to apply a random IP scheme, but to randomly pick a network from the appropriate sized Private Networking ranges, then apply a well thought out scheme to the section of IP addresses you chose. E.g. 10.150.x.y/16 as their network. X could be physical positioning, and Y could be purposive in nature. 10.150.0.0 as basement, 10.150.1.0 as first floor, 10.150.2.0 as second floor, etc. 1-20 as switches/routers, 21-50 as servers and static workstations, 51-100 as printers, and 101--200 as DHCP scope for PCs, and 201-254 for remote login DHCP scope (vpn, dialup, etc.) Yes, I think a large private network would work this way. RFC 1918 wants it to work this way (imho). How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use?
RE: was bogon filters, now Brief Segue on 1918
Actually, rereading this, I agree. My experience is large companies take it all, using huge swathes inefficiently, instead of doing it right. In my previous post I was answering the question I thought you were asking, not your real question. I agree with you both. I think that RFC1918 Could work, if companies used it correctly Again, though, I have only run into one company that used it correctly. IPV6, you are our only hope! (obiwan kenobi, you are our only hope!) --p Joel said How much of 10/8 and 172.16/12 does an organization with ~80k employees, on 5 continents, with hundreds of extranet connections to partners and suppliers in addition to numerous aquistions and the occasional subsidiary who also use 10/8 and 172.16/12 use? Marshall said In my experience, effectively all of it.
RE: Is it time to abandon bogon prefix filters?
1. DOS of Cymru (as noted below). 2. False Positives. Your network is suddenly stranded. Maybe on purpose. (DOS of a network, e.g. China or Youtube). 3. False Negatives. A bogus network is suddenly centrally rubber-stamped. Could happen. We've seen a lot of shenanigans with the domain registrars--similar issues could happen here. . . I guess I am just trying to say that a centralized trusted repository brings with it a chance for a single point of failure. Could be the pros outweigh the cons. There are issues with a de-centralized system as well (which is what brought this conversation about.) Nothing specific to Cymru. --Patrick Darden -Original Message- From: Skywing [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 06, 2008 1:25 PM To: Patrick W. Gilmore; NANOG list Subject: RE: Is it time to abandon bogon prefix filters? Then again, it does make Team Cymru an attractive target for DoS or even compromise if they can control routing policy to a degree for a large number of disparate networks. Especially if it gets in the way of for-profit spammers. (Not trying to knock them, just providing a for consideration. I would certainly hope and expect that Team Cymru would do their due dilligance in that respect, but it seems like an attractive central point of failure to attack to me.) - S
