You probably want to control the latter because as a good netadmin you should know that this is good practise.
Proper filtering of packets trageted at the router helps to make it more robust against DoS attacks directed at the router itself. Actually, most people already have such filters in place (especially on IOS versions which support IP receive ACLs).
Second, I'd be interested to see a comparison of 2.0.46 versus 1.3.27. I have a pet theory that multithreaded C code has more bugs than single-threaded C code, and I'd like to see whether there is evidence to support it.
I don't think the tool can statically detect synchronization errors and the like. Probably it just viewed Apache 2 as a singled-threaded program.
So basically they offer a service like lclint [virginia.edu] only many times more advanced ? What is to say they haven't missed anything?
Exactly, this is a PR campaign for their tool. If Apache had used it, it would have had zero defects in this test. What does this tell about the actual bug count in Apache? Nothing. The tool doesn't even check functionality, only some occurrences of undefined behavior (which is an achievement nevertheless, such things are quite hard to detect statically).
One I think I wonder: What happens if you run the tool on Apache 1.3.10 (say)? Does it find all the security bugs? And if it dows, should its use be banned as a cracker tool? 8-)
Many makers of 802.11g cards cannot lawfully provide such a driver under various radio frequency emission regulations.
Irrelevant. The ISDN subsystem of Linux has exactly the same problem (well, even worse, regulation is stricter in the old telco world), and there is source code. Some versions have even been certified, and it's legal to run them on public networks.
Not necessarily. IIRC, GCC generates faster x86 floating point code when you activate SSE. The chip might be faster, but it won't help you if the compiler can't exploit the bizarre FPU stack architecture.
Are there any Intel-sponsored GCC 3.3 numbers around for comparison?
IIRC, Apple has contributed a lot to the PPC compiler backend in GCC. Wouldn't that make it a "special compiler" wrt Apple's chips?
GCC does not contain code that recognizes and special-cases certain SPEC fragments, e.g. by inserting hand-written machine code, as some vendor compilers do. Of course, Apple had plenty of opportunity to tune the PPC backend (maybe they did, to me Apple is mostly known for front-end work such as precompiled headers, which are generally useful), but they can't push code into GCC on the grounds of "it makes us look good on SPEC, but there's no other purpose".
I wouldn't say that they are bogus, they just measured with a realistic compiler.
Another part to twiddle with is floating point. If you leave the FPU in its default 80 bit mode, you'll get somewhat worse numbers than with 64 bits. But the fact that GCC doesn't cope too well with the stack-based x86 FPU is probably the major contributing factor.
But these numbers are probably more realistic, at least for us GNU users.
The SPEC results are really interesting. Single-processor integer performance (which matters most at least for me, although CPU performance is hardly interesting for me these times) is slightly worse than Intel's flagships, but the clock rate is also significantly lower.
However, the most interesting part is that they used GCC to compile the SPEC suite, and not some special compiler to make hardware look good in benchmarks (in contrast to some vendor compilers). Given that all the software I run has been compiled by GCC (with the exception of a few Lisp programs), the numbers are a bit more relevant than the usual SPEC results for me.
On the other hand, you could claim that Apple chose GCC on the Intel platforms to make them look bad in this comparison...
Most new stuff has IPv6 in *hardware*. 3700's, et al.
Some ISPs have not yet written off large investments in hardware-accelerated IP forwarding without a simple software upgrade path to IPv6 (e.g. 76xx, or 12xxx with almost any line card).
Before IPv6 can be deployed the vendors of the various routers etc. of hte internet will have to get fully tested and come in to line.
This will happen eventually, no doubt, and the DoD won't have much influence here. A major obstacle for moving to IPv6 internally is the lack of IPv6 support in all those devices that are neither routers nor real hosts---e.g. printers. I think the DoD deadline might actually encourage vendors to enhance their firmware.
Cisco has finally released IOS 12.3 which has full support for IPv6 in a production IOS train
With some high-end Cisco routers, the problem is not software but hardware. For example, only very, very few GSR line cards are currently able to route IPv6 traffic at reasonable packet rates.
Why should the FSF be able to interpret Red Hat's inconsistent licensing terms? Wouldn't it be more natural to natural to ask Red Hat for a clarification first?
No shit the channel was not compromised, but it was misused. So how do we solve the problem of determining if a message is authentic. *snaps fingers* I know! We use public key cryptography [rsasecurity.com]!
If PKIs become relevant, we're going to see attacks on CAs (and not just the rather insecure SSL browser PKI). Furthermore, there is currently no large-scale PKI which tracks who is authorized to speak for which company (let alone IP address space!).
What we see is a problem during registration, and switching to a PKI won't solve such a problem, just shift it to the CA registration. It could be argued that a one-time registration might very thorough checks faesible, but that's just theory. All bulk data processing on the net is either done by machines or by unqualified, low-paid works (that's why it's called bulk processing), and I don't see why a large-scale would be different.
And let me repeat the major problem: At some point, you have to check that a document dealing with address space allocation issues was sent by someone who is authorized to change the allocation. Even if you have digital certificate which proves the identity of the sender (a questionable assumption), you still don't know if the sender is authorized for the transaction. Given that we deal with extremely critical infrastructure, I really don't care if I can sue someone afterwards. The goal has to be to avoid processing bogus transactions in the first place.
I hope this makes it a little bit clearer why PKIs can't immediately solve such problems.
With the still-ongoing cases over domain theft and fraud, is it at all surprising that it's also active in areas like IP block assignments?
Procedures for DNS registrations and customer/ISP/ARIN communications are somewhat different. (In fact, IP WHOIS and DNS WHOIS server completely different purposes, DNS WHOIS is just for the lawyers.)
But it's not hardly suprising that such plots are successful. Spotting forgery requires skillful people with a suitable time budget, but it's hard to pay them in the current market.
YOu know, as evil as this may be, Sitting on that quantity of Unused IP adresses is just as criminal.
Unfortunately, due to aggressive route filtering for the old class B space, you cannot route these IP addresses as freely as you'd have to if you'd reassign it to a couple of organisations. I agree it's annoying (hey, we are using two or three/16 for less than 20,000 hosts), but the Internet at large has far more pressing issues to deal with (combatting DoS in a scalable manner, general security accountability and so on).
IBM owns 9.0.0.0/8, none of it is connected to the Internet. They use globally unique addressing in their internal network for private connections to other organizations, without fear of collisions.
IBM is so special that they can't use 10.0.0.0/8 like everybody else?
(Actually, the assignment predates the reservation of 10/8, so that's not a valid complaint. Unfortunately, renumbering is infeasible, even in this case.)
Fortunately, filters usually prevent you from announcing arbitrary address space via BGP (some ISPs run RIP on CPE and their customers can steal address space from each other, but that's a different, local problem).
However, I fear that you can get quite far with forged BGP announcements if your upstream (and the upstream's upstream 8-) doesn't apply any filters. We are definitely heading for interesting times (but this isn't news).
255 addresses x 255 networks - 2 (network and broadcast) = 65023 IP addresses
Interesting, but completely meaningless calculation -- and you forgot to account for the gateway in each subnet, which usually takes another IP address.
If you are short of IP addresses, just put the whole/16 onto one interface, and you can use 65533 addresses for hosts.
The sad thing is that you cannot automatically verify BGP announcements because most of the out-of-band routing registries are incomplete or full of data which is mainly of historic interest.
Unfortunately, your proposal is completely irrelevant. In the cases I know, the communication channel between the ISP and ARIN was not compromised. The ISP just sent bogus data, acting on forged customer requests.
There isn't any cryptographic protocol that can solve such a problem, and that's why S-BGP and other "secure" BGP successors are almost completely irrelevant. Cryptography is not the answer to all attacks.
Slashdot Mirror
You probably want to control the latter because as a good netadmin you should know that this is good practise.
Proper filtering of packets trageted at the router helps to make it more robust against DoS attacks directed at the router itself. Actually, most people already have such filters in place (especially on IOS versions which support IP receive ACLs).
At the moment, the impact of this defect is downtime because of hasty emergency router maintaince.
According to Cisco, high CPU utilization is not a result of the present defect.
The ISP was probably experiencing an ordinary DoS attack.
The cable provider could have made an emergency update of its CPE, but that's rather unlikely.
Second, I'd be interested to see a comparison of 2.0.46 versus 1.3.27. I have a pet theory that multithreaded C code has more bugs than single-threaded C code, and I'd like to see whether there is evidence to support it.
I don't think the tool can statically detect synchronization errors and the like. Probably it just viewed Apache 2 as a singled-threaded program.
So basically they offer a service like lclint [virginia.edu] only many times more advanced ? What is to say they haven't missed anything?
Exactly, this is a PR campaign for their tool. If Apache had used it, it would have had zero defects in this test. What does this tell about the actual bug count in Apache? Nothing. The tool doesn't even check functionality, only some occurrences of undefined behavior (which is an achievement nevertheless, such things are quite hard to detect statically).
One I think I wonder: What happens if you run the tool on Apache 1.3.10 (say)? Does it find all the security bugs? And if it dows, should its use be banned as a cracker tool? 8-)
Many makers of 802.11g cards cannot lawfully provide such a driver under various radio frequency emission regulations.
Irrelevant. The ISDN subsystem of Linux has exactly the same problem (well, even worse, regulation is stricter in the old telco world), and there is source code. Some versions have even been certified, and it's legal to run them on public networks.
So how do you explian this?
Bottom line: the fp numbers are totally bogus.
Not necessarily. IIRC, GCC generates faster x86 floating point code when you activate SSE. The chip might be faster, but it won't help you if the compiler can't exploit the bizarre FPU stack architecture.
Are there any Intel-sponsored GCC 3.3 numbers around for comparison?
Hey, even my HP-48 has a 64 bit ADD instruction. (It's executed in microcode, though, the Saturn processor has just a 4-bit adder, it seems.)
IIRC, Apple has contributed a lot to the PPC compiler backend in GCC. Wouldn't that make it a "special compiler" wrt Apple's chips?
GCC does not contain code that recognizes and special-cases certain SPEC fragments, e.g. by inserting hand-written machine code, as some vendor compilers do. Of course, Apple had plenty of opportunity to tune the PPC backend (maybe they did, to me Apple is mostly known for front-end work such as precompiled headers, which are generally useful), but they can't push code into GCC on the grounds of "it makes us look good on SPEC, but there's no other purpose".
I wouldn't say that they are bogus, they just measured with a realistic compiler.
Another part to twiddle with is floating point. If you leave the FPU in its default 80 bit mode, you'll get somewhat worse numbers than with 64 bits. But the fact that GCC doesn't cope too well with the stack-based x86 FPU is probably the major contributing factor.
But these numbers are probably more realistic, at least for us GNU users.
The SPEC results are really interesting. Single-processor integer performance (which matters most at least for me, although CPU performance is hardly interesting for me these times) is slightly worse than Intel's flagships, but the clock rate is also significantly lower.
However, the most interesting part is that they used GCC to compile the SPEC suite, and not some special compiler to make hardware look good in benchmarks (in contrast to some vendor compilers). Given that all the software I run has been compiled by GCC (with the exception of a few Lisp programs), the numbers are a bit more relevant than the usual SPEC results for me.
On the other hand, you could claim that Apple chose GCC on the Intel platforms to make them look bad in this comparison...
Most new stuff has IPv6 in *hardware*. 3700's, et al.
Some ISPs have not yet written off large investments in hardware-accelerated IP forwarding without a simple software upgrade path to IPv6 (e.g. 76xx, or 12xxx with almost any line card).
Before IPv6 can be deployed the vendors of the various routers etc. of hte internet will have to get fully tested and come in to line.
This will happen eventually, no doubt, and the DoD won't have much influence here. A major obstacle for moving to IPv6 internally is the lack of IPv6 support in all those devices that are neither routers nor real hosts---e.g. printers. I think the DoD deadline might actually encourage vendors to enhance their firmware.
Cisco has finally released IOS 12.3 which has full support for IPv6 in a production IOS train
With some high-end Cisco routers, the problem is not software but hardware. For example, only very, very few GSR line cards are currently able to route IPv6 traffic at reasonable packet rates.
Why should the FSF be able to interpret Red Hat's inconsistent licensing terms? Wouldn't it be more natural to natural to ask Red Hat for a clarification first?
No shit the channel was not compromised, but it was misused. So how do we solve the problem of determining if a message is authentic. *snaps fingers* I know! We use public key cryptography [rsasecurity.com]!
If PKIs become relevant, we're going to see attacks on CAs (and not just the rather insecure SSL browser PKI). Furthermore, there is currently no large-scale PKI which tracks who is authorized to speak for which company (let alone IP address space!).
What we see is a problem during registration, and switching to a PKI won't solve such a problem, just shift it to the CA registration. It could be argued that a one-time registration might very thorough checks faesible, but that's just theory. All bulk data processing on the net is either done by machines or by unqualified, low-paid works (that's why it's called bulk processing), and I don't see why a large-scale would be different.
And let me repeat the major problem: At some point, you have to check that a document dealing with address space allocation issues was sent by someone who is authorized to change the allocation. Even if you have digital certificate which proves the identity of the sender (a questionable assumption), you still don't know if the sender is authorized for the transaction. Given that we deal with extremely critical infrastructure, I really don't care if I can sue someone afterwards. The goal has to be to avoid processing bogus transactions in the first place.
I hope this makes it a little bit clearer why PKIs can't immediately solve such problems.
With the still-ongoing cases over domain theft and fraud, is it at all surprising that it's also active in areas like IP block assignments?
Procedures for DNS registrations and customer/ISP/ARIN communications are somewhat different. (In fact, IP WHOIS and DNS WHOIS server completely different purposes, DNS WHOIS is just for the lawyers.)
But it's not hardly suprising that such plots are successful. Spotting forgery requires skillful people with a suitable time budget, but it's hard to pay them in the current market.
YOu know, as evil as this may be, Sitting on that quantity of Unused IP adresses is just as criminal.
/16 for less than 20,000 hosts), but the Internet at large has far more pressing issues to deal with (combatting DoS in a scalable manner, general security accountability and so on).
Unfortunately, due to aggressive route filtering for the old class B space, you cannot route these IP addresses as freely as you'd have to if you'd reassign it to a couple of organisations. I agree it's annoying (hey, we are using two or three
IBM owns 9.0.0.0/8, none of it is connected to the Internet. They use globally unique addressing in their internal network for private connections to other organizations, without fear of collisions.
IBM is so special that they can't use 10.0.0.0/8 like everybody else?
(Actually, the assignment predates the reservation of 10/8, so that's not a valid complaint. Unfortunately, renumbering is infeasible, even in this case.)
Fortunately, filters usually prevent you from announcing arbitrary address space via BGP (some ISPs run RIP on CPE and their customers can steal address space from each other, but that's a different, local problem).
However, I fear that you can get quite far with forged BGP announcements if your upstream (and the upstream's upstream 8-) doesn't apply any filters. We are definitely heading for interesting times (but this isn't news).
255 addresses x 255 networks - 2 (network and broadcast) = 65023 IP addresses
/16 onto one interface, and you can use 65533 addresses for hosts.
Interesting, but completely meaningless calculation -- and you forgot to account for the gateway in each subnet, which usually takes another IP address.
If you are short of IP addresses, just put the whole
The sad thing is that you cannot automatically verify BGP announcements because most of the out-of-band routing registries are incomplete or full of data which is mainly of historic interest.
Unfortunately, your proposal is completely irrelevant. In the cases I know, the communication channel between the ISP and ARIN was not compromised. The ISP just sent bogus data, acting on forged customer requests.
There isn't any cryptographic protocol that can solve such a problem, and that's why S-BGP and other "secure" BGP successors are almost completely irrelevant. Cryptography is not the answer to all attacks.