[PLUG] another reason or two why IPv6 rocks

Daniel Pittman daniel at rimspace.net
Sun Jan 30 06:16:57 UTC 2011


On Sat, Jan 29, 2011 at 18:47, Tim <tim-pdxlug at sentinelchicken.org> wrote:
>
>> So it seems my issue is with the immensity.  This immensity will dull the
>> enormity of some net citizens.  No longer will it be possible for them to scan
>> address ranges checking for exploitable targets. With the sheer size of the
>> IPv6 space random probes just won't be efficient.

...but don't count on that helping you in the slightest. Various
approaches to remote host discovery have already floated about, and
once any local device is compromised scanning the local network
becomes fairly trivial.

> Yes and there are some interesting tricks you can play with this if
> you get clever.  Here is an example of one:
>
> Ever heard of port knocking?  This is a strategy whereby clients
> intentionally probe (for example, port scan) certain services in a
> certain order as a secret code in order to instruct a firewall to open
> up service to them.  It provides a simple way to mask a service from
> potential attackers while still allowing users from any source IP
> address to access it.  Port knocking is not a replacement for good
> authentication, but it can help mitigate vulnerabilities in certain
> critical services.

...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.

[...]

> 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.

[...]

> So instead, let's improve this by creating a smart DNS server that we
> control.  Whenever we ask about any valid name, it returns us a signed
> cryptographic token which contains some limited information.  This
> token is embedded as the last 80 bits of the IP address itself.
> The DNS server can be instructed to place anything it wants in that
> token, within space limits.  When the firewall receives a request for
> an IP address, it statelessly validates the cryptographic token (much
> like we already do in TCP SYN cookies) and passes traffic on according
> to predefined rules.

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.

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.

> So now we can create ourselves a special, secret domain name like
> "mysecretSSHservice.example.org" which returns a cryptographic cookie
> containing an indicator for what services should be opened to the
> client.

...which is equivalent to the bad versions of port knocking, if you
don't have custom client-side software, since you are transmitting
your "secret" in the clear, and worse: now you are using an even more
MITM-able protocol to do it.  Without DNSSEC there is no way at all to
validate that an attacker hasn't manipulated your secret, and even
DNSSEC can't stop them sniffing it out of the air.  Do you really want
to be the next target of FireSheep?

> The domain name is easy to remember, there is no client
> software required, and we have a very strong guarantee about how
> hidden our hidden services are.

A strong guarantee of zero, there.  It isn't even vaguely well hidden.
 You would do a universe better by layering your authentication token
on something robust, like HTTPS, or even better, ssh.  (pfauth, all is
forgiven. Please come back.)


> 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!

Regards,
    Daniel
-- 
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman <daniel at rimspace.net>
✆ Contact me via gtalk, email, or phone: +1 (503) 893-2285
♲ Made with 100 percent post-consumer electrons



More information about the PLUG mailing list