> ...though it has exactly the same security properties as sticking a > web page in place that accepts a password, and then opens a hole in > the firewall to the client.
I agree. > > Let us now consider the enormous address space of IPv6. Every person > > can easily obtain a /48, or 80 bits of address space. The only way to > > find services on a hidden address would be if they were explicitly > > advertised or shared in a secret way. So, you could simply tell your > > trusted associates what your random IP address is that provides a > > service and then you achieve what you had achieved with port knocking > > without the need for a special client. > > Er, no you didn't. Port knocking at least required a password > (probably sent in the clear, and trivially weak, but whatever) before > it granted access; this model counts only on obscurity. You might as > well advocate picking a random high port to run the service on in IPv4 > land. As I said, port knocking is not a replacement for proper authentication. That is obvious. What is the difference between sending a secret series of ports numbers to a host versus sending a secret IP address? None. It is the same level of obscurity. For certain services, there *is* a benefit in hiding them. Sure, you can pretend that every service you ever run will be perfectly safe in its implementation, but as we have seen several times in the past, even the most trusted services like SSH and IPSEC have been vulnerable to attack. Privileged services like this are great examples of where port knocking is actually useful. It makes no sense to use it for public services, but those where you need to afford remote access and don't really trust the implementation, it is handy. > So, rather than actually authenticating, or using the *mandatory* > IPSec features in IPv6 which are a cryptographically strong way to > provide both authentication and encryption, you want create a shiny > new protocol based on cryptographic tokens. Once again, I'm not saying this or port knocking should be used to replace good authentication. Some people like port knocking though, and this is an improvement to it. > That has all the drawbacks of building a new cryptographic protocol > (how are you preventing replay attacks?), and all the drawbacks of > requiring custom client-side software, *and* avoids an existing > solution. I'm not advocating that any Joe off the street should hack together some shell scripts to implement such a system. I was merely trying to illustrate how the large address space can be used for some interesting data tracking. I have implemented a replay resistant version of this which also adds other information tracking about attackers. > > Sorry if that's long-winded, but I just wanted to illustrate that > > there are some fundamental changes in how the Internet can work, > > simply due to the very large address space. > > ...but that isn't a change, except in the perception of difficultly. > Now, if you said "IPv6 changes the game because it mandates functional > IPSec" you would be totally on a winner! Now if IPSEC is such a panacea, then tell me how you are going to deal with the denial of service problems that are baked into the design of the protocol? Not sure what I'm talking about? The IKE handshake is vulnerable to a serious DoS attack because it checks a Diffie-Hellman signature right off the bat prior to authentication. This first packet often comes in over protocols that can't be protected with things like TCP SYN cookies because they are tunneled over UDP or sent directly without any initial handshake. An attacker can simply flood the service with invalidly signed packets. Thank you NSA for pushing a flawed protocol on us. So now, consider protecting that service with port knocking or the DNS->IPv6 system I propose. An attacker can't get the first valid packet through without first knowing the port sequence or the secret domain name. This doesn't provide strong authentication, but it does provide real-world protection against several types of attacks. tim _______________________________________________ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
