There are tons of directory resources out there like X.500. I disagree with your statement that corperations drive the bleading edge. They do.
We might think that individuals have the ability to run the course of the internet but it will be VERY hard for any individuals or non-profit groups (except ICANN) to take the rings of power from the internet.
Admit it. I don't have $10,000+ a month to keep a fast pipe to the net and the servers / routers / redundancy / etc.. to keep a fully robust name server, which get nearly as much traffic as the root servers. I would if I could 8-),
I can see that the opennic project has been setup effectively, but I would seriously doubt that they could handle NEARLY as much traffic that it takes to replace the ICANN root servers.
Although ICANN is making a concerted effort to have a fair and open election process, they have still come under serious fire form democracy advocates in the actual process of the elections.
The price to apply registrar status of a TLD is $50,000
Another point to add in why there are few female representatives ont the board, dispite the validity of the otehr comments.
Most of the ICANN to Be's are older then most of us, and they have probably been around since the 70's.
Now, even though there were femenists lining the halls of Universitities, I serously doubt that many were there to take Computer Sciences or Electronic Enngineering.
It is not a prejudice. I would say outside factors kept them away, but it did happen. These days, women are more encouraged to go inot the field's that they really like, and more women are finding a place with computers.
Although There might be a lot more women in the industry than the nominations reflect, they only nominated older (more distinguished) individuals.
Actually he is right. When IBM was struggling to keep in pace with the Windows sweap of the client side of the enterprise, IBM was developing their OS/2 platform as a windows killer (obviously they were on drugs... have you used OS/2...).
Anyway, back when the first affordable LAN's were around, Netware was the god of it all. IBM and M$ joined up to take that away. They made a Server Architecture called "LAN Manager", which is basically like Server Message Blocks...
I don't recall if IBM had a seperate server platform, or if it was part of OS/2, but M$ came out with Windows NT (New Technology), which was to be compatible with the LANManager system of IBM.
I would like to shed another point that could possibly make this itrace ICMP message quite useless, or destructive. Note, I am not an expert on the workings of the ICMP itrace packet. I just know enough of IP and the workings of routing / firewalls / ICMP to see there may be flaws in IETF's planning.
1. Possibility for using itrace messages for malicious attacks
Because the ICMP packet is just another IPv4 packet, there is just as likely a risk that the originator can use this packet type as a way to DOS a system, but flooding the system with itrace packets, like smurf(http://www.cert.org/advisories/CA-98.01.smur f.html), etc..
By opening a new, valid form of ICMP, firewalls that are used to block all non-productive ICMP traffic will have to be changed to block iTrace packets, hence eliminating its use.
2. The ways to stop itrace from working
The itrace packet will be susceptible to the same ill's of source spoofing that any other packet could. If one wishes to stop an itrace packet from finding the source that sent to, the originator could send a slew of itrace packets from varying sources, making any response useless.
3. The effects to routers and IP Stacks
In order to implement itrace effectively, all IP Stacks and Router software in the world may have to be changed to allow the tracing of these new message types. Firewalls shouldn't have a problem letting them through as long as the ICMP 'type' field can be specified in a filter. If itrace is not implemented directly into the stack, some stacks may throw the packet out as being 'mal-formed', which is another form of network attack.
4. Firewalls, NAT's, and the risks that itrace poses
The point of a firewalled system is so that hosts behind the wall will become protected, or even anonymous to the world at large. There are two decisions that network engineers have when the itrace packet is implemented.
They can let the packets enter the firewall, and run free. This can lead to DOS and smurf like attacks inside the network, and could cause a good deal of havoc. Also, letting itrace packets in and out of a firewall could seriously jeopardize the security of the private network, by using the itrace responses to reconstruct the layout of the internal network.
The other choice was to block any itrace packets from entering a firewalled system. This is what admins will likely do for security reasons. When a itrace request to find a host enters the firewall, the best that would happen is that the firewall would bounce a negative response saying that the firewall wouldn't let the ICMP message in. The worst is that the itrace message just gets discarded, in which case, the source of the itrace message has no idea why the trace failed.
5. Changes to IP Stacks and server/router loads
The problems presented had to do with a system that has been accepted and implemented. This problem has to do with the feasibility of such a system.
Just imagine a root router. It is pumping out hundreds of thousands of packets a minute. All of a sudden, a spoofed packet enters the router, and the leaves to its next hop, which is a host that the packet is DOS'ing. The router has to know which 'home' that the spoofed packet came from. That means that the router will have to keep track of every packet that comes and goes from the machine, in order to properly route the itrace packet to its next hop.
Conclusion
So, now I hope you all can see the ill's that the itrace packet type will lead to in the scheme of things. My best suggestion would be to wait until IPv6, when all routers, firewalls, and IP Stacks will be rewritten. At that time, architects could find reasonable ways around such a problem.
Well at least it is better than the estimated 5000 people they were expecting to vote.
;-)
There are tons of directory resources out there like X.500. I disagree with your statement that corperations drive the bleading edge. They do.
We might think that individuals have the ability to run the course of the internet but it will be VERY hard for any individuals or non-profit groups (except ICANN) to take the rings of power from the internet.
Admit it. I don't have $10,000+ a month to keep a fast pipe to the net and the servers / routers / redundancy / etc.. to keep a fully robust name server, which get nearly as much traffic as the root servers. I would if I could 8-),
I can see that the opennic project has been setup effectively, but I would seriously doubt that they could handle NEARLY as much traffic that it takes to replace the ICANN root servers.
Wrong on both accounts.
Although ICANN is making a concerted effort to have a fair and open election process, they have still come under serious fire form democracy advocates in the actual process of the elections.
The price to apply registrar status of a TLD is $50,000
Another point to add in why there are few female representatives ont the board, dispite the validity of the otehr comments.
Most of the ICANN to Be's are older then most of us, and they have probably been around since the 70's.
Now, even though there were femenists lining the halls of Universitities, I serously doubt that many were there to take Computer Sciences or Electronic Enngineering.
It is not a prejudice. I would say outside factors kept them away, but it did happen. These days, women are more encouraged to go inot the field's that they really like, and more women are finding a place with computers.
Although There might be a lot more women in the industry than the nominations reflect, they only nominated older (more distinguished) individuals.
Actually he is right. When IBM was struggling to keep in pace with the Windows sweap of the client side of the enterprise, IBM was developing their OS/2 platform as a windows killer (obviously they were on drugs... have you used OS/2...).
Anyway, back when the first affordable LAN's were around, Netware was the god of it all. IBM and M$ joined up to take that away. They made a Server Architecture called "LAN Manager", which is basically like Server Message Blocks...
I don't recall if IBM had a seperate server platform, or if it was part of OS/2, but M$ came out with Windows NT (New Technology), which was to be compatible with the LANManager system of IBM.
Well, we all know what happened after that...
The I stands for Inverse. Do some research, thank you.
I would like to shed another point that could possibly make this itrace ICMP message quite useless, or destructive. Note, I am not an expert on the workings of the ICMP itrace packet. I just know enough of IP and the workings of routing / firewalls / ICMP to see there may be flaws in IETF's planning.
r f.html), etc..
1. Possibility for using itrace messages for malicious attacks
Because the ICMP packet is just another IPv4 packet, there is just as likely a risk that the originator can use this packet type as a way to DOS a system, but flooding the system with itrace packets, like smurf(http://www.cert.org/advisories/CA-98.01.smu
By opening a new, valid form of ICMP, firewalls that are used to block all non-productive ICMP traffic will have to be changed to block iTrace packets, hence eliminating its use.
2. The ways to stop itrace from working
The itrace packet will be susceptible to the same ill's of source spoofing that any other packet could. If one wishes to stop an itrace packet from finding the source that sent to, the originator could send a slew of itrace packets from varying sources, making any response useless.
3. The effects to routers and IP Stacks
In order to implement itrace effectively, all IP Stacks and Router software in the world may have to be changed to allow the tracing of these new message types. Firewalls shouldn't have a problem letting them through as long as the ICMP 'type' field can be specified in a filter. If itrace is not implemented directly into the stack, some stacks may throw the packet out as being 'mal-formed', which is another form of network attack.
4. Firewalls, NAT's, and the risks that itrace poses
The point of a firewalled system is so that hosts behind the wall will become protected, or even anonymous to the world at large. There are two decisions that network engineers have when the itrace packet is implemented.
They can let the packets enter the firewall, and run free. This can lead to DOS and smurf like attacks inside the network, and could cause a good deal of havoc. Also, letting itrace packets in and out of a firewall could seriously jeopardize the security of the private network, by using the itrace responses to reconstruct the layout of the internal network.
The other choice was to block any itrace packets from entering a firewalled system. This is what admins will likely do for security reasons. When a itrace request to find a host enters the firewall, the best that would happen is that the firewall would bounce a negative response saying that the firewall wouldn't let the ICMP message in. The worst is that the itrace message just gets discarded, in which case, the source of the itrace message has no idea why the trace failed.
5. Changes to IP Stacks and server/router loads
The problems presented had to do with a system that has been accepted and implemented. This problem has to do with the feasibility of such a system.
Just imagine a root router. It is pumping out hundreds of thousands of packets a minute. All of a sudden, a spoofed packet enters the router, and the leaves to its next hop, which is a host that the packet is DOS'ing. The router has to know which 'home' that the spoofed packet came from. That means that the router will have to keep track of every packet that comes and goes from the machine, in order to properly route the itrace packet to its next hop.
Conclusion
So, now I hope you all can see the ill's that the itrace packet type will lead to in the scheme of things. My best suggestion would be to wait until IPv6, when all routers, firewalls, and IP Stacks will be rewritten. At that time, architects could find reasonable ways around such a problem.