After reading through their site, I found no real details of what they are claiming.
They claim 20 mile connections: OK, I can believe that, since I have some running at 26 miles. A guy in British Columbia has some connections running nearly 50 miles. Nothing new here.
Their product acts as a "repeater" from the customer premise: Again, nothing new here. Nokia has a reasonably well designed product called RoofTop that also works at 2mbps.
I would be curious to see how they are addressing the issue of spectrum re-use, since 802.11b only has 3 clear channels to operate on. In a haphazard deployment using customer premise equipment to repeat, RF collision is terrible. What happens during a power outage in a neighborhood? Does the whole area drop out, or is the homeowner required to provide UPS? What happens when the unthinkable happens, and a key repeater/customer terminates his service, and that repeater has to come off the house?
Much of your document retention policy must be based on the Statutes of your area. In many cases, documents are required to be kept for 2-7+ years as a record of business. For example, if memory serves, Ontario requires documents be kept for 7 years. Nevada requires 2 years for civil matters, and 4 years for contract law (most corporate documents).
While it may seem a good idea to delete email after but a few weeks, the record of your conversations can be a lifesaver in contract disputes, where verbal or emailed agreements outside of the contract documents are considered part of the contract. Depending on the court, and jurisdiction, email can be given the same weight as facsimile conversations.
Standard, which is the enumeration 0, 1, 2 and produces numbers such as 122101 and 202210
Balanced, which uses -1, 0, 1 as its notation, and is much easier to work with by humans. It produces numbers such as 10101 (note the BOLD should actually be a superline above the '1' for negative notation) and 11001
Many are beginning to discredit the detection of steganographic images in the wild without learning the actual methods of detection!
While it is very easy to change an algorithm by byte offset, this is NOT the method of detection being used.
The method of detection exploits the characteristics of the JPEG compression algorithm to detect non-naturally occuring deviations in the image file. An example of this would be the gamma balance which is averaged over a certain number of pixels. In order to "hide" a change to a single bit, another bit would need to be inversely modified such that the balance of the image remains within or close to natural balance.
ALR VEISA 433 - The hard disk died on it years ago, but it runs as a TV-SVGA converter so I can watch DVDs on the projector from the office. Right now it boots off of a 360KB 5-1/4" Floppy to MS-DOS 6.0 and auto-runs the TSR.
VLB - This is my pride and joy:
486 DX 50 MHz (NOT dx2, DX!)
VLB runs at 50 MHz native as opposed to 33 MHz on DX2 and DX4 systems
40 MB, 70ns, 30 pin SIMMS
Promise Ultra IDE controller with 16MB disk cache onboard
ATI VGAWonderXL (with the passthru header)
The VLB system still runs as a netware print server, happily chugging away after ~7 years.
The limits here in the US is 1 watt ERP. With the antenna they are showing in the articule, (I use the same one) and using the Orinoco Silver card, (I use the Gold card) they are illegal with that set up.
Actually, for point to point links, the maximum EIRP is 48dbm (total system power), but you must reduce output power by 3db for each 6db added with antenna.
For normal point to multipoint, the EIRP is 36dbm (4W total system power) but the power output of the radio/amplifier cannot exceed 1W (30db).
Breaking into the gateway box is no different than breaking into a class5 switch - it takes an individual with drive, motive and skillset. I would much prefer the hands-on security available with VOCAL than using a nortel or lucent voice switch which utilize the old "security through obscurity" principle. With a decent Intrusion Detection system in place, and a well implemented firewall, the chances of having the gateway box compromised is much lower than a telco switch.
As for being "clipped" along the way, the most vulnerable point is from the client to the first ISP as this is likely to involve cable modem or dialup which is not extremely difficult to arrange.
With regards to the wires of an ISP - I agree that it can be sniffed, but not with the ease you suggest. How many people do you know that can de-frame a DS1 and pull the IP traffic out of it inline? How many have access to the equipment necessary to strip the shielding off of the exact fibre cable, create a macrobend and have the protocol analyzer to dump the reflected impulses to ATM then to IP?
The point is not that it cannot be broken into, but that it is more difficult and takes a different skillset than the trusty alligator clip method.
It would be great if there was encryption built into the standard, but what policy do you use when completing calls? Calls without encryption get dropped? That's a PR nightmare for any company doing that. Linking up the call as unencrypted? even worse. Should a voice prompt notify the caller that it will be unencrypted? That will start FUD how much the phone company knows yet people like to remain ignorant of.
There is no simple answer to any of this - but VOCAL is a good step in the right direction since we can take the code, and add encryption to it or improve on the standards.
The tolerence on voice communication is much better than command line interfaces. International call latency can often be in the 300-500ms range, with a poor call being even higher latency.
If you can hit 200ms latency with Voice over IP, then the average person cannot tell the difference between that and a normal local or national call. Obviously a call sounds much better if latency is under 100ms - but in most cases it is not possible from end-user to end-user.
Security is the art of making the goal more expensive to reach than its value. Although those with access to backbone routers can reroute traffic easily through a sniffer or utilize a mirror port, most of the population does not have access to be able to sniff traffic beyond their first upstream router.
Compared to the existing phone system where any preteen with alligator clips can listen in on a phone call it now takes a person with considerable experience, who would be jeopardizing a successful career to listen in on the calls.
On the other hand, we could all just live our lives as if we were always being watched and listened to all the time..... oh wait, we already are.
While I appreciate the authors intent to attempt a fair comparison and evaluation of 802.11 wireless radio transmission speeds compared to manufacturer specifications, there are a number of serious errors in the method of testing and subsequent conclusions.
First let me express my bias: I do not believe that the 802.11b standard utilizing Direct Sequence Spread Spectrum (DSSS) technology suits mobile or last-mile usage. Ideally this technology suits point to point (PtP) or as a controlled point to multipoint (PtMP) involving less than an half dozen receivers. Now taken with a grain of salt, let us continue.
1. There is no baseline.
There are many variables involved in the transmission of data between two computers, and while the author made a valid attempt to remove some by eliminating disk I/O operations, interface delays (PCMCIA/Cardbus), protocol overheads (802.11b, 802.2, TCP), and signal quality (retransmissions/bad packets) were ignored. The simple addition of a test utilizing 10baseT PCMCIA cards and running the same test would have accounted for the TCP and 802.2 overheads, leaving only the 802.11b (wireless) protocol and retransmissions as variables which is what he was testing for.
2. Method of comparision flawed. Assuming that a 1Mbit radio link will provide 1,048,576 bytes/second is incorrect. The 1Mbit number refers to the maximum RADIO speed possible, not throughput that could be seen. The transmission process tested was SSH --> O/S --> TCP/IP --> Ethernet --> Wireless and reversed on the receiving side. Since this computer is probably used day to day with 100baseT ethernet and sees higher transmission rates than 4Mbit for this comparision it can be ignored in the lack of a valid baseline (see #1 above). SSH encapsulates the raw data provided with its own headers, TCP/IP adds packet headers, Ethernet adds MAC headers, and Wireless adds 802.11b headers. Depending on the packet size being utilized by the SSH implementations, this overhead can result in a packet overhead of 20% to 60%. In this case based on the times published, it is probably in the 20-30% range.
After deploying a real network supporting 10,000 desktops in 16 communities I can safely say that DSSS technology is being deployed and used incorrectly as it is not well suited to either office mobile, last-mile or roaming mobile deployments. The large overheads involved in the 802.11b protocol reduce actual throughput and the congestion that results from colocating cells in unacceptable outside of a small office or home environment.
The industry as a whole needs to take a hard look without the spin created by the large manufacturers pushing their own products at the true capabilities of both DSSS and FHSS technologies. DSSS has an excellent application in providing network backbone, and high-rate point-to-point communication it is not suited for outdoor point-to-multipoint deployment or in-office roaming between access points, let alone mobile roaming like a cell phone. Frequency Hopping technologies should be deployed in the busy office, are perfectly suited for outdoor deployment, are extremely resistant to interference and support high-speed roaming between cells at 60 mph for in-vehicle applications that will start to appear shortly.
Use UUNet as a backbone, and you're just fine. Plus, you don't have to go through that HORRIBLE teleglobe bottleneck in montreal to get anywhere. Pure backbone sailing to the world!
On another note, since commercial interests took over designing the internet after DARPA, they have introduced a TELCO MODEL of deployment. Ever noticed that every packet that goes out-of-network happens to go through 1 of 5 NAPs in North America? Yes, there are backup lines, but with the NAPs down networks will not talk nicely.
The internet has been designed by a group of TELCO engineers who plan only for minor outages, not global failures. The only way to manage a MAJOR failure is to peer in every area that backbones overlap... this would mean approximately 3000 new "peering" points in North America - something no network engineer wants the headache of (just thing of the routes to publish).
When growing your network, peer well & peer often.
When organized properly, wireless lans are NOT like party lines.
It is possible to plan a network to maximize bandwidth to the customer without getting into cable-modem style problems.
Look at the cellular carriers - they usually have less than 10MHz of bandwidth in any given area, but use time division and code division to make sure every phone has enough bandwidth for the call..... they aren't perfect, but their call drop rate is less than 1/1000 on average now.
In an improperly configured wireless network, yes it is possible to eavesdrop. But so can your home telephone line with an op-amp tool (the ones the bell guys carry). So can your cordless phone.
When a wireless network is properly planned, there are 3, sometimes 4 or 5 layers of network security:
1. In freqency hopping systems, there are 78 hopping patterns. Only one will "sniff" the packets in the correct order.
2. ESSID. This is the network security password. Access Points will only respond to radios with correct ESSIDs.
3. WEP. Wireless Equivelency Protocol. This is 40, 56 or 128 bit encryption that encrypts all communication on the radio.
4. Direct AP connection to router/firewall. This stops any extraneous traffic from flowing over the WLAN.
5. VPN Encryption. Many ISPs are using VPN from customer premise gear to the router, which makes sniffing wireless more difficult than wireline, since there are 4 extra layers of security.
---
No security will ever be perfect, but then again, most people using wireless lans are using them for internet access which is inherently PUBLIC anyways.
The coalition that will be deploying the network includes a large amount of wireless deployment as well. Being a large rural province, there is no possible way that $300 million would cover fibre deployment to every government office and school.
My guess is that they will run fibre to each town, probably in conjunction with the local power company (dark fibre), and use wireless to link all the offices to a central POP.
================================================ Notice that the IP of each MASQ box is identical to the opposing L2TP Router.
Each MASQ box must have PORT FORWARDING enabled with the GRE/ESP patch to the Linux Kernal to enable IPCHAINS passthrough and proper forwarding.
Each MASQ box must have either 2 way MASQerading running or a combination of global IP's (headache time) that allow the packets to change origin at destination.
L2TP1 initiates a connection to 192.168.0.1, which is then forwarded by MASQ1 to MASQ2 on port 500, utilizing GRE/ESP packet encoding. MASQ2 is set to forward internally these packets to L2TP2 on it's internal network, with the "originating" system appearing to be the local MASQ2 system, which, by design has the same IP as the original L2TP system.
Now, this is an incredible waste of time, since you completely wreck the ability of L2TP to support multiple connections.... but it is POSSIBLE!
Cheers (and I appologize for the headaches if you try to make this work)
Although you cannot get *MORE* than 56k out of it, you can get a pure 33.6-56k to your local lan by just "faking" an ISP connection.
If you take a phone cord, put it between the 2 modems, then make the dreamcast dial any number (as long as it doesn't do dial-tone detection).
Then on the other side, force an answer by entering "ATA", then the modems will handshake and all will be well.
Hope this works on dreamcast.... I sure worked well for transferring files between a PC and an AMIGA, although the AMIGA only had a 1200 baud modem and it was sloooooooooow.
I would have to disagree with you, but for entirely different reasons:
Although most ISPs are happy to "flood the spectrum with enough RF to bake a potato at 500 yards", there are some who are approaching it with a more cautious and thoughtful approach, utilizing passive receive amplifiers rather than transmit amplifiers; using directional antennas to eliminate radiated interference and sectored antennas to allow maximum coverage. Not everyone is tilting OMNIs from the top of a building to reach a customer below (although some do think that UFO's need bandwidth too:-).
Although the band will get chewed up by the abusers, the rest of us will continue to plan our networks, and continue to run long after the has-been ISPs are gone or have switched vendors yet again.
The 2.4GHz spectrum band is "unlicenced", and more commonly known as ISM (Industrial, Scientific, Medical) band.
It spans a frequency range of 2.4350 - 2.4850 GHz, which is broken down into 78 channels.
There are two types of Spread Spectrum technologies in use: DSSS & FHSS (Direct Sequence Spread Spectrum & Frequency Hopping Spread Spectrum).
DSSS uses 26 of the available frequency channels for its transfer signal, this is a contiguous block, and is very sensitive to any interference.
DSSS specifications call for 11 possible channels, overlapping, with only 3 non-overlapping channels. (this means it is only possible to co-exist 3 seperate DSSS networks/devices)
Under US/FCC regulations, the full spectrum may be used, so 3 DSSS networks will co-exist, or up to 26 FHSS (in practice, 15 more realistic).
Under Canadian/IC regulations, only 1/3 of the spectrum may be used, so only 1 DSSS network is allowed, with only 1 possible channel, while FHSS will allow 8-10 networks)
The FHSS network standard is 802.11, which is officially 2Mbit/s, but some venders have proprietary 3Mbit/s rates available.
The DSSS network standard is 802.11hr, which is officially 11Mbit/s.
In Canada/USA, the maximum power output at your antenna is +36dBm ERP (Effective Radiated Power).
In Europe, the maximum power output is only +20dBm.
In my experience to date,
FHSS systems will consistently with up to 97% signal loss, while DSSS will work up to 30-40% signal loss.
When co-existing FHSS & DSSS, the frequency hopper will run nicely 2-3Mbit, while the direct sequence radio will drop from 11Mbit to 1Mbit with 50% "interference".
My longest Links to date(FHSS): .....13.2km @ 1Mbit/s .....10.1km @ 2Mbit/s .....6.7km @ 3Mbit/s
If anyone else has longest link or interference stats, please post them.
It really just comes down to what pattern-matching algorithms they use to detect an entry. In most cases the network is probed first, usually between a specific time on a repeating basis (between classes, after work, weekends, etc). Next a would-be cracker must find an exploit, this would usually involve determining characteristics of a specific point of entry - a single server, discovering the software version, patch level, security updates, etc. Then comes the entry to the system, and following what is done afterwards.
Unless you have an extremely patient cracker, with foreknowledge of the layout, it would be almost impossible to not leave traces in the logs.
I am guessing you could use a modified version of the psychiatric profiling software many law enforcement branches use, since they also look for a needle-in-a-haystack comparison between dissimilar crimes (dissimiler origin IP addresses)
Currently, I am on one of the smallest providers in the area (Fido/Microcell) which is a GSM provider in Canada. Coverage only exists in metro areas, but I was amazed at how well I could roam to other providers.
I did a road trip 4 weeks ago from Ontario to Florida, and was only out of signal for 1 hour out of 24, never had a problem receiving calls, voice mail worked perfectly, and the charges weren't all that bad.
While it would be nice to be on a full coverage network, it roams so well, who cares?
Between Intel & AMD we have: Socket7 Super7 (100Mhz) Socket 370 Socket ??? (100 & 133Mhz Coppermine) Slot 1 Slot 2 (SECC2) Slot A
With all these different "standards" for putting the processor onto the motherboard, how long will it be before the processors are just stamped onto the motherboard?
We're at the point now, where any processor upgrade requires a new motherboard (either for FSB speed, or connector type, or chassis type). If you buy early and expect to upgrade, Intel changes the rules, if you buy later, your upgrade choices are less than 100Mhz different because the clock multiplyer won't go that high. And of course, everything else under the sun has been integrated onto some motherboards (Video, Sound, Modem, Ethernet, Serial, Parallel, USB, IDE, FDC)
This industry is rapidly moving just like the Automotive industry did about 10 years ago. The trend moved from a car that could be 'tinkered' with in the driveway to eke out more horsepower or gas mileage, to cars that should never be touched by a hobbyist without expensive diagnostic equipment.
The days of tinkering are numbered, and I for one am disappointed.
As I said, it's been a while since I took finite... it's starting to come back, though.
Using all lower case is bad, but restricting the sample space to 4.5 million still makes it easier for a brute-force passcrack than leaving it alone.
The real question is: How far out of our way should we go to protect low-access user accounts? The amount of information given to a would be cracker by having a default policy reduces the amount of time he has to spend by 1/3! If anything, that would make the server more inviting.
Again, it's all just a matter of how you look at the problem.
Adding in those two requirements greatly enlarges the potential pool of passwords. Even if you assume only numbers will be used in addition to letters and not all the punctuation marks, you're still increasing your password base by several orders of magnitude.
I would have to disagree.
Forcing the use of both upper and lower case letters actually restricts the possible combinations by at least half!
(Disclaimer: this is all based on an OAC finite math course i took a few years back)
Let's assume 4 character passwords, because the math is simpler:
Total number of possible passwords (26 LC, 26 UC, 10 #) = 62^4 = 14776336 total passwords.
because of the need to have at least ONE non-letter, the following is now true
= 62*62*62*10 = 2383280
We just ELIMINATED 12 MILLION possible passwords!
Now, since one letter MUST be opposite case (and not a number) we are at:
= 62*62*26*10 = 999440
Well, there goes another 1.3 MILLION passwords!
Out of 14 MILLION passwords, there are now only 1 MILLION acceptable passwords based on the critera.
Now, on longer passwords, the effect of these constraints should be proportionally less.
Slashdot Mirror
After reading through their site, I found no real details of what they are claiming.
They claim 20 mile connections: OK, I can believe that, since I have some running at 26 miles. A guy in British Columbia has some connections running nearly 50 miles. Nothing new here.
Their product acts as a "repeater" from the customer premise: Again, nothing new here. Nokia has a reasonably well designed product called RoofTop that also works at 2mbps.
I would be curious to see how they are addressing the issue of spectrum re-use, since 802.11b only has 3 clear channels to operate on. In a haphazard deployment using customer premise equipment to repeat, RF collision is terrible. What happens during a power outage in a neighborhood? Does the whole area drop out, or is the homeowner required to provide UPS? What happens when the unthinkable happens, and a key repeater/customer terminates his service, and that repeater has to come off the house?
So many questions, so few answers
Much of your document retention policy must be based on the Statutes of your area. In many cases, documents are required to be kept for 2-7+ years as a record of business. For example, if memory serves, Ontario requires documents be kept for 7 years. Nevada requires 2 years for civil matters, and 4 years for contract law (most corporate documents).
While it may seem a good idea to delete email after but a few weeks, the record of your conversations can be a lifesaver in contract disputes, where verbal or emailed agreements outside of the contract documents are considered part of the contract. Depending on the court, and jurisdiction, email can be given the same weight as facsimile conversations.
GetRight uses multiple sites to download from and then pieces them back together.
http://www.getright.com
For example: 1010
= [(-1) * 27] + [0 * 9] + [1 * 3] + [0 * 1] OR
= [(-1) * 3^3] + [0 * 3^2] + [1 * 3^1] + [0 * 3^0]
= [-27] + [0] + [3] + [0]
= -24
Many are beginning to discredit the detection of steganographic images in the wild without learning the actual methods of detection!
While it is very easy to change an algorithm by byte offset, this is NOT the method of detection being used.
The method of detection exploits the characteristics of the JPEG compression algorithm to detect non-naturally occuring deviations in the image file. An example of this would be the gamma balance which is averaged over a certain number of pixels. In order to "hide" a change to a single bit, another bit would need to be inversely modified such that the balance of the image remains within or close to natural balance.
The VLB system still runs as a netware print server, happily chugging away after ~7 years.
The limits here in the US is 1 watt ERP. With the antenna they are showing in the articule, (I use the same one) and using the Orinoco Silver card, (I use the Gold card) they are illegal with that set up.
Actually, for point to point links, the maximum EIRP is 48dbm (total system power), but you must reduce output power by 3db for each 6db added with antenna.
For normal point to multipoint, the EIRP is 36dbm (4W total system power) but the power output of the radio/amplifier cannot exceed 1W (30db).
Breaking into the gateway box is no different than breaking into a class5 switch - it takes an individual with drive, motive and skillset. I would much prefer the hands-on security available with VOCAL than using a nortel or lucent voice switch which utilize the old "security through obscurity" principle. With a decent Intrusion Detection system in place, and a well implemented firewall, the chances of having the gateway box compromised is much lower than a telco switch.
As for being "clipped" along the way, the most vulnerable point is from the client to the first ISP as this is likely to involve cable modem or dialup which is not extremely difficult to arrange.
With regards to the wires of an ISP - I agree that it can be sniffed, but not with the ease you suggest. How many people do you know that can de-frame a DS1 and pull the IP traffic out of it inline? How many have access to the equipment necessary to strip the shielding off of the exact fibre cable, create a macrobend and have the protocol analyzer to dump the reflected impulses to ATM then to IP?
The point is not that it cannot be broken into, but that it is more difficult and takes a different skillset than the trusty alligator clip method.
It would be great if there was encryption built into the standard, but what policy do you use when completing calls? Calls without encryption get dropped? That's a PR nightmare for any company doing that. Linking up the call as unencrypted? even worse. Should a voice prompt notify the caller that it will be unencrypted? That will start FUD how much the phone company knows yet people like to remain ignorant of.
There is no simple answer to any of this - but VOCAL is a good step in the right direction since we can take the code, and add encryption to it or improve on the standards.
The tolerence on voice communication is much better than command line interfaces. International call latency can often be in the 300-500ms range, with a poor call being even higher latency.
..... oh wait, we already are.
If you can hit 200ms latency with Voice over IP, then the average person cannot tell the difference between that and a normal local or national call. Obviously a call sounds much better if latency is under 100ms - but in most cases it is not possible from end-user to end-user.
Security is the art of making the goal more expensive to reach than its value. Although those with access to backbone routers can reroute traffic easily through a sniffer or utilize a mirror port, most of the population does not have access to be able to sniff traffic beyond their first upstream router.
Compared to the existing phone system where any preteen with alligator clips can listen in on a phone call it now takes a person with considerable experience, who would be jeopardizing a successful career to listen in on the calls.
On the other hand, we could all just live our lives as if we were always being watched and listened to all the time
While I appreciate the authors intent to attempt a fair comparison and evaluation of 802.11 wireless radio transmission speeds compared to manufacturer specifications, there are a number of serious errors in the method of testing and subsequent conclusions.
First let me express my bias: I do not believe that the 802.11b standard utilizing Direct Sequence Spread Spectrum (DSSS) technology suits mobile or last-mile usage. Ideally this technology suits point to point (PtP) or as a controlled point to multipoint (PtMP) involving less than an half dozen receivers. Now taken with a grain of salt, let us continue.
1. There is no baseline.
There are many variables involved in the transmission of data between two computers, and while the author made a valid attempt to remove some by eliminating disk I/O operations, interface delays (PCMCIA/Cardbus), protocol overheads (802.11b, 802.2, TCP), and signal quality (retransmissions/bad packets) were ignored. The simple addition of a test utilizing 10baseT PCMCIA cards and running the same test would have accounted for the TCP and 802.2 overheads, leaving only the 802.11b (wireless) protocol and retransmissions as variables which is what he was testing for.
2. Method of comparision flawed. Assuming that a 1Mbit radio link will provide 1,048,576 bytes/second is incorrect. The 1Mbit number refers to the maximum RADIO speed possible, not throughput that could be seen. The transmission process tested was SSH --> O/S --> TCP/IP --> Ethernet --> Wireless and reversed on the receiving side. Since this computer is probably used day to day with 100baseT ethernet and sees higher transmission rates than 4Mbit for this comparision it can be ignored in the lack of a valid baseline (see #1 above). SSH encapsulates the raw data provided with its own headers, TCP/IP adds packet headers, Ethernet adds MAC headers, and Wireless adds 802.11b headers. Depending on the packet size being utilized by the SSH implementations, this overhead can result in a packet overhead of 20% to 60%. In this case based on the times published, it is probably in the 20-30% range.
After deploying a real network supporting 10,000 desktops in 16 communities I can safely say that DSSS technology is being deployed and used incorrectly as it is not well suited to either office mobile, last-mile or roaming mobile deployments. The large overheads involved in the 802.11b protocol reduce actual throughput and the congestion that results from colocating cells in unacceptable outside of a small office or home environment.
The industry as a whole needs to take a hard look without the spin created by the large manufacturers pushing their own products at the true capabilities of both DSSS and FHSS technologies. DSSS has an excellent application in providing network backbone, and high-rate point-to-point communication it is not suited for outdoor point-to-multipoint deployment or in-office roaming between access points, let alone mobile roaming like a cell phone. Frequency Hopping technologies should be deployed in the busy office, are perfectly suited for outdoor deployment, are extremely resistant to interference and support high-speed roaming between cells at 60 mph for in-vehicle applications that will start to appear shortly.
OK, I will
... this would mean approximately 3000 new "peering" points in North America - something no network engineer wants the headache of (just thing of the routes to publish).
Use UUNet as a backbone, and you're just fine. Plus, you don't have to go through that HORRIBLE teleglobe bottleneck in montreal to get anywhere. Pure backbone sailing to the world!
On another note, since commercial interests took over designing the internet after DARPA, they have introduced a TELCO MODEL of deployment. Ever noticed that every packet that goes out-of-network happens to go through 1 of 5 NAPs in North America? Yes, there are backup lines, but with the NAPs down networks will not talk nicely.
The internet has been designed by a group of TELCO engineers who plan only for minor outages, not global failures. The only way to manage a MAJOR failure is to peer in every area that backbones overlap
When growing your network, peer well & peer often.
When organized properly, wireless lans are NOT like party lines.
It is possible to plan a network to maximize bandwidth to the customer without getting into cable-modem style problems.
Look at the cellular carriers - they usually have less than 10MHz of bandwidth in any given area, but use time division and code division to make sure every phone has enough bandwidth for the call..... they aren't perfect, but their call drop rate is less than 1/1000 on average now.
In an improperly configured wireless network, yes it is possible to eavesdrop. But so can your home telephone line with an op-amp tool (the ones the bell guys carry). So can your cordless phone.
When a wireless network is properly planned, there are 3, sometimes 4 or 5 layers of network security:
1. In freqency hopping systems, there are 78 hopping patterns. Only one will "sniff" the packets in the correct order.
2. ESSID. This is the network security password. Access Points will only respond to radios with correct ESSIDs.
3. WEP. Wireless Equivelency Protocol. This is 40, 56 or 128 bit encryption that encrypts all communication on the radio.
4. Direct AP connection to router/firewall. This stops any extraneous traffic from flowing over the WLAN.
5. VPN Encryption. Many ISPs are using VPN from customer premise gear to the router, which makes sniffing wireless more difficult than wireline, since there are 4 extra layers of security.
---
No security will ever be perfect, but then again, most people using wireless lans are using them for internet access which is inherently PUBLIC anyways.
The coalition that will be deploying the network includes a large amount of wireless deployment as well. Being a large rural province, there is no possible way that $300 million would cover fibre deployment to every government office and school.
My guess is that they will run fibre to each town, probably in conjunction with the local power company (dark fibre), and use wireless to link all the offices to a central POP.
http://www.wi-lan.com/news/press156.html& amp; lt;/A>
Just not all that practical: read on.
=
.... but it is POSSIBLE!
L2TP Router INT: 192.168.200.1
L2TP Router EXT: 192.168.0.50
|
|
MASQ BOX INT: 192.168.0.1
MASQ BOX EXT: 172.32.1.1 (or any GLOBAL IP)
MASQ BOX EXT: 172.32.1.2 (or any GLOBAL IP)
MASQ BOX INT: 192.168.0.50
|
|
L2TP Router EXT: 192.168.0.1
L2TP Router INT: 192.168.201.1
===============================================
Notice that the IP of each MASQ box is identical to the opposing L2TP Router.
Each MASQ box must have PORT FORWARDING enabled with the GRE/ESP patch to the Linux Kernal to enable IPCHAINS passthrough and proper forwarding.
Each MASQ box must have either 2 way MASQerading running or a combination of global IP's (headache time) that allow the packets to change origin at destination.
L2TP1 initiates a connection to 192.168.0.1, which is then forwarded by MASQ1 to MASQ2 on port 500, utilizing GRE/ESP packet encoding. MASQ2 is set to forward internally these packets to L2TP2 on it's internal network, with the "originating" system appearing to be the local MASQ2 system, which, by design has the same IP as the original L2TP system.
Now, this is an incredible waste of time, since you completely wreck the ability of L2TP to support multiple connections
Cheers (and I appologize for the headaches if you try to make this work)
Although you cannot get *MORE* than 56k out of it, you can get a pure 33.6-56k to your local lan by just "faking" an ISP connection.
.... I sure worked well for transferring files between a PC and an AMIGA, although the AMIGA only had a 1200 baud modem and it was sloooooooooow.
If you take a phone cord, put it between the 2 modems, then make the dreamcast dial any number (as long as it doesn't do dial-tone detection).
Then on the other side, force an answer by entering "ATA", then the modems will handshake and all will be well.
Hope this works on dreamcast
I would have to disagree with you, but for entirely different reasons:
:-).
Although most ISPs are happy to "flood the spectrum with enough RF to bake a potato at 500 yards", there are some who are approaching it with a more cautious and thoughtful approach, utilizing passive receive amplifiers rather than transmit amplifiers; using directional antennas to eliminate radiated interference and sectored antennas to allow maximum coverage. Not everyone is tilting OMNIs from the top of a building to reach a customer below (although some do think that UFO's need bandwidth too
Although the band will get chewed up by the abusers, the rest of us will continue to plan our networks, and continue to run long after the has-been ISPs are gone or have switched vendors yet again.
If you're looking for highspeed 2-way in Southern Ontario, look at WDSL
They cover Hamilton, Burlington, Oakville, Mississauga, Stoney Creek, Grimsby, Beamsville, Carlisle & Waterdown.
3Mbit/s 2-way business access
cheers
SAMS publishing has a book entitled "Build your own 32-bit Operating System" that was released a few years ago.
... I even got through the first few examples!
It's been collecting dust on the shelf for a year, but it was well written
If you want, I can dig up the ISBN for you.
The 2.4GHz spectrum band is "unlicenced", and more commonly known as ISM (Industrial, Scientific, Medical) band.
It spans a frequency range of 2.4350 - 2.4850 GHz, which is broken down into 78 channels.
There are two types of Spread Spectrum technologies in use: DSSS & FHSS (Direct Sequence Spread Spectrum & Frequency Hopping Spread Spectrum).
DSSS uses 26 of the available frequency channels for its transfer signal, this is a contiguous block, and is very sensitive to any interference.
DSSS specifications call for 11 possible channels, overlapping, with only 3 non-overlapping channels. (this means it is only possible to co-exist 3 seperate DSSS networks/devices)
Under US/FCC regulations, the full spectrum may be used, so 3 DSSS networks will co-exist, or up to 26 FHSS (in practice, 15 more realistic).
Under Canadian/IC regulations, only 1/3 of the spectrum may be used, so only 1 DSSS network is allowed, with only 1 possible channel, while FHSS will allow 8-10 networks)
The FHSS network standard is 802.11, which is officially 2Mbit/s, but some venders have proprietary 3Mbit/s rates available.
The DSSS network standard is 802.11hr, which is officially 11Mbit/s.
In Canada/USA, the maximum power output at your antenna is +36dBm ERP (Effective Radiated Power).
In Europe, the maximum power output is only +20dBm.
In my experience to date,
FHSS systems will consistently with up to 97% signal loss, while DSSS will work up to 30-40% signal loss.
When co-existing FHSS & DSSS, the frequency hopper will run nicely 2-3Mbit, while the direct sequence radio will drop from 11Mbit to 1Mbit with 50% "interference".
My longest Links to date(FHSS):
.....13.2km @ 1Mbit/s
.....10.1km @ 2Mbit/s
.....6.7km @ 3Mbit/s
If anyone else has longest link or interference stats, please post them.
It really just comes down to what pattern-matching algorithms they use to detect an entry. In most cases the network is probed first, usually between a specific time on a repeating basis (between classes, after work, weekends, etc). Next a would-be cracker must find an exploit, this would usually involve determining characteristics of a specific point of entry - a single server, discovering the software version, patch level, security updates, etc. Then comes the entry to the system, and following what is done afterwards.
Unless you have an extremely patient cracker, with foreknowledge of the layout, it would be almost impossible to not leave traces in the logs.
I am guessing you could use a modified version of the psychiatric profiling software many law enforcement branches use, since they also look for a needle-in-a-haystack comparison between dissimilar crimes (dissimiler origin IP addresses)
hmmm
Currently, I am on one of the smallest providers in the area (Fido/Microcell) which is a GSM provider in Canada. Coverage only exists in metro areas, but I was amazed at how well I could roam to other providers.
I did a road trip 4 weeks ago from Ontario to Florida, and was only out of signal for 1 hour out of 24, never had a problem receiving calls, voice mail worked perfectly, and the charges weren't all that bad.
While it would be nice to be on a full coverage network, it roams so well, who cares?
Well, here we are again, folks:
Between Intel & AMD we have:
Socket7
Super7 (100Mhz)
Socket 370
Socket ??? (100 & 133Mhz Coppermine)
Slot 1
Slot 2 (SECC2)
Slot A
With all these different "standards" for putting the processor onto the motherboard, how long will it be before the processors are just stamped onto the motherboard?
We're at the point now, where any processor upgrade requires a new motherboard (either for FSB speed, or connector type, or chassis type). If you buy early and expect to upgrade, Intel changes the rules, if you buy later, your upgrade choices are less than 100Mhz different because the clock multiplyer won't go that high. And of course, everything else under the sun has been integrated onto some motherboards (Video, Sound, Modem, Ethernet, Serial, Parallel, USB, IDE, FDC)
This industry is rapidly moving just like the Automotive industry did about 10 years ago. The trend moved from a car that could be 'tinkered' with in the driveway to eke out more horsepower or gas mileage, to cars that should never be touched by a hobbyist without expensive diagnostic equipment.
The days of tinkering are numbered, and I for one am disappointed.
As I said, it's been a while since I took finite ... it's starting to come back, though.
Using all lower case is bad, but restricting the sample space to 4.5 million still makes it easier for a brute-force passcrack than leaving it alone.
The real question is: How far out of our way should we go to protect low-access user accounts?
The amount of information given to a would be cracker by having a default policy reduces the amount of time he has to spend by 1/3! If anything, that would make the server more inviting.
Again, it's all just a matter of how you look at the problem.
cheers
Adding in those two requirements greatly enlarges the potential pool of passwords. Even if you assume only numbers will be used in addition to letters and not all the punctuation marks, you're still increasing your password base by several orders of magnitude.
I would have to disagree.
Forcing the use of both upper and lower case letters actually restricts the possible combinations by at least half!
(Disclaimer: this is all based on an OAC finite math course i took a few years back)
Let's assume 4 character passwords, because the math is simpler:
Total number of possible passwords (26 LC, 26 UC, 10 #) = 62^4 = 14776336 total passwords.
because of the need to have at least ONE non-letter, the following is now true
= 62*62*62*10 = 2383280
We just ELIMINATED 12 MILLION possible passwords!
Now, since one letter MUST be opposite case (and not a number) we are at:
= 62*62*26*10 = 999440
Well, there goes another 1.3 MILLION passwords!
Out of 14 MILLION passwords, there are now only 1 MILLION acceptable passwords based on the critera.
Now, on longer passwords, the effect of these constraints should be proportionally less.