Re: IP address fee??
On Thu, 5 Sep 2002, Tony Tauber wrote: At least as importantly, why do 254 addresses get provided where the actual need might not warrant that quantity? Being out here on the edge, I ask that question a lot. Customer calls and says I need a static IP. I (actually our front line people) ask WHY?. If they mutter something like VPN or Mail Server or similar we give one to them without much discussion. If they say We need a block of 4 or 8 (/30 or /29) and they mutter something along the lines of We're running our own firewall and want to put a couple of servers on the outside, then we give them to them after some discusson of are you sure you need to do it this way? and explain the glories of PNAT to them. If they want a /28 or larger, they better be ready with a real netorking plan, really have a clue, and really understand why they don't want to use NAT or why they need more than the 8 addresses. IP Purists will probably be quick to jump all over me with the evils of NAT, but for the average small business it works perfectly well and solves a lot of security-related issues. (NOTE: I am not saying that NAT and a Stateful Inspection Firewall or similar is the same thing). The average office needs 1 probably-dynamic IP. Period. Back to the original poster's question. We charge a buck-a-month-per-ip more as a conservation tax than for anything else. Typically if we feel the customer has packed services as tightly as is reasonable in the address space we waive the fee (good use of NAT and/or other address conservation technologies and/or really valid technical reasons). Customers giving us reasons like I can't make my server do name-based (non SSL) virtual hosting so I need an IP for each domain I host or I think it would be cool to have a real publically visible address on each of my 100 computers in my Beowulf cluster of 486's are the types of things we don't waive the fees for even though they are valid enough reasons to hand out a block of address space for. - Forrest W. Christian ([EMAIL PROTECTED]) AC7DE -- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/Helena, MT 59604 Home of PacketFlux Technologies and BackupDNS.com (406)-442-6648 -- Protect your personal freedoms - visit http://www.lp.org/
Re: IP address fee??
On Thu, Sep 05, 2002 at 09:58:08PM -0400, Richard Welty wrote: [snip] about 2 years ago, interviewing fresh graduates for jobs, i found that they were still being taught classful networking at many colleges. Only half a year ago a teacher (university, subject: networking) told us (I'm a student) 'netmasks are not really needed, you can always infer them from the class'. By then he had already decided to ignore my corrections.. Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: IP address fee??
On Thu, Sep 05, 2002 at 03:19:08PM -0400, Christian Malo wrote: [snip] these days you can easily delegate reverse using CIDR with BIND ... http://www.faqs.org/rfcs/rfc2317.html And you can do it even easier without RFC2317: http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: IP address fee??
At 11:11 AM +0200 2002/09/06, Peter van Dijk wrote: And you can do it even easier without RFC2317: http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html Nope. Fundamentally broken. Delegations must occur at the apex of a zone. Trying to take advantage of certain mis-features in current versions of BIND does not excuse you from being responsible for doing the job properly in the first place, because you can be assured that future versions of BIND will most likely fix this feature. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: IP address fee??
On Fri, Sep 06, 2002 at 02:21:35PM +0200, Brad Knowles wrote: At 11:11 AM +0200 2002/09/06, Peter van Dijk wrote: And you can do it even easier without RFC2317: http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html Nope. Fundamentally broken. Delegations must occur at the apex of a zone. That is a common misconception. Recursing resolvers couldn't care less if they are written according to spec (unlike old BIND versions, for example). Also, it's easy (with tinydns) or not very hard (with BIND) to implement given solution without violating your condition. Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those. Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: IP address fee??
On Fri, 06 Sep 2002 14:42:39 +0200, Peter van Dijk [EMAIL PROTECTED] said: That is a common misconception. Recursing resolvers couldn't care less if they are written according to spec (unlike old BIND versions, for example). Well... way back when (18 months or so)... On Thu, 01 Feb 2001 18:11:34 PST, Paul Vixie [EMAIL PROTECTED] said: [EMAIL PROTECTED] (Pim van Riezen) writes: bogosity while updating 8.2.2-P7 to 8.2.3: (1) 8.2.3 Doesn't accept the ( in the SOA string to be on the next line after the IN SOA. Our script-generated zonefiles, about 45000 of them, all had this. Neither do the relevant RFC's, or any other DNS implementation. Pre-8.2.3 was simply _wrong_ to accept that syntax. If you want to be the *next* guy who gets bit for 45K zones when the *next* next release starts enforcing something that was illegal-but-worked-mostly, be my guest -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg05138/pgp0.pgp Description: PGP signature
Re: Vulnerbilities of Interconnection
Hi, [EMAIL PROTECTED] wrote: Again, it seems more likely and more technically effective to attack internally than physically. Focus again here on the cost/benefit analysis from both the provider and disrupter perspective and you will see what I mean. Is there a general consensus that cyber/internal attacks are more effective/dangerous than physical attacks. Anecdotally it seems the largest Internet downages have been from physical cuts or failures. It depends on what you consider and internet outage. Or how you define that. IMHO. Jane 2001 Baltimore train tunnel vs. code red worm (see keynote report) 1999 Mclean fiber cut - cement truck ATT cascading switch failure Utah fiber cut (date??) Not sure where the MAI mess up at MAE east falls Utah fiber cut (date??) Then again this is the biased perspetive of the facet I'm researching Secondly it seems that problems arise from physical cuts not because of a lack of redundant paths but a bottlneck in peering and transit - resulting in ripple effects seen with the Baltimore incident. - Original Message - From: William B. Norton [EMAIL PROTECTED] Date: Thursday, September 5, 2002 3:04 pm Subject: Re: Vulnerbilities of Interconnection At 02:45 PM 9/5/2002 -0400, [EMAIL PROTECTED] wrote: This obviously would be a thesis of Equinix and other collo space providers,since this is exactly the service that they provide. It won't, hower, be a thesis of any major network that either already has a lot of infrastructurein place or has to be a network that is supposed to survive a physical attack. Actually, the underlying assumption of this paper is that major networks already have a large global backbone that need to interconnect in n-regions. The choice between Direct Circuits and Colo-based cross connects is discussed and documented with costs and tradeoffs. Surviving a major attack was not the focus of the paper...but... When I did this research I asked ISPs how many Exchange Points they felt were needed in a region. Many said one was sufficient, that they were resilient across multiple exchange points and transit relationships, and preferred to engineer their own diversity separate from regional exchanges. A bunch said that two was the right number, each with different operating procedures, geographic locations, providers of fiber, etc. , as different as possible. Folks seemed unanimous about there not being more than two IXes in a region, that to do so would splinter the peering population. Bill Woodcock was the exception to this last claim, positing (paraphrasing) that peering is an local routing optimization and that many inexpensive (relatively insecured) IXes are acceptable. The loss of any one simply removes the local routing optimization and that transit is always an alternative for that traffic. A couple physical security considerations came out of that research: 1) Consider that man holes are not always secured, providing access to metro fiber runs, while there is generally greater security within colocation environments This is all great, except that the same metro fiber runs are used to get carriers into the super-secure facility, and, since neither those who originate information, nor those who ultimately consume the information are located completely within facility, you still have the same problem. If we add to it that the diverse fibers tend to aggregate in the basement of the building that houses the facility, multiple carriers use the same manholesfor their diverse fiber and so on. Fine - we both agree that no transport provider is entirely protected from physical tampering if its fiber travels through insecure passageways. Note that some transport capacity into an IX doesn't necessarily travel along the same path as the metro providers, particularly those IXes located outside a metro region. There are also a multitude of paths, proportional to the # of providers still around in the metro area, that provide alternative paths into the IX. Within an IX therefore is a concentration of alternative providers, and these alternative providers can be used as needed in the event of a path cut. 2) It is faster to repair physical disruptions at fewer points, leveraging cutovers to alternative providers present in the collocation IX model, as opposed to the Direct Circuit model where provisioning additional capacities to many end points may take days or months. This again is great in theory, unless you are talking about someone who is planning on taking out the IX not accidently, but deliberately. To illustrate this, one just needs to recall the infamous fiber cut in McLean in 1999 when a backhoe not just cut Worldcom and Level(3) circuits, but somehow let a cement truck to pour cement into Verizon's
classless delegation [was: Re: IP address fee??]
On Fri, Sep 06, 2002 at 09:10:45AM -0400, [EMAIL PROTECTED] wrote: On Fri, 06 Sep 2002 14:42:39 +0200, Peter van Dijk [EMAIL PROTECTED] said: That is a common misconception. Recursing resolvers couldn't care less if they are written according to spec (unlike old BIND versions, for example). Well... way back when (18 months or so)... I'm not referring to that particular problem, but read on. On Thu, 01 Feb 2001 18:11:34 PST, Paul Vixie [EMAIL PROTECTED] said: [EMAIL PROTECTED] (Pim van Riezen) writes: bogosity while updating 8.2.2-P7 to 8.2.3: (1) 8.2.3 Doesn't accept the ( in the SOA string to be on the next line after the IN SOA. Our script-generated zonefiles, about 45000 of them, all had this. Neither do the relevant RFC's, or any other DNS implementation. Pre-8.2.3 was simply _wrong_ to accept that syntax. If you want to be the *next* guy who gets bit for 45K zones when the *next* next release starts enforcing something that was illegal-but-worked-mostly, be my guest A fun note is that BIND, in that situation (I worked for Vuurwerk at that time as well), just put some (high-ascii) garbage in the logfile and segfaulted, instead of reporting a nice error. Ofcourse it is also highly broken that the RFC specifies the zonefile syntax. [I think we're drifting offtopic here] Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: IP address fee??
At 2:42 PM +0200 2002/09/06, Peter van Dijk wrote: That is a common misconception. Recursing resolvers couldn't care less if they are written according to spec (unlike old BIND versions, for example). Just because something accidentally manages to work at the moment doesn't mean that the whole concept is not fundamentally broken. You delegate zones, not IP addresses. Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those. Okay, so you've made 192.122.109.193.in-addr.arpa a zone (delegated from bit.nl within 122.109.193.in-addr.arpa, which is delegated from RIPE's 193.in-addr.arpa), and this zone has an SOA and NS records defined. Other than the fact that this zone is within the in-addr.arpa tree, this would seem to be fairly normal behaviour for any other zone in any other tree. However, it doesn't appear to have a PTR record. Contrariwise, 193.122.109.193.in-addr.arpa has an SOA, NS RRs, and a PTR. I'm sure your other zones look similar. Bizarre. Truly bizarre. Somehow, I feel compelled to make some remark about perverting the course of the DNS, or somesuch. It's a wonder you have any Internet connectivity at all. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: IP address fee??
On Fri, Sep 06, 2002 at 03:32:00PM +0200, Brad Knowles wrote: [snip] Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those. Okay, so you've made 192.122.109.193.in-addr.arpa a zone (delegated from bit.nl within 122.109.193.in-addr.arpa, which is delegated from RIPE's 193.in-addr.arpa), and this zone has an SOA and NS records defined. Other than the fact that this zone is within the in-addr.arpa tree, this would seem to be fairly normal behaviour for any other zone in any other tree. in-addr.arpa is not special from a DNS point-of-view. However, it doesn't appear to have a PTR record. Contrariwise, 193.122.109.193.in-addr.arpa has an SOA, NS RRs, and a PTR. I'm sure your other zones look similar. Indeed 192 doesn't have a PTR - it's the network number. 193 and a few others do indeed have PTR's. Bizarre. Truly bizarre. Somehow, I feel compelled to make some remark about perverting the course of the DNS, or somesuch. What am I doing wrong in this case? A zone is delegated, the nameserver receiving the delegation serves this zone. No apexes mismatch. Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: Vulnerbilities of Interconnection
Is there a general consensus that cyber/internal attacks are more effective/dangerous than physical attacks. Anecdotally it seems the largest Internet downages have been from physical cuts or failures. It depends on what you consider and internet outage. Or how you define that. IMHO. Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? Alex
Re: IP address fee??
On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Joe
Re: IP address fee??
At 3:32 PM +0200 2002/09/06, Brad Knowles wrote: Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those. The page you originally referenced says: The first three records are simply there to make BIND happy about loading the zone from the database file. (Would that it did not require them! But - alas! - it would complain were they not there.) Your content DNS server will serve those resource records up to the world (the NS resource records in the authority section of responses and the SOA resource record in no such name responses) but the world will ignore them, so this does not matter one iota. A correctly operating resolving proxy DNS server must discard them because their names are outside of your content DNS server's bailiwick. in-addr.arpa. is not delegated to your content DNS server, only subdomains within it are. The key phrase is A correctly operating resolving proxy DNS server must discard them Do you have any idea whatsoever how many incredibly badly mis-configured and incorrectly operating caching nameservers there are in the world?!? My talk at LISA 2002 is going to cover (in part) how many badly mis-configured and incorrectly operating TLD nameservers there are in the world, and above all other servers of all other types (except the root servers themselves), these should be more correct and properly configured. And yet, there is an unbelievable number of these servers that are not correctly configured, and some of them are incredibly screwed-up. $DEITY!!! Even trying to conceive of the scale of the numbers of screwed-up caching nameservers just totally boggles the mind. I doubt that there is anyone in the world that could come up with an accurate estimate. Now, if you wanted to do separate zone files, and make sure that each zone file doesn't contain any out-of-zone data, that would be a different issue. But this is like handing people sticks of dynamite, flamethrowers, and encouraging them to ignite the explosives they're holding in their hands. If you really want to do this (and especially do it this way), all I can say is that, sooner or later, you *will* get what you deserve. Bizarre. Truly bizarre. Somehow, I feel compelled to make some remark about perverting the course of the DNS, or somesuch. Now *this* is pretty cool: DNS Expert Detailed Report for 192.122.109.193.in-addr.arpa. 9/6/02, 4:05 PM, using the analysis setting Everything == Information -- Serial number: 1031317961 Primary name server: ns.dataloss.nl. Primary mail server: N/A Number of records: N/A Errors -- o The reverse zone contains one or more A records The reverse domain 192.122.109.193.in-addr.arpa. contains one or more A records. A records should only be placed in forward-mapping domains. Warnings -- o The name server ns.dataloss.nl. does not permit zone transfers The name server ns.dataloss.nl. has been configured to reject unauthorized zone transfers and the application will not be able to use data from this server while analyzing the zone. o The name server ns3.dataloss.nl. does not permit zone transfers The name server ns3.dataloss.nl. has been configured to reject unauthorized zone transfers and the application will not be able to use data from this server while analyzing the zone. o Zone transfer from authoritative servers not possible It was not possible to perform a zone transfer from any of the authoritative name servers for the zone. This will limit the range of tests performed for the zone. o The TTL field in the SOA record contains an unusually low value The value 2560 of the TTL field in the SOA record field is unusually low. The value for this field should be within the range 3600 - 172800. o The Minimum TTL field in the SOA record contains an unusually low value The value 2560 of the Minimum field in the SOA record is unusually low. The value for this field should be within the range 3600 - 172800. o The Serial number field in the SOA record contains an unusual value It appears that the Serial number field in the SOA record is based on a date value that is in the future. o The TTL value 259200, in the A record ns.dataloss.nl. is rather high The TTL value 259200,
Re: IP address fee??
I have tended as of late to avoid using the term class A/B/C. Too many people at my job do not understand the meaning and make themselves look stupid. I have instead resorted to using mask be it a /24 or a /27 aka slash 27 it seems to work well with the people who have some experience. Other you have to train from the binary .111... But in the end the classing of addresses has gone the way for EGP depricated. On Fri, 2002-09-06 at 10:00, Joe Abley wrote: On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Joe -- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:[EMAIL PROTECTED] http://www.dialtone.com The only source of knowledge is experience. - A. Einstein
Re: Vulnerbilities of Interconnection
On Fri, 2002-09-06 at 10:01, [EMAIL PROTECTED] wrote: What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? Keep in mind that traffic in the global internet after N x 500 kgs of explosives are simultaneously detonated will upsurge, directed towards major news sites. I'll go back to lurking now. Ryan
Re: IP address fee??
At 3:40 PM +0200 2002/09/06, Peter van Dijk wrote: in-addr.arpa is not special from a DNS point-of-view. Technically, you are correct. However, this issue is as much about how the DNS has been used historically, and general agreed-upon principles by which the DNS should be used, as it is about how do you technically serve that information. If you have a nail and a hammer, there are ways of using the hammer to hit the nail that will be less productive than others (in terms of nailing some object to another). If you choose to lay the nail flat on the top object and hit the side of the nail with the hammer, you're welcome to do so. However, if you do this, don't be surprised when it doesn't stick to second object very well. Moreover, don't come complaining to me, or anyone else, who told you that this was stupid thing to do. Bizarre. Truly bizarre. Somehow, I feel compelled to make some remark about perverting the course of the DNS, or somesuch. What am I doing wrong in this case? A zone is delegated, the nameserver receiving the delegation serves this zone. No apexes mismatch. For the most part, we only care about mis-uses and abuses of technical tools (like the DNS) to the degree that we can modify future versions of the programs that serve these protocols to refuse to function in this manner, thus preventing people from accidentally (or otherwise) doing these kinds of incredibly stupid things. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Vulnerbilities of Interconnection
Hi Alex, [EMAIL PROTECTED] wrote: Is there a general consensus that cyber/internal attacks are more effective/dangerous than physical attacks. Anecdotally it seems the largest Internet downages have been from physical cuts or failures. It depends on what you consider and internet outage. Or how you define that. IMHO. Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? N? Well, if you define N as the number of interconnect facilities, such as all the Equinix sites (and I'm not banging on Equinix, it's just where we started all this) then I think globally, it wouldn't make that much difference. People in Tokyo would still be able to reach the globe and both coasts of the US. Maybe some sites in the interior of the US would be difficult to reach. I'd have to run a model to be sure, but every one of the major seven have rerouting methodologies that would recover from the loss. And I don't think they exclusively peer at Equinix. The more I think about it, the more sure I am that they don't. However I could be wrong. Wouldn't be the first time. Jane Alex
RE: IP address fee??
I have tended as of late to avoid using the term class A/B/C. Too many people at my job do not understand the meaning and make themselves look stupid. I have instead resorted to using mask be it a /24 or a /27 aka slash 27 it seems to work well with the people who have some experience. Other you have to train from the binary .111... But in the end the classing of addresses has gone the way for EGP depricated. I never really used the Class C tag because it has rarely been correct at any place I've worked; the first place I worked, we had a class B and used 8-bit subnets of it for departments (before the CIDR notation became popular, the common name seemed to be 8-bit subnets); the next place, we had a /19 CIDR block out of Class A IP space as our primary address space (among 100 other network blocks). In neither case would it be correct to call a /24 a Class C. Although I do call 203-space networks Class C, because they are. A class refers to more than just the prefix length, it refers to the location in IP space as well. Classful routing still causes occasional headaches, in that people who don't configure their routers properly may accidentally be unable to reach the whole /8 which contains our /19 (among others, of course). Or if you use RIPv1, any IP outside your defined network statements is automatically advertised as the classful aggregate containing that IP (or doesn't that happen anymore?), causing horrible things to happen (I worked at one Australian university, one of our staff dialed up to another and specified their home static IP via PPP (IPCP), that universities' access server automatically inserted a class B into it's RIP and that university was doing RIPv1 with Telstra, effectively overriding the Australian routing table -- at the time, Telstra _were_ the network -- and black-holing us as they were further east than we were, ie, closer to the international gateway). Although I have to shamefully admit my very small contribution to Zebra was the classful routing assumptions for RIPv1 so we could use it at the university I worked at (in the end it couldn't handle interfaces dynamically appearing/disappearing so we used gated then migrated to a hacked up routed as gated wasn't handling newer Linux variants and I was terminating the student PPTP sessions on my personal workstation running Linux). David. On Fri, 2002-09-06 at 10:00, Joe Abley wrote: On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Joe -- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:[EMAIL PROTECTED] http://www.dialtone.com The only source of knowledge is experience. - A. Einstein
Re: Vulnerbilities of Interconnection
Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? N? Well, if you define N as the number of interconnect facilities, such as all the Equinix sites Lets say that N is 4 and they are all in the US, for the sake of the discussion. (and I'm not banging on Equinix, it's just where we started all this) then I think globally, it wouldn't make that much difference. People in Tokyo would still be able to reach the globe and both coasts of the US. This presumes that the networks peer with the same AS numbers everywhere in the world, which I dont think they do. The other thing to think about is that the physical transport will be affected as well. Wavelenth customers will lose their paths. Circuit customers that rely on some equipment located at the affected sites, losing their circuits. Alex
RE: Vulnerbilities of Interconnection
What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? Not knowing how much damage would result from 500kg of explosives.. What is the typical size of pipe a carrier would pull into an interconnect facility, how many carriers, how much traffic? Now how much traffic would shift to other facilities if one went down? How many would it take to saturate the pipes? And at what point would congestion be bad enough to render them useless? At some point traffic will shift over to private interconnects either through complete loss of peering in third party facilities, or through manual intervention. Kris
classless delegation [Re: IP address fee??]
On Fri, Sep 06, 2002 at 04:06:40PM +0200, Brad Knowles wrote: At 3:32 PM +0200 2002/09/06, Brad Knowles wrote: Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those. [snip] The key phrase is A correctly operating resolving proxy DNS server must discard them Yes. This is your original complaint about matching apexes with delegations. I am not violating that condition, however. Now, if you wanted to do separate zone files, and make sure that each zone file doesn't contain any out-of-zone data, that would be a different issue. But this is like handing people sticks of dynamite, flamethrowers, and encouraging them to ignite the explosives they're holding in their hands. I am doing separate zone files. Each IP delegated to me is a separate zone. Now, again, what is wrong with that? DNS Expert Detailed Report for 192.122.109.193.in-addr.arpa. 9/6/02, 4:05 PM, using the analysis setting Everything == Information -- Serial number: 1031317961 Primary name server: ns.dataloss.nl. Primary mail server: N/A Number of records: N/A Errors -- o The reverse zone contains one or more A records The reverse domain 192.122.109.193.in-addr.arpa. contains one or more A records. A records should only be placed in forward-mapping domains. What A-records is it talking about? I am not seeing any. [axfr is closed] [banter about SOA values] [all servers on the same subnet] DNS Expert Detailed Report for 193.122.109.193.in-addr.arpa. 9/6/02, 4:05 PM, using the analysis setting Everything == Information -- Serial number: 1031317961 Primary name server: ns.dataloss.nl. Primary mail server: N/A Number of records: N/A Errors -- o The reverse zone contains one or more A records The reverse domain 193.122.109.193.in-addr.arpa. contains one or more A records. A records should only be placed in forward-mapping domains. Again, I am not seeing any A records. [no axfr] [soa values] [all servers on the same subnet] What about this? % dnswalk -ralF 122.109.193.in-addr.arpa. Checking 122.109.193.in-addr.arpa. Getting zone transfer of 122.109.193.in-addr.arpa. from ns2.bit.nl...done. SOA=ns.bit.nl contact=root.bit.nl [hosts outside my /29] [failed zonetransfers] Nothing there that's wrong with my /29. DNS Expert Detailed Report for 122.109.193.in-addr.arpa. This is the parent zone. 9/6/02, 3:56 PM, using the analysis setting Everything == Information -- Serial number: 2002090401 Primary name server: ns.bit.nl. Primary mail server: N/A Number of records: 112 (34 NS, 0 MX, 0 A, 0 CNAME, 78 PTR, 0 Other) Errors -- [hosts outside my /29] Indeed, you found some things wrong with the /24 zone, but that was not the subject, and nothing you found wrong with the /24 is related to the /29. Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: Vulnerbilities of Interconnection
On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: :would be difficult to reach. I'd have to run a model to be sure, but :every one of the major seven have rerouting methodologies that would :recover from the loss. And I don't think they exclusively peer at Even if we were to model it, the best data we could get for the Internet would be BGP routing tables. These are also subjectve views of the rest of the net. We could take a full table, map all the ASN adjacencies, and then pick arbtrary ASN's to fail, then see who is still connected, but we are still dealing with connectivity relatve to us and our peers, even 5+ AS-hops away. I would imagine this is one of the tasks CAIDA.org is probably working on, as it seems to fall within their mission. So even if we all agreed upon a common disaster to hypothesize on, there would be little common ground to be had, as our interpretations could only be political arguments over what is most important, because there is no technically objective view of the network to forge agreement on. Cheers, -- batz
Re: Vulnerbilities of Interconnection
You also have the problem of cascading failures. Just because there are redundant paths and alternate peering locations does not mean those facilites have the bandwidth to handle all the redirected traffic. If A gets swamped you go to B if the redrected traffic is to much for B then you go to C and so on - each time the amount of traffic increases and the avialble bandwidth decreases. According to the analysis I've seen and run on the the Baltimore incident this is the jest of how a few cut lines rippled across the Internet. I would think Alex's scenario would have a bigger impact than that incident. sean - Original Message - From: [EMAIL PROTECTED] Date: Friday, September 6, 2002 10:29 am Subject: Re: Vulnerbilities of Interconnection Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? N? Well, if you define N as the number of interconnect facilities, such as all the Equinix sites Lets say that N is 4 and they are all in the US, for the sake of the discussion. (and I'm not banging on Equinix, it's just where we started all this) then I think globally, it wouldn't make that much difference. People in Tokyo would still be able to reach the globe and both coasts of the US. This presumes that the networks peer with the same AS numbers everywhere in the world, which I dont think they do. The other thing to think about is that the physical transport will be affected as well. Wavelenth customers will lose their paths. Circuit customers that rely on some equipment located at the affected sites, losing their circuits. Alex
Re: classless delegation [Re: IP address fee??]
At 4:40 PM +0200 2002/09/06, Peter van Dijk wrote: I am doing separate zone files. Each IP delegated to me is a separate zone. Now, again, what is wrong with that? Technically, nothing -- at least, with the absolute latest authoritative nameservers and the absolute latest recursive/caching nameservers, and it doesn't seem to give much problems to modern resolver libraries. Procedurally, everything is wrong with it -- in part, because of the profusion of mis-configured authoritative and recursive/caching nameservers that exist on the Internet today (not to mention resolving libraries), the fact that most vendors today still ship vulnerable authoritative recursive/caching nameservers with their OSes (and *no one* ships an OS that uses modern resolver libraries), and the fact that 99.99% of the people on the 'net will take the default garbage that the vendor ships to them simply because they don't know any better. o The reverse zone contains one or more A records The reverse domain 192.122.109.193.in-addr.arpa. contains one or more A records. A records should only be placed in forward-mapping domains. What A-records is it talking about? I am not seeing any. They are the ones associated with your NS records. At a procedural level, PTR records are mutually exclusive with SOA NS records. Indeed, you found some things wrong with the /24 zone, but that was not the subject, and nothing you found wrong with the /24 is related to the /29. See above. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: classless delegation [Re: IP address fee??]
On Fri, Sep 06, 2002 at 04:56:09PM +0200, Brad Knowles wrote: [snip] I am doing separate zone files. Each IP delegated to me is a separate zone. Now, again, what is wrong with that? Technically, nothing -- at least, with the absolute latest authoritative nameservers and the absolute latest recursive/caching nameservers, and it doesn't seem to give much problems to modern resolver libraries. ['it will break with lots of software'] I am very willing to believe everything that you are saying, but *what part* of my configuration breaks those nameservers? o The reverse zone contains one or more A records The reverse domain 192.122.109.193.in-addr.arpa. contains one or more A records. A records should only be placed in forward-mapping domains. What A-records is it talking about? I am not seeing any. They are the ones associated with your NS records. At a procedural level, PTR records are mutually exclusive with SOA NS records. But there are no A records in that zone. Again, what A-records? I have, by the way, enabled AXFR to the world for my reverse zones (all 16), so feel free to have a look. Also, I am aware that the hostmaster-address in the SOA for these zones is bogus - I will fix that shortly. Greetz, Peter -- [EMAIL PROTECTED] | http://www.dataloss.nl/ | Undernet:#clue
Re: Vulnerbilities of Interconnection
Hi, batz wrote: On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: :would be difficult to reach. I'd have to run a model to be sure, but :every one of the major seven have rerouting methodologies that would :recover from the loss. And I don't think they exclusively peer at Even if we were to model it, the best data we could get for the Internet would be BGP routing tables. These are also subjectve views of the rest of the net. We could take a full table, map all the ASN adjacencies, and then pick arbtrary ASN's to fail, then see who is still connected, but we are still dealing with connectivity relatve to us and our peers, even 5+ AS-hops away. I want to make sure I understand this. As I understand it, this would work regarding routing only. It would be a model that would have a result of ones and zeros, so to speak, meaning either you're connected or you're not. What this doesn't take into consideration, I believe, is the effects of congestion regarding increased traffic due to news traffic and rerouting that takes place whenever there is a loss of a site. I would imagine this is one of the tasks CAIDA.org is probably working on, as it seems to fall within their mission. So even if we all agreed upon a common disaster to hypothesize on, there would be little common ground to be had, as our interpretations could only be political arguments over what is most important, because there is no technically objective view of the network to forge agreement on. I totally agree. I think what I envision as not a huge impact would be devastating to others. That's mostly because I'm looking at it globally, like, if you take all routes as the denominator, and the lost routes as the numerator, four colo sites, even the big ones, wouldn't be *that* much effect. Proportionally. At first. Of course, if you're a smallish ISP operator and your one peering site happens to be at one of the four sites, you're done. Jane Cheers, -- batz
RE: IP address fee??
Just because I'm tired of this, it's mostly due to customer work. I learned CIDR first and foremost. I payed near no attention to Classful addressing. I just am in the habit, in particular, of saying Class C instead of /24. Any other block I use the CIDR notation, and then still have to explain how many this is. I cannot believe that everyone is really being this ridiculous. Can you all let this thread die. Yes, we should refer to everything as CIDR. No, 90% of our clients don't understand that. Yes, sometimes that carries over into tech conversations. Enough. Derek -Original Message- From: Joe Abley [mailto:[EMAIL PROTECTED]] Sent: Friday, September 06, 2002 10:01 AM To: Stephen Sprunk Cc: Richard A Steenbergen; Derek Samford; 'Owens, Shane (EPIK.ORL)'; [EMAIL PROTECTED] Subject: Re: IP address fee?? On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Joe
Re: Vulnerbilities of Interconnection
Hi Alex, [EMAIL PROTECTED] wrote: Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? N? Well, if you define N as the number of interconnect facilities, such as all the Equinix sites Lets say that N is 4 and they are all in the US, for the sake of the discussion. Which four? Makes a big difference. And there, we just got proprietary/classified. I've often wondered what difference there would be in attacking cable heads instead of colo sites. Cut off the country from everywhere. How bad would that be. (and I'm not banging on Equinix, it's just where we started all this) then I think globally, it wouldn't make that much difference. People in Tokyo would still be able to reach the globe and both coasts of the US. This presumes that the networks peer with the same AS numbers everywhere in the world, which I dont think they do. Hadn't thought of that. I'm not sure then of the impact. The other thing to think about is that the physical transport will be affected as well. Wavelenth customers will lose their paths. Circuit customers that rely on some equipment located at the affected sites, losing their circuits. For individual users, it might be devastating. Overall, globally, that's a different story. Jane
Bad Dog, no biscuit, Interland
So after four different phone calls to Interland, and four different hangups by the techs and a refusal to do anything Interland, your client is being bad. Five minute rate was very high Folks need to take security and abuse issues seriously. The time has come for operators to have responsive staff, and to use technology to thwart known bad things. Folks look at DOS/DDOS/IDS tools to check ingress traffic, lets also use them to check EGRESS as well.. Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3753 xx.yy.36.94:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3755 xx.yy.36.96:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3756 xx.yy.36.97:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3760 xx.yy.36.101:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3762 xx.yy.36.103:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3764 xx.yy.36.105:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3766 xx.yy.36.107:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3765 xx.yy.36.106:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3719 xx.yy.36.60:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3721 xx.yy.36.62:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3722 xx.yy.36.63:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3725 xx.yy.36.66:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3727 xx.yy.36.68:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3730 xx.yy.36.71:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3736 xx.yy.36.77:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3738 xx.yy.36.79:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3739 xx.yy.36.80:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3741 xx.yy.36.82:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3743 xx.yy.36.84:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3744 xx.yy.36.85:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3746 xx.yy.36.87:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3748 xx.yy.36.89:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3752 xx.yy.36.93:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3754 xx.yy.36.95:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3757 xx.yy.36.98:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3758 xx.yy.36.99:80 in via sis0 Sep 6 09:04:40 sentinel /kernel: ipfw: 2100 Deny TCP 64.19.151.228:3759 xx.yy.36.100:80 in via sis0
Re: Vulnerbilities of Interconnection
[EMAIL PROTECTED] said: Taking out an a collo would more than just increase time to download porn for a few days. and went on to say: Is there a general consensus that cyber/internal attacks are more effective/dangerous than physical attacks. Anecdotally it seems the largest Internet downages have been from physical cuts or failures. It depends on what you consider and internet outage. Or how you define that. IMHO. Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? The answer to the first thing is Yes, it would be back at full speed in 24 hours and the second thing is Unless N is unreasonably large, not much. The reason is that people like us work on running the internet. In case 1, suppose I am a porn magnate. (Obviously, I am not, or I would dress better and work less, but stay with me for a moment.) I sell two products: pictures, and online strippers. The pictures are a static gold mine, so chances are, I have them backed up. The strippers are at a studio near my hosting/colocation site, and backhauled via your favorite fiber-based protocol. I get a call saying, Hey, a terrorist from group X walked into the colo facility with a 12008 chassis filled with plastique, and, well, the entire site is a charred hole in the ground. After a few seconds of horror, greed takes over, and I call other nearby providers to see who can get me back up today, pay the telco a nice hefty fee to reroute my SONET connection to that provider, and the money is rolling in before sunset. In case 2, suppose it is 4 major peering points. No big deal for the bulk of traffic, because the bulk of traffic goes between the big players, and they are all privately peering. So are many of the medium-sized folks. Smaller folks often buy transit from a larger provider to reach everybody they cannot peer with. And even if you don't buy transit and don't have overseas peering and lose your connectivity because they picked your 4 favorite sites, you're not going to be down for long, because somewhere, you are close enough to a UUnet or a ATT or a Level 3 who can toss you a cable until you can get back on your feet. Yeah, an attack can make the Internet uncomfortable and cause a lot of scurrying and odd deals, but the provider who is completely screwed by an attack on 1 colo or 4 peering points is going to be an exception, not the rule. -Dave
Re: Vulnerbilities of Interconnection
Wow, nothing like jumping into the middle of a running discussion after deleting all previous messages unread :) On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: Hi Alex, [EMAIL PROTECTED] wrote: Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? N? Well, if you define N as the number of interconnect facilities, such as all the Equinix sites Lets say that N is 4 and they are all in the US, for the sake of the discussion. Which four? Makes a big difference. And there, we just got proprietary/classified. I've often wondered what difference there would be in attacking cable heads instead of colo sites. Cut off the country from everywhere. How bad would that be. I was under the impression that OCS/Homeland Security had already done a little study, perhaps aided by some other 3 letter agencies and some Telco's, for this very thing. I was also under the impression that the number of sites had to be sigificantly higher than 4 to do any real damage. (and I'm not banging on Equinix, it's just where we started all this) then I think globally, it wouldn't make that much difference. People in Tokyo would still be able to reach the globe and both coasts of the US. This presumes that the networks peer with the same AS numbers everywhere in the world, which I dont think they do. Hadn't thought of that. I'm not sure then of the impact. Additionally, a majority of peering, big peering, isn't on public exchanges is it? So, you'd have to find all the places that the larger providers connect to eachother and perhaps target these. Even with this there are the public exchanges so things 'should' fail over to them... Overall I recall the outcome from the study being that the internet was a significantly difficult target to completely kill, and even making a performance impact was somewhat difficult... I will say though, that my memory is a bit foggy on this particular study, I didn't participate in it, and I didn't read the actual results. Any info I have on it is third hand via a lawyer, so take all this with a grain of salt :) The other thing to think about is that the physical transport will be affected as well. Wavelenth customers will lose their paths. Circuit customers that rely on some equipment located at the affected sites, losing their circuits. For individual users, it might be devastating. Overall, globally, that's a different story. This was about the result I heard, you can easily cut out 'mom and pop' ISP, but cutting out a large provider is a tougher task with bombs... we already know its possible with the right routing 'update' :(
Re: IP address fee??
At 10:00 AM 9/6/02 -0400, Joe Abley postulated: On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Joe The class of an address is determined by the bit-pattern of the first octet of the address. 10.0.0.0 will always be a Class A address. 172.16.0.0 will always be a Class B address, and 192.168.0.0 will always be Class C address. I'm not aware of any RFC that rescinded the definition of the Class of an address. Masks, when associated with an address, enable one to determine (a), what network I'm on (if I'm an IP host) or (b) how many addresses exist within a given range of addresses (if I'm a routing table). Subnetting (robbing mask host bits (0's) to make network bits (1's) allowed one to more effectively use the decreasing amounts of networks that required less than the default number of addresses (65,536 in the case of a Class B) by more effeciently using the space one had been allocated. With subnetting, I can take one Classful network and make many (sub)networks from it. There was no way prior to 1993, however, to effectively represent the range of addresses in more than one Classful network. CIDR, simply stated, says that one can use any address with any mask, regardless of the original class of the address, to represent a range of addresses (i.e. rob network bits to make host bits). It allows the properties of IP to be more effectively used for IP host addressing (only need a /23 to support 400 IP hosts (a very effecient 78% use of the allocated space), as well as (one of the original, primary reasons for CIDR) aggregate (Supernet) X traditional Class C's into one routing statement (who today would advertise delivery to the range of 4,096 addresses from, for example, 192.168.192.0 through 192.168.207.255 with 16 individual traditional Class C statements?). Since NANOG is the front line, then perhaps that is where the oral tradition should be teaching the history of IP addressing, from Classful addressing (default masks) to Subnetting (other than default) to Supernetting (ranges of addresses regardless of original - or legacy if you will - class (Classless)). The prefix, of course, does not refer to the class of the address, but the number of contiguous ones in the mask. As far as pronounciation goes, I prefer slash 24 to two fifty five dot two fifty five dot two fifty five dot zero :) $.02 Ted Fischer
Re: IP address fee??
Thus spake Joe Abley [EMAIL PROTECTED] On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! I just write/say C unless the meaning would be ambiguous. How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. I'd bet most of the customers I deal with learned networking from OS manuals or CCNA study books, all of which still teach classful addressing as the primary method. All of the ones I work with use the term C or class C to refer to a /24, and all are noticeably slower when dealing with non-/24 masks. The point of communication is to get an idea across; if most of the people you communicate with don't understand slash notation, then you use terms they're familiar with even if they're imprecise or inaccurate. I think NANOG's ISP-centric membership may skew the perception of our lexicon's state. Most network operators are not ISPs. S
Re: IP address fee??
At 12:42 PM 9/6/02 -0400, you wrote: Was this reply directed at me, particularly? Joe Joe, Most definitely not. I felt that the two comments I included most closely represented the discussion and information I wanted to pass. No offense meant, I hope none taken, apologies if they were. Ted On Fri, Sep 06, 2002 at 12:33:09PM -0400, Ted Fischer wrote: At 10:00 AM 9/6/02 -0400, Joe Abley postulated: On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote: Because Cee is easier to pronounce than slash twenty-four. Ease of use trumps open standards yet again :) Nobody was talking. /24 is easier to type than class C. No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Joe The class of an address is determined by the bit-pattern of the first octet of the address. 10.0.0.0 will always be a Class A address. 172.16.0.0 will always be a Class B address, and 192.168.0.0 will always be Class C address. I'm not aware of any RFC that rescinded the definition of the Class of an address. Masks, when associated with an address, enable one to determine (a), what network I'm on (if I'm an IP host) or (b) how many addresses exist within a given range of addresses (if I'm a routing table). Subnetting (robbing mask host bits (0's) to make network bits (1's) allowed one to more effectively use the decreasing amounts of networks that required less than the default number of addresses (65,536 in the case of a Class B) by more effeciently using the space one had been allocated. With subnetting, I can take one Classful network and make many (sub)networks from it. There was no way prior to 1993, however, to effectively represent the range of addresses in more than one Classful network. CIDR, simply stated, says that one can use any address with any mask, regardless of the original class of the address, to represent a range of addresses (i.e. rob network bits to make host bits). It allows the properties of IP to be more effectively used for IP host addressing (only need a /23 to support 400 IP hosts (a very effecient 78% use of the allocated space), as well as (one of the original, primary reasons for CIDR) aggregate (Supernet) X traditional Class C's into one routing statement (who today would advertise delivery to the range of 4,096 addresses from, for example, 192.168.192.0 through 192.168.207.255 with 16 individual traditional Class C statements?). Since NANOG is the front line, then perhaps that is where the oral tradition should be teaching the history of IP addressing, from Classful addressing (default masks) to Subnetting (other than default) to Supernetting (ranges of addresses regardless of original - or legacy if you will - class (Classless)). The prefix, of course, does not refer to the class of the address, but the number of contiguous ones in the mask. As far as pronounciation goes, I prefer slash 24 to two fifty five dot two fifty five dot two fifty five dot zero :) $.02 Ted Fischer
Re: Vulnerbilities of Interconnection
Jane == Pawlukiewicz Jane [EMAIL PROTECTED] writes: Even if we were to model it, the best data we could get for the Internet would be BGP routing tables. These are also subjectve views of the rest of the net. We could take a full table, map all the ASN adjacencies, and then pick arbtrary ASN's to fail, then see who is still connected, but we are still dealing with connectivity relatve to us and our peers, even 5+ AS-hops away. Jane I want to make sure I understand this. As I understand it, Jane this would work regarding routing only. It would be a model Jane that would have a result of ones and zeros, so to speak, Jane meaning either you're connected or you're not. What this Jane doesn't take into consideration, I believe, is the effects Jane of congestion regarding increased traffic due to news Jane traffic and rerouting that takes place whenever there is a Jane loss of a site. I believe you are correct. Modelling the connectivity matrix [1] is good as a first approximation. The next thing to do would be to estimate the transition probabilities between ASi and ASj (you could do this by looking at the adjacencies one step out [2], for example. There are other methods of estimating the transition probabilities but most are foiled by a lack of available data. You can get a pretty good adjacency map doing table dumps from all of the route servers, looking glasses, etc.) Once you have the TP matrix, construct a vector of initial conditions to represent likely traffic sources -- i.e. the ASs containing CNN and the BBC, for example -- and look at how the traffic dissipates through an n-step Markov process [3]. This will tell you something about how heavily loaded with traffic certain ASs (the accumulation points) become, at least as a ratio to normal, but since we have no information about channel capacity available within each AS, it doesn't say much about actual congestion. It will, however, suggest where congestion is likely to occur if links have not been overprovisioned by some ratio. I think ;) The trick is in estimating the transition probabilities. I'm not sure this is a good method. Using adjacencies from one hop out assumes transit to two hops out. Using n hops out implies transit to n+1 hops and the bigger n gets the less accurately it will start representing the real mesh since it starts implicitly assuming symmetric transit everywhere once n is greater than, say, 4 or 5 or whatever the average AS path length is these days. -w [1] C_ij = 1 if i and j connected or i == j, 0 otherwise [2] If A_i is the number of adjacencies for ASi, then set transition probabilities P_ij proportional to (C_ij * A_j) / Sum_k (C_jk * A_k), normalized so that Sum_j P_ij = 1. [3] n-th step transition probabilities are (P_ij)^n -- William Waites [EMAIL PROTECTED] +1 416-717-2661 finger [EMAIL PROTECTED] for PGP keys Idiosyntactix Research Laboratories http://www.irl.styx.org -- NetBSD: ça marche!
Re: Vulnerbilities of Interconnection
Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? N? Well, if you define N as the number of interconnect facilities, such as all the Equinix sites Lets say that N is 4 and they are all in the US, for the sake of the discussion. Which four? Makes a big difference. And there, we just got proprietary/classified. I've often wondered what difference there would be in attacking cable heads instead of colo sites. Cut off the country from everywhere. How bad would that be. I was under the impression that OCS/Homeland Security had already done a little study, perhaps aided by some other 3 letter agencies and some Telco's, for this very thing. I was also under the impression that the number of sites had to be sigificantly higher than 4 to do any real damage. That study probably came from the same people who believe that Echelon can intercept every single email sent, in addition to every phone conversation and fax. Bankruptcies of two fiber carriers showed rather clear that those companies themselves do not know where do they have what and what depends on what. (and I'm not banging on Equinix, it's just where we started all this) then I think globally, it wouldn't make that much difference. People in Tokyo would still be able to reach the globe and both coasts of the US. This presumes that the networks peer with the same AS numbers everywhere in the world, which I dont think they do. Hadn't thought of that. I'm not sure then of the impact. Additionally, a majority of peering, big peering, isn't on public exchanges is it? So, you'd have to find all the places that the larger providers connect to eachother and perhaps target these. Even with this there are the public exchanges so things 'should' fail over to them... Interconnect sites are not public peering. It is simply a location where the networks exchange traffic with each other. This was about the result I heard, you can easily cut out 'mom and pop' ISP, but cutting out a large provider is a tougher task with bombs... we already know its possible with the right routing 'update' :( Tell it to those whose primary facility was in one tower of WTC and backup facility in another. Alex
Re: IP address fee??
On Fri, Sep 06, 2002 at 11:41:07AM -0500, Stephen Sprunk wrote: I'd bet most of the customers I deal with learned networking from OS manuals or CCNA study books, all of which still teach classful addressing as the primary method. All of the ones I work with use the term C or class C to refer to a /24, and all are noticeably slower when dealing with non-/24 masks. The point of communication is to get an idea across; if most of the people you communicate with don't understand slash notation, then you use terms they're familiar with even if they're imprecise or inaccurate. I think NANOG's ISP-centric membership may skew the perception of our lexicon's state. Most network operators are not ISPs. And half the internet's users type u r kewl, and think that ethernet is a broadband connection. Just because a misconception is popular doesn't mean we should indulge it. :) Think of it as a public service, if you make an effort to say /24, and someone asks and you explain it, thats one less confused person circulating around teaching others. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
Re: IP address fee??
On 9/6/2002 at 13:18:54 -0400, Richard A Steenbergen said: And half the internet's users type u r kewl, and think that ethernet is a broadband connection. Just because a misconception is popular doesn't mean we should indulge it. :) Think of it as a public service, if you make an effort to say /24, and someone asks and you explain it, thats one less confused person circulating around teaching others. Think of it as a service towards your own future, too. An awful lot of the new protocols and services arise out of college environments, and hence the proliferation of protocols that work fine in a campus network but somehow just don't fly in the real world.
Re: Vulnerbilities of Interconnection
At 07:41 PM 05/09/2002 -0400, batz wrote: On Thu, 5 Sep 2002 [EMAIL PROTECTED] wrote: :The question is what if someone was gunning for your fiber. To date :cuts have been unintentional. Obviously the risk level is much higher :doing a phyisical attack, but the bad guys in this scenario are not :teenage hackers in the parents basement. This happened recently in Quebec where there is a labour dispute with Videotron and one of the unions representing its workers. The dispute has been exaserbated by the sabotage of the companies fiber lines. Quick summary for those not familiar with this story http://therecord.com/business/technology/z083017A.html Its an interesting to contemplate how this event was presented in the media and perceived by the public at large. Consider the end result in the above story and consider two different motives. a) Angry union or union sympathizers cut fibre optic lines to put pressure on company, or corporate strike busters cut cable to make union look bad vs. b) International terrorists cut fibre optic lines With a) its a filler news item to be displaced by Shark Attacks and Gary Condit. b) Two words: media frenzy. Same end result, but two totally different reactions because of who the terrorists are/were... How about network operators ? Would you be any more or less pissed and react differently at the motives as to why someone attacked your network ? On a day to day basis, I see far more attacks from the usual suspects than from anything media frenzy worthy. I mean, how many code red and MS-SQL worm attacks do you see on a day to day basis Its so much, that I explain to customers its like cosmic background radiation when they turn on their firewalls for the first time and see connect attempts to port 1433 from international IP addresses :-( ---Mike
Re: How about a game of chess? (was Re: Vulnerbilities ofInterconnection)
Actually I do not know how to play chess maybe *Risk*, but your point is well taken. The intent is not provide a public recipe for taking down the Internet, that would be the opposite goal of the research to begin with. Regardless it is difficult line to tread and it is best to err on the side of caution. As for sampling biases - that is why it is only anecdotal evidence and the need for it to be questioned. Reports of Vinny accidently announcing his router as AS701 do not make it to the media very often. That aside the suggestion of how to model the Internet are very useful and the closer these models can get to operational reality the better. The intent being methodology not revealing data. Waites' approach is a good first step, but what next. Also if you know capacties how do you model a cascading effect that encompasses intra- network and inter-network traffic flows. Also it might be easier to calculate transition probabilities by summing across the rows of the adjaceny matrix then dividing the row components by the sum. - Original Message - From: Sean Donelan [EMAIL PROTECTED] Date: Friday, September 6, 2002 12:52 pm Subject: How about a game of chess? (was Re: Vulnerbilities of Interconnection) On Thu, 5 Sep 2002 [EMAIL PROTECTED] wrote: Is there a general consensus that cyber/internal attacks are more effective/dangerous than physical attacks. Anecdotally it seems the largest Internet downages have been from physical cuts or failures. I think you have a sampling bias problem. The biggest national/international network disruptions have generallybeen the result of operator error or software error. Its not always easy to tell the difference. It may be better for carrier PR spin control to blame a software/router/switch vendor. Until recently physical disruptions have been due to causes which don'teffect the stock price, carriers were more willing to talk about them. Carriers usually don't fire people due to backhoes, hurricanes, floods, or train derailments. What does this say about the effect of an external or internal cyber-attack? Not much. Naturally occuring physical and procedural disruptions have different properties than a directed attack. Not the least is hurricanesand trains don't read NANOG, and generally don't alter their behavior based on the recommendations posted. Wouldn't you prefer a good game of chess?
Re: Vulnerbilities of Interconnection
On Fri, 6 Sep 2002, Mike Tancsa wrote: :How about network operators ? Would you be any more or less pissed and :react differently at the motives as to why someone attacked your network :? To a network technician, it doesn't matter whether it's terrorists or cow tipping teenagers causing outages, as the depth of analysis required to fix the problem doesn't involve speculating about the identities and motives of the perpetrators. Even as a network operator, you have to respond to incidents based on what you can do about them, which with a few exceptions, is seperate from who caused the incident, or why they did it. The Why's of network outages have more to do with why didn't it fail over and how can be make sure it does next time?, than are cow tipping terrorists rampaging through my network?. There is a human tendency to react to situations using information from the very edge of our knowledge and understanding, (It must be something to do with superstrings! Just let me do some reasearch and I'll get back to you about the *real* cause of these network problems..) and this is something we have to take into account when working on problems so we don't get sidetracked from solving the problem at hand. Cheers, -- batz
Re: Vulnerbilities of Interconnection
On Fri, Sep 06, 2002 at 01:55:40PM -0400, batz wrote: On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: :would be difficult to reach. I'd have to run a model to be sure, but :every one of the major seven have rerouting methodologies that would :recover from the loss. And I don't think they exclusively peer at ASN's to fail, then see who is still connected, but we are still dealing with connectivity relatve to us and our peers, even 5+ AS-hops away. I would imagine this is one of the tasks CAIDA.org is probably working on, as it seems to fall within their mission. Coming up with the as interconnection data is actaully fairly easy if you parse route-views data. This obviously doesn't cover every possible interconnection that exists but it does provide a large swath of data to review for the interconnection postulation. Looking at that data, (this is an old snapshot) the top ten networks are: (in #10-#1 order) conn ASN + 161 3356 229 1 242 2914 248 209 274 6461 277 3561 295 3549 328 7018 484 701 493 1239 - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: Vulnerbilities of Interconnection
On Fri, 06 Sep 2002 17:15:52 EDT, batz said: To a network technician, it doesn't matter whether it's terrorists or cow tipping teenagers causing outages, as the depth of analysis required to fix the problem doesn't involve speculating about the identities and motives of the perpetrators. Actually, it does. If it's a cable cut caused by a backhoe or a cow-tipping teenager, I can probably safely send out a tech with a splicing kit. If it's a terrorist attack, I may want to think for a bit whether I can re-route around it and let authorities secure the area before I even THINK of sending in a tech with a splicing kit. It's the rare backhoe or bovine that presents a threat of boobytraps, chemical/biological weapons, snipers, etc -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg05177/pgp0.pgp Description: PGP signature
Re: classless delegation [Re: IP address fee??]
At 5:11 PM +0200 2002/09/06, Peter van Dijk wrote: I am very willing to believe everything that you are saying, but *what part* of my configuration breaks those nameservers? $DEITY-only-knows how older/less capable nameserver software will deal with the issue of having a zone that is also a PTR record. But there are no A records in that zone. Again, what A-records? The A RRs in the glue that goes along with the NS records that are a result of making this a zone. I have, by the way, enabled AXFR to the world for my reverse zones (all 16), so feel free to have a look. Will do. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
Re: Vulnerbilities of Interconnection
On Fri, 6 Sep 2002, batz wrote: To a network technician, it doesn't matter whether it's terrorists or cow tipping teenagers causing outages, as the depth of analysis required to fix the problem doesn't involve speculating about the identities and motives of the perpetrators. It does matter. A cow might fall over and break a line card, but a savvy attacker could give you a linecard that kills chassis such that they make linecards that kill chassis.. When every piece of gear you have in a reagon is dead due to poor failure containment, you'll be wishing you had only suffered a chance failure.
Re: How about a game of chess? (was Re: Vulnerbilities of Interconnection)
On Fri, 6 Sep 2002 [EMAIL PROTECTED] wrote: Actually I do not know how to play chess maybe *Risk*, but your point is well taken. The intent is not provide a public recipe for taking down the Internet, that would be the opposite goal of the research to begin with. Regardless it is difficult line to tread and it is best to err on the side of caution. Bell Labs published papers on security problems in the IP protocol and the Clipper chip. On the other hand Bell Labs had a policy of not publishing papers about security issues in protocols such as SS7. Did not publishing the information keep the telephone network more secure, or did publishing make the Internet less secure? Did it make a difference? I don't know. People building new networks should be aware of the risks so they can address them. We don't keep fire or building codes a secret, because we want people to build safe buildings. How do people learn how to build secure networks if the information is secret?
Estimating Transition Probabilities
sgorman == [EMAIL PROTECTED] writes: sgorman Also it might be easier to calculate transition sgorman probabilities by summing across the rows of the adjaceny sgorman matrix then dividing the row components by the sum. I'm not surethat that works. That would cause systems not adjacent to i to contribute to the probability that a packet goes from i to j in one step, if I understand correctly. There is also a hidden imbedded Markov chain in my formulation. Firstly, to avoid confusion with terminology, i am using: A_i - adjacency density vector -- the number of systems adjacent to i. C_ij - connectivity matrix -- representing presence or absence of an interconnect between i and j as a 1 or 0. C_ij does not represent a Markov process. P_ij - transition probability matrix -- probability that a packet, now in i will end up in j next. We have, A_i = Sum_j C_ij In making P_ij, i think it is necessary to calculate according to the number of interconnections of j -- how big the neighbour is. This looks right intuitively: if i is a smaller, local isp or an non-isp organization they will tend to have a few upstream providers and maybe some private peering. The upstreams will tend to be more heavily interconnected and peered and their component of A_i will be larger than that of the private peering, or more of your packets will go to an upstream than to your peers. The assumption may or may not be valid; it is difficult to know without actual traffic statistics for a good sample of links on the internet. If we had a close complete data set of traffic statistics for the internet measured at the same instant, it would be possible to calculate the P_ij directly: pps on link connecting i and j P_ij = -- total pps leaving i but this data is not available available in general. (aside: I belive that because of the scoping property of Little's Formula this approach would also be valid for analyzing packet flow within an AS where i and j represent each router indexed arbitrarily) Consider C_ij A_j P_ij = lambda_i -- Sum_k C_jk A_k Sum_k C_ij C_jk = lambda_i - Sum_k Sum_l C_jk C_kl where lambda_i is a normalizing factor appropriate to make the sums across each row of P_ij equal to 1. The product of C_ij with A_j is necessary since we don't want to take into account the adjacency density of ASj if we are not connected to it -- it doesn't matter how big it is, if i is not connected to j, a packet has zero chance of making the transition directly. This is taken care of by the fact that C_ij == 0 in that instance. Likewise the right inner product of C_jk with A_k in the denominator is necessary for the same reason, except now two hops out. Non existent links are never taken into account in calculating the transition probabilities. You might say that the numerator is skewed towards the current state, and the denominator is skewed towards the next state. This suggests that there is an implicitly imbedded Markov chain -- the denominator used in calculating the probability of going in one step from i to j takes into account information about what will happen after at the next step when it leaves j. -w -- William Waites [EMAIL PROTECTED] finger [EMAIL PROTECTED] for PGP keys Idiosyntactix Research Laboratories http://www.irl.styx.org -- NetBSD: ça marche!
Re: Vulnerbilities of Interconnection
Quite a few researchers have looked at the topology of AS interconnection. They have found that AS connectivity follows a power law - i.e. the vast majority have a few connections while a small minority has the majority of connections. Same as an earthquake - most are small and not noticable but a few are huge, smash a boulder and you get the same thing. Lots of dynamic networks follow this topology. The upside is that they are incredibly robust to random failures but very susceptible to targeted failures. For details see: http://www.physicsweb.org/article/world/14/7/09 - Original Message - From: Jared Mauch [EMAIL PROTECTED] Date: Friday, September 6, 2002 2:20 pm Subject: Re: Vulnerbilities of Interconnection On Fri, Sep 06, 2002 at 01:55:40PM -0400, batz wrote: On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: :would be difficult to reach. I'd have to run a model to be sure, but :every one of the major seven have rerouting methodologies that would :recover from the loss. And I don't think they exclusively peer at ASN's to fail, then see who is still connected, but we are still dealing with connectivity relatve to us and our peers, even 5+ AS-hops away. I would imagine this is one of the tasks CAIDA.org is probably working on, as it seems to fall within their mission. Coming up with the as interconnection data is actaully fairly easy if you parse route-views data. This obviously doesn't cover every possible interconnection that exists but it does provide a large swath of data to review for the interconnection postulation. Looking at that data, (this is an old snapshot) the top ten networks are: (in #10-#1 order) conn ASN + 161 3356 229 1 242 2914 248 209 274 6461 277 3561 295 3549 328 7018 484 701 493 1239 - Jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: IP address fee??
On Fri, 6 Sep 2002, Joe Abley wrote: How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. Well, maybe, if you define listening to people as reading what people write. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Actually, I would assume it to be the other way around: if you only communicate with people who are active in the field who are aware of all the new tricks, how are you going to learn about obsolete stuff? About classfulness: I think it's more relevant, even today, than many people like to admit. Why is it that I can type network 192.0.2.0 in my Cisco BGP config and the box knows what I'm talking about, but network 192.0.2.0/24 is no good? If it doesn't do anything else, at least IPv6 will get rid of this problem. Iljitsch van Beijnum
Re: IP address fee??
On Fri, 6 Sep 2002, Stephen Sprunk wrote: The point of communication is to get an idea across; if most of the people you communicate with don't understand slash notation, then you use terms they're familiar with even if they're imprecise or inaccurate. That is a very dangerous thing to say (or worse, do). Being inaccurate too often means it becomes impossible to be precise when you need to, because the terminology becomes ambigous after being used wrong all the time. That doesn't imply you should teach everyone who talks about a class C when they mean a /24 about CIDR and VLSM, but it's not much harder to say Your new class C sized address range is 96.112.30.0 - 96.112.30.255 rather than Your new class C net is 96.112.30.0 which is at least incorrect and maybe even ambigous (then what's the netmask?). I think NANOG's ISP-centric membership may skew the perception of our lexicon's state. Most network operators are not ISPs. Ok, if I connect to their network I'll remove ip subnet-zero and ip classless from my configs to revert to the defaults that still reflect the pre-1993 state of affairs, but if they want to connect to our network, they should play nice and follow the rules we use here. Iljitsch van Beijnum
RE: classless delegation [Re: IP address fee??]
Brad Knowles wrote: At 4:40 PM +0200 2002/09/06, Peter van Dijk wrote: It could be me but... SNIP o The reverse zone contains one or more A records The reverse domain 192.122.109.193.in-addr.arpa. contains one or more A records. A records should only be placed in forward-mapping domains. What A-records is it talking about? I am not seeing any. Yes, they get returned, whoo hoo: 8- jeroen@purgatory:~$ dig 192.122.109.193.in-addr.arpa any ; DiG 9.1.3rc3 192.122.109.193.in-addr.arpa any ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13829 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;192.122.109.193.in-addr.arpa. IN ANY ;; ANSWER SECTION: 192.122.109.193.in-addr.arpa. 66808 IN NS ns3.dataloss.nl. 192.122.109.193.in-addr.arpa. 66808 IN NS ns.dataloss.nl. ;; AUTHORITY SECTION: 192.122.109.193.in-addr.arpa. 66808 IN NS ns3.dataloss.nl. 192.122.109.193.in-addr.arpa. 66808 IN NS ns.dataloss.nl. ;; ADDITIONAL SECTION: ns.dataloss.nl. 239655 IN A 193.109.122.194 ns3.dataloss.nl.66855 IN A 193.109.122.215 ;; Query time: 22 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Sep 6 22:14:25 2002 ;; MSG SIZE rcvd: 152 -8 But isn't that normal for a zone?: Let's take seque.merit.edu (just picked a host from the message headers :) 8- jeroen@purgatory:~$ dig 41.1.108.198.in-addr.arpa. any ; DiG 9.1.3rc3 41.1.108.198.in-addr.arpa. any ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13553 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;41.1.108.198.in-addr.arpa. IN ANY ;; ANSWER SECTION: 41.1.108.198.in-addr.arpa. 172786 INPTR segue.merit.edu. ;; AUTHORITY SECTION: 1.108.198.in-addr.arpa. 172786 IN NS dns.merit.net. 1.108.198.in-addr.arpa. 172786 IN NS dns2.merit.net. 1.108.198.in-addr.arpa. 172786 IN NS dns3.merit.net. ;; ADDITIONAL SECTION: dns.merit.net. 172794 IN A 198.108.1.42 dns2.merit.net. 172794 IN A 198.109.36.3 dns3.merit.net. 172794 IN A 198.108.130.5 ;; Query time: 7 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Sep 6 22:17:55 2002 ;; MSG SIZE rcvd: 185 -8 Or any other IP you would randomly pick actually... show me one that doesn't have this behaviour :) What is so special about the reverse zones anyways? You must be one very stupid implementor if you where handling those zones differently than 'forward' zones... Nothing wrong with putting up something like: 60.1.0.10.in-addr.arpa. CNAME bla-reverse.example.org. bla-reverse.example.org. PTR bla.example.org. bla.example.org. A 10.0.1.60 What's wrong with that? No RFC against it ;) They are the ones associated with your NS records. At a procedural level, PTR records are mutually exclusive with SOA NS records. You are actually saying that one can't setup a DNS for a reverse host then ;) Cool, why does it work then? grin Btw... another 'cool' DNS tool: www. Greets, Jeroen
RE: IP address fee??
Richard A Steenbergen wrote: On Fri, Sep 06, 2002 at 11:41:07AM -0500, Stephen Sprunk wrote: I'd bet most of the customers I deal with learned networking from OS manuals or CCNA study books, all of which still teach classful addressing as the primary method. All of the ones I work with use the term C or class C to refer to a /24, and all are noticeably slower when dealing with non-/24 masks. Or even better... actual popquiz question*: What is the subnet mask of a class E? ;) Does anybody know that one ? Without looking into docs that is. Greets, Jeroen * = Seen in a pre-summer 2002 quiz at a Computer Science education in The Netherlands... And no the person teaching it didn't think he needed newer material than his 1980's sheets. So nopes, CIDR didn't exist for him and yes it's a false answer to say class E is pre-1992, we live in 2002.
RE: classless delegation [Re: IP address fee??]
Oops, SNIP Btw... another 'cool' DNS tool: www. http://www.foobar.tm/dns/ DNS Bajaj is a tool I made to help pinpoint errors when setting up nameservers for a domain. This is still a sort of proof of concept and the code is reflecting that. Someone asked what a bajaj is and how it should be pronounced . Think of DNS Bajaj as D N S By Eye. I hope this explains the stupid name. DNS Bajaj - What it is DNS Bajaj is a tool mainly for checking the delegation of a domain. As the name implies (or at least I hope so) it does this by making a graph of the interrelationships beteween all the nameservers involved in the managment of the domain and marking the servers that does funny stuff in a way that makes it easy to pinpoint them by sight - by eye if you want to. Greets, Jeroen
RE: Vulnerbilities of Interconnection
Okay, If we're going to go off the deep end here, how about the effect of a small yield air burst over $importantplace? Not designed to maximize casualties/damage but rather EMP? A large number of senior military officials got that 'deer-in-the-headlights' look a few decades back when a deserter supplied Soviet state of the art fighter turned out to have tube based electronics. :) It's not much of a stretch from crashing civilian airliners into high rises to firing for effect with nuclear weapons. Look at what's going on with Iraq right now. I know, but you're saying that's why the Internet was invented, to provide diverse communications even in a nuclear war. The Internet and its electronics and equipment was a much different animal when that flag was first run up the pole. I wonder if anyone has checked to see if anyone would salute today. Oh, wait, that's what this whole discussion is about, isn't it. ;) Best regards, _ Alan Rowland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tim Thorne Sent: Friday, September 06, 2002 12:58 PM To: [EMAIL PROTECTED] Subject: Re: Vulnerbilities of Interconnection [EMAIL PROTECTED] wrote: Lets bring this discussion to a some common ground - What kind of implact on the global internet would we see should we observe nearly simultaneous detonation of 500 kilogramms of high explosives at N of the major known interconnect facilities? OK, what if 60 Hudson, 25 Broadway, LinX and AmsIX were all put out of commission? What about the major sites terminating undersea cables in an effort to isolate the US? Or major satellite uplink points? Or all of them? -- Tim
Re: IP address fee??
On Friday, September 6, 2002, at 04:04 PM, Iljitsch van Beijnum wrote: On Fri, 6 Sep 2002, Joe Abley wrote: How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. Well, maybe, if you define listening to people as reading what people write. That too, in the context of written discussions, rather than books or manuals. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be taught long after it stopped having any relevance. Actually, I would assume it to be the other way around: if you only communicate with people who are active in the field who are aware of all the new tricks, how are you going to learn about obsolete stuff? I think there is often a directed graph of information flow for particular subjects. There will be nodes in the graph which correspond to people who have done research, and who speak with some accuracy. There are other nodes which listen selectively to the interpretations of others, derive rules of thumb and pass their filtered wisdom onto other nodes, but do no research from sources that might be considered authoritative. The effectiveness of this information-sharing network is hampered by the unreliability of individual nodes to filter information they receive, the inconsistent manner in which the information is processed, the near-complete absense of filters on information passed to other nodes, and the ad-hoc summarisation that happens throughout the network regardless of the intentions of the origin nodes. Sounds almost eerily familiar. Many ISPs provide a fertile learning environment for people who are able and willing to learn, regardless (in spite of!) of initial training and qualification. However, I seem to think that there are lots of people in organisations that run IP networks who don't have the opportunity to learn how to do lots of different things, and many of them don't have the time, ability or inclination to go research questions from the bottom up. Rules of thumb and networking myths abound in that environment. The people who are most able to appreciate finer technical points are also those who are most likely to get bored and go find a more interesting job somewhere else, etc, etc. ICMP is a security risk. You can't use the first and last subnets. Education is hard. Joe
RE: Vulnerbilities of Interconnection
*** REPLY SEPARATOR *** On 9/6/2002 at 1:42 PM Al Rowland wrote: Okay, If we're going to go off the deep end here, how about the effect of a small yield air burst over $importantplace? Not designed to maximize casualties/damage but rather EMP? A large number of senior military officials got that 'deer-in-the-headlights' look a few decades back when a deserter supplied Soviet state of the art fighter turned out to have tube based electronics. :) Said tube electronics were apparently more survivable against EMP effects. Or was that the point you were making? I think the real surprise was a toggle switch that Belenko said was supposed to be flipped only when told over the radio by higher headquarters. It changed the characteristics of the radar sort of a go to war mode vs. the standard training mode. An interesting, if not totally professional evaluation of something like this is in Steven Coonts book America where terrorists take over an American nuclear submarine armed with a new type of Tomahawk warhead - an EMP warhead. One of the early targets is AOL HQ in Reston, VA., (I almost cheered). Coonts has an inflated idea of what an outage there would do the the internet... but there is a lot of other stuff fairly nearby, isn't there? -- Jeff Shultz Network Support Technician Willamette Valley Internet 503-769-3331 (Stayton) 503-390-7000 (Salem) [EMAIL PROTECTED] ...most of us have as our claim to fame the ability to talk to inanimate objects and convince them they want to listen to us. -- Valdis Kletnieks in a.s.r
RE: classless delegation [Re: IP address fee??]
At 10:28 PM +0200 2002/09/06, Jeroen Massar wrote: Yes, they get returned, whoo hoo: 8- jeroen@purgatory:~$ dig 192.122.109.193.in-addr.arpa any That could just be your local caching nameserver. You need to ask his nameservers the same question: % dig @ns.dataloss.nl. 192.122.109.193.in-addr.arpa any ; DiG 9.2.1 @ns.dataloss.nl. 192.122.109.193.in-addr.arpa any ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 56202 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;192.122.109.193.in-addr.arpa. IN ANY ;; ANSWER SECTION: 192.122.109.193.in-addr.arpa. 2560 IN SOA ns.dataloss.nl. hostmaster.192.122.109.193.in-addr.arpa. 1031343156 16384 2048 1048576 2560 192.122.109.193.in-addr.arpa. 259200 IN NS ns.dataloss.nl. 192.122.109.193.in-addr.arpa. 259200 IN NS ns3.dataloss.nl. ;; ADDITIONAL SECTION: ns.dataloss.nl. 259200 IN A 193.109.122.194 ns3.dataloss.nl.86400 IN A 193.109.122.215 ;; Query time: 73 msec ;; SERVER: 193.109.122.194#53(ns.dataloss.nl.) ;; WHEN: Fri Sep 6 23:00:13 2002 ;; MSG SIZE rcvd: 171 Fortunately, in this case, we still get the same information. Or any other IP you would randomly pick actually... show me one that doesn't have this behaviour :) That's really more a factor of the nameserver which provides the answer -- did you ask their servers directly, or did you ask a local caching nameserver which could have answered some or all of that from cache? 60.1.0.10.in-addr.arpa. CNAME bla-reverse.example.org. bla-reverse.example.org. PTR bla.example.org. bla.example.org. A 10.0.1.60 What's wrong with that? No RFC against it ;) Are you sure about that? IIRC, the definitions of CNAME records and what they can point to are pretty strict. You are actually saying that one can't setup a DNS for a reverse host then ;) No, just saying that if you're going to do it, you should do it the proper way -- using RFC 2317. Cool, why does it work then? grin Just because something hasn't actually been made officially illegal doesn't mean that it's not a really bad idea. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
RE: Vulnerbilities of Interconnection
At 2:01 PM -0700 2002/09/06, Jeff Shultz wrote: Said tube electronics were apparently more survivable against EMP effects. Or was that the point you were making? I think the real surprise was a toggle switch that Belenko said was supposed to be flipped only when told over the radio by higher headquarters. It changed the characteristics of the radar sort of a go to war mode vs. the standard training mode. I wouldn't be too surprised. The Patriot has a clock problem, and can't be left turned on for an extended period of time. There are plenty of military systems everywhere in the world that have various operational issues that may not materially reduce their effectiveness in their official role, but which may make them less suitable for other roles. An interesting, if not totally professional evaluation of something like this is in Steven Coonts book America where terrorists take over an American nuclear submarine armed with a new type of Tomahawk warhead - an EMP warhead. One of the early targets is AOL HQ in Reston, VA., (I almost cheered). These things exist. I would be more concerned about drive-by attacks with HERF (High Energy Radio Frequency) guns, capable of generating an EMP field that can wipe out RAM on any computer device that is not suitably protected (Tempest shielding or being in a SCIF?). These things can be made relatively portable and undetectable until such time as they are turned on -- unlike nuclear devices that can be detected by Geiger counters, etc A drive-by with a van would be a lot easier to organize than hi-jacking a nuclear-equipped submarine. BTW, AOL headquarters is in Sterling, not Reston. It's not that far away, so I can understand why people not from that area would not be aware of the difference. Coonts has an inflated idea of what an outage there would do the the internet... but there is a lot of other stuff fairly nearby, isn't there? What do you mean by nearby? Do you count the TerraPOP? Do you count Langley? -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++)
RE: Vulnerbilities of Interconnection
*** REPLY SEPARATOR *** On 9/6/2002 at 11:26 PM Brad Knowles wrote: At 2:01 PM -0700 2002/09/06, Jeff Shultz wrote: Said tube electronics were apparently more survivable against EMP effects. Or was that the point you were making? I think the real surprise was a toggle switch that Belenko said was supposed to be flipped only when told over the radio by higher headquarters. It changed the characteristics of the radar sort of a go to war mode vs. the standard training mode. I wouldn't be too surprised. The Patriot has a clock problem, and can't be left turned on for an extended period of time. There are plenty of military systems everywhere in the world that have various operational issues that may not materially reduce their effectiveness in their official role, but which may make them less suitable for other roles. Actually I suspect it was an anti-jamming feature. Think about it the jammers would all be programmed based on the training mode, which presumably we would have heard before. All off the sudden this thing is broadcasting an entirely new signal... snip Coonts has an inflated idea of what an outage there would do the the internet... but there is a lot of other stuff fairly nearby, isn't there? What do you mean by nearby? Do you count the TerraPOP? Do you count Langley? I thought that MAE-East was somewhere around there? I know that there is a fair amount of high-tech in that particular area. I don't know how far away Langley itself is another target was basically The Mall where it took out a couple of fly-by-wire Airbuses. Interesting book from a techno-thriller standpoint. Just don't confuse it with reality.G -- Jeff Shultz Network Support Technician Willamette Valley Internet 503-769-3331 (Stayton) 503-390-7000 (Salem) [EMAIL PROTECTED] ...most of us have as our claim to fame the ability to talk to inanimate objects and convince them they want to listen to us. -- Valdis Kletnieks in a.s.r
Re: Vulnerbilities of Interconnection
On Fri, 06 Sep 2002 14:01:24 PDT, Jeff Shultz [EMAIL PROTECTED] said: Coonts has an inflated idea of what an outage there would do the the internet... but there is a lot of other stuff fairly nearby, isn't there? *You* know that a hit on 60 Hudson would probably be worse (especially considering all the OTHER stuff that would be in blast range). *I* know that. The rest of the NANOG readership knows that. However, the organization based in Reston probably has on the order of 1,500 times more subscribers than the NANOG list does... ;) ...most of us have as our claim to fame the ability to talk to inanimate objects and convince them they want to listen to us. -- Valdis Kletnieks in a.s.r Wow - I'm famous. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech msg05195/pgp0.pgp Description: PGP signature
Re: Vulnerbilities of Interconnection
On Fri, 6 Sep 2002 [EMAIL PROTECTED] wrote: On Fri, 06 Sep 2002 14:01:24 PDT, Jeff Shultz [EMAIL PROTECTED] said: Coonts has an inflated idea of what an outage there would do the the internet... but there is a lot of other stuff fairly nearby, isn't there? *You* know that a hit on 60 Hudson would probably be worse (especially considering all the OTHER stuff that would be in blast range). *I* know that. The rest of the NANOG readership knows that. We had examples of that on Sep 11th and it wasnt -that- bad... However, the organization based in Reston probably has on the order of 1,500 times more subscribers than the NANOG list does... ;) ...most of us have as our claim to fame the ability to talk to inanimate objects and convince them they want to listen to us. -- Valdis Kletnieks in a.s.r Wow - I'm famous. ;) famous or infamous? :) Steve
Re: IP address fee??
On Fri, 6 Sep 2002, Joe Abley wrote: Actually, I would assume it to be the other way around: if you only communicate with people who are active in the field who are aware of all the new tricks, how are you going to learn about obsolete stuff? I think there is often a directed graph of information flow for particular subjects. There will be nodes in the graph which correspond to people who have done research, and who speak with some accuracy. There are other nodes which listen selectively to the interpretations of others, derive rules of thumb and pass their filtered wisdom onto other nodes, but do no research from sources that might be considered authoritative. The trouble with authorative sources is that they may deliver high quality data, but usually not very much of it. You can't build and operate a network using only scientific facts. You also need experience, rules of thumb, and common sense. And it never ceases to amaze me how researches carefully remove all interesting variables until they arrive at data that while being incredibly accurate, has no longer any meaning in the real world. The effectiveness of this information-sharing network is hampered by the unreliability of individual nodes to filter information they receive, the inconsistent manner in which the information is processed, the near-complete absense of filters on information passed to other nodes, and the ad-hoc summarisation that happens throughout the network regardless of the intentions of the origin nodes. Sounds almost eerily familiar. Yes, it sound a lot like Usenet when the S/N ratio was still not much worse than that of NANOG. While each and every fact posted on Usenet is completely unreliable, entire discussions more often than not help you a good deal into the direction of a usable answer. Many ISPs provide a fertile learning environment for people who are able and willing to learn, regardless (in spite of!) of initial training and qualification. I wonder if they still do. However, I seem to think that there are lots of people in organisations that run IP networks who don't have the opportunity to learn how to do lots of different things, and many of them don't have the time, ability or inclination to go research questions from the bottom up. Rules of thumb and networking myths abound in that environment. Still, in this day and age anyone who remains ignorant for a significant period of time has only him/herself to blame. If information isn't available on the web in the first place, you can order books on subjects they don't even know how to spell at your local bookstore. (For instance, there are more than 4300 books on computer networking on Amazon.) ICMP is a security risk. You can't use the first and last subnets. You can't get more than 50% throughput on shared ethernet. Iljitsch
NSA's recommendation for classfull routing (was Re: IP address fee??)
On Fri, 6 Sep 2002, Iljitsch van Beijnum wrote: Ok, if I connect to their network I'll remove ip subnet-zero and ip classless from my configs to revert to the defaults that still reflect the pre-1993 state of affairs, but if they want to connect to our network, they should play nice and follow the rules we use here. The National Security Agency has issued the following principles and guidance for security configuration of IP routers, with detailed instructions for Cisco System routers. A brief passage from the document: By default, a Cisco router will make an attempt to route almost any IP packet. If a packet arrives addressed to a subnet of a network that has no default network route, then IOS will, with IP classless routing, forward the packet along the best available route to a supernet of the addressed subnet. This feature is often not needed. On routers where IP classless routing is not needed, disable it as shown below. Central# config t Enter configuration commands, one per line. End with CNTL/Z. Central(config)# no ip classless Central(config)# exit http://nsa2.www.conxion.com/cisco/download.htm Geez, people are worried about the NSA tapping the Internet. How about worrying the NSA connecting misconfigured routers to the Internet? Yes, even the NSA has bad network days. They just don't like to talk about it.
Re: Vulnerbilities of Interconnection
Actually damage to the net could be done with relative ease. If you wanted to do some planning and a little staging work you could affect large amounts of traffic. Given recent press about large carriers moving their interconnects to a well known IX type company, all you would have to do is place some 7206VXR's (VXR == Very eXplosive Routers) in these co-lo's. Or servers, 5U server Nice and big. I wonder how much damage a couple of slots in a router full of Semtex would do. Then do that in multiple co-lo and use a IP packet as a trigger to pop them all. Don't forget the spare parts depots as well. PS: All the money people spend on physical stuff to keep those on the outside out, would only help over pressure and other things on the inside. The issue is that Free Market places are going to do only as much as is needed to turn a profit, and not a penny more. This isn't the 60's or the 70's when ATT ran the infrastructure and had bunkers around the nation On Fri, Sep 06, 2002 at 05:41:29PM -0400, [EMAIL PROTECTED] wrote: On Fri, 06 Sep 2002 14:01:24 PDT, Jeff Shultz [EMAIL PROTECTED] said: Coonts has an inflated idea of what an outage there would do the the internet... but there is a lot of other stuff fairly nearby, isn't there? *You* know that a hit on 60 Hudson would probably be worse (especially considering all the OTHER stuff that would be in blast range). *I* know that. The rest of the NANOG readership knows that. However, the organization based in Reston probably has on the order of 1,500 times more subscribers than the NANOG list does... ;) ...most of us have as our claim to fame the ability to talk to inanimate objects and convince them they want to listen to us. -- Valdis Kletnieks in a.s.r Wow - I'm famous. ;) -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
Console Servers
Hi, It's been a while since I last saw this thread... I'm looking at a few listed below and looking for comments: Lantronix - http://www.lantronix.com/products/cs/scs820_scs1620/index.html Looks good, can't find a price on Ingram. Cyclades - http://www.cyclades.com/products/ts_series.php Looks to run about $2100 for 16 ports Digi - http://www.digi.com/solutions/devtermsrv/cm/index.shtml Looks to run about $1800 for 16 ports All of the above do sshv2, and that's a requirement. I haven't found much else. For the time being I'm ruling out old stuff like a Portmaster or Xylogics. I'd also appreciate pointers to any roll your own parts, esp. IDE - Flash adapters and multiport serial cards that will work with FreeBSD. I can summarize to keep the noise down... Thanks, Charles -- Charles Sprickman [EMAIL PROTECTED]
Re: NSA's recommendation for classfull routing (was Re: IP addressfee??)
Not that it will more people the trouble of sending me more messages, but yes I'm aware the NSA guide states: The goal for this guide is a simple one: improve the security provided by routers on US Department of Defense (DoD) operational networks. Inside the DoD, they may want to only use classful routing. The recommendation may be valid for that environment. Unfortunately, some security firms and organizations have taken the NSA guide as a rulebook. I've seen a lot of security checklists copied directly from the NSA Router Security and Configuration Guide. Even worse, I've seen very expensive security vulnerability reports recommending clients change their routers based on the NSA guide, such as turning off ip classless. If you are building a network in the outside of the DoD some of the NSA recommendations should *NOT* be followed.
Re: Console Servers
I just went through this exercise. In POP a) where space is a premium, I
bought a 8 port RocketPort PCI serial card to sit in the FreeBSD firewall
that was there. ebay $50 and made the rj-11 to {rj-45|db9} cables in house
(connections to other PCs and cisco gear).
In POP b) where space is not a problem, a PM2 with an existing FreeBSD box
in front of it which we can SSH into, and then telnet to the individual
serial ports.
Have a look on ebay for Livingston PM2s. About $150-$200 US for upto 30
serial ports. At under $200, buy and extra one for your cold standby
spare. Then, put a surplus PC in front of it (or an existing one) from
where you can SSH from. On the PM2 just for the archives,
set s1 device /dev/network
set s1 service_device netdata 6001
set s1 override xon off
set s1 modem off
save s1
reset s1
where 6001 is the port you would telnet to in order to get the serial
session. These are about 4U, so you will require space to spare.
---Mike
At 06:42 PM 9/6/2002 -0400, Charles Sprickman wrote:
Hi,
It's been a while since I last saw this thread...
I'm looking at a few listed below and looking for comments:
Lantronix - http://www.lantronix.com/products/cs/scs820_scs1620/index.html
Looks good, can't find a price on Ingram.
Cyclades - http://www.cyclades.com/products/ts_series.php
Looks to run about $2100 for 16 ports
Digi - http://www.digi.com/solutions/devtermsrv/cm/index.shtml
Looks to run about $1800 for 16 ports
All of the above do sshv2, and that's a requirement. I haven't found much
else. For the time being I'm ruling out old stuff like a Portmaster or
Xylogics.
I'd also appreciate pointers to any roll your own parts, esp. IDE -
Flash adapters and multiport serial cards that will work with FreeBSD.
I can summarize to keep the noise down...
Thanks,
Charles
--
Charles Sprickman
[EMAIL PROTECTED]
Mike Tancsa, tel +1 519 651 3400
Sentex Communications,[EMAIL PROTECTED]
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike
Re: NSA's recommendation for classfull routing (was Re: IP address fee??)
Not that it will more people the trouble of sending me more messages, but yes I'm aware the NSA guide states: The goal for this guide is a simple one: improve the security provided by routers on US Department of Defense (DoD) operational networks. Inside the DoD, they may want to only use classful routing. The recommendation may be valid for that environment. Highly unlikely. From what experience I have w/ DOD networks a lot of them tend to be early large allocations (whole class B's or even a class A or two) that have since been subnetted - a lot. If you peruse the allocation lists as far as who has what I believe that you'll that there are a lot of large classfull delegations to DOD networks, and not near as many class C blocks. Turning off ip classless in any of the enviroments I've seen would be nothing short of catastrophic. OTOH having lived through several so called security audits, I can certainly believe that this would be on one of the checklists. Note: I've intentionally used classful notation, not because I'm an idiot (although I'm always open to that possibility :), but because it represents the historical aspects of these allocations. Unfortunately, some security firms and organizations have taken the NSA guide as a rulebook. I've seen a lot of security checklists copied directly from the NSA Router Security and Configuration Guide. Even worse, I've seen very expensive security vulnerability reports recommending clients change their routers based on the NSA guide, such as turning off ip classless. If you are building a network in the outside of the DoD some of the NSA recommendations should *NOT* be followed. -- -=-=-=-=-=-=--=-=-=-=-=--=-=-=-=-=--=-=-=-=-=--=-=-=-=-=-=- Ryan Mooney [EMAIL PROTECTED] -=-=-=-=-=-=--=-=-=-=-=--=-=-=-=-=--=-=-=-=-=--=-=-=-=-=-=-
Re: Estimating Transition Probabilities
Apologies for replying to myself. I wrote: ww C_ij A_j ww P_ij = lambda_i -- ww Sum_k C_jk A_k The first factor in the sum in should be C_ik, not C_jk. There is no imbedded chain, nor skew in the equation. There was skew in my reasoning. ;) It also means that lambda_i == 1 -- it is already normalized. -- William Waites [EMAIL PROTECTED] finger [EMAIL PROTECTED] for PGP keys Idiosyntactix Research Laboratories http://www.irl.styx.org
