[PLUG] another reason or two why IPv6 rocks

Daniel Pittman daniel at rimspace.net
Mon Jan 31 03:57:52 UTC 2011


On Sun, Jan 30, 2011 at 10:15, Tim <tim-pdxlug at sentinelchicken.org> wrote:

[...]

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

Well, sure.  OTOH, that isn't providing substantial security...

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

...and you are just moving risk around, right?  Now you have an
exposure risk in your port knocking software, rather than an exposure
risk in your core service.

[...]

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

Didn't you agree that a secret IP was identical to a secret port
sequence earlier?  I would certainly grant this is no worse than port
knocking, but I can't see how it represents any improvement.

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

I still don't see it.  Seriously, how is this anything like the value
of actual security protocols embedded in the requirements for IPv6?
Sure, those have risks, but are they really any worse than the risks
in inventing a new security protocol?

Anyway, I would be interested in seeing the protocol description for
your secret DNS solution; I am curious about how you tackle a few
different aspects of the requirements, and that should answer them
pretty quickly. :)


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

Y'know, the baked in assumption there isn't terribly nice. ;)

In any case, yes, I was aware of that, and that there are plenty of
issues with IPSec.  Heck, if you asked me to point out a current
protocol that was pretty much the epitome of overdesign and complexity
as the enemy of security, IPSec would be right on up there.  (Hello,
Cisco extensions, while we are complaining.)

What it does provide is a substantially tested and, at least in
commercially deployed systems, reliably secure solution to the problem
of strong authentication *without* needing you to modify the client
software.

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

Sure.  OTOH, it remains secure, just unavailable, and frankly: if
someone wants to DoS your system the infrastructure to do that is
pretty readily available and inexpensive.  The attacker almost
certainly can manage even without something like this attack.

So, yes, granted: there is absolutely a DoS risk there, as well as the
exposure risk of the IKE daemon, and the complexity of IKE and IKEv2
(which does address that risk), and so forth.  Like any bit of
security I regard this, and port knocking, as a fundamental trade-off.

Incidentally: for most cases moving the service to a non-standard port
would have exactly the same benefit as port knocking, which is that
random scanning is less likely to find it, and no difference for
targetted attacks.  Done, without all the extra complexity.

(Also notable: SYN cookies are not a great example of solutions, since
the loss of all TCP options hurts an awful lot on modern systems.
Even the extended version in recent Linux isn't that much better, and
requires both ends to support the same system.)

[...]

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

...but, again, no different to using some sort of secure
authentication that opens the firewall, which easily has better
cryptographic properties, fairly reasonable security assurances, and
uses standard tools.

I don't dispute that the extended IPv6 address space makes this
possible, I just don't consider it a great advertisement for the
improvements in security it delivers. ;)

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