[PLUG] another reason or two why IPv6 rocks

[Tim]

Hi Daniel,

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

It's true.  All security software has the potential to create more
exposures as it closes others.


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

I guess you missed the part where I mentioned clients no longer need
any special client side software or even need to take any additional
steps to access the service.  They merely need to remember a secret
domain name, which I would estimate is significantly easier than
installing some special client or even taking the additional step of
logging into some web page to white list themselves.


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

My Master's thesis wasn't focused primarily on the port knocking
replacement trick, it was focused on mitigating spoofed attacks.
However, if you dig enough into the paper, you can find all of the
details that shoul be relevant:
  http://sentinelchicken.com/research/tdm_ms_thesis/


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

We see eye to eye on the complexity bit. =)

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

Maybe.  Content distribution networks today do a pretty darned good
job of mitigating attacks using lots of network tricks, though it
seems to require throwing a lot of hardware at the problem.

Resource DoS attacks are a hard problem to address and most people
just write them off saying "well if they send packets fast enough,
there's nothing we can do".  But that's just a hand wave.  There are
ways to make systems scale even under massive DoS and the more tools
we have at our disposal for that the better.


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

I don't think I buy that argument for targeted attacks.  Port knocking
and similar schemes aren't going to easily yield their secret after a
full port scan.


> (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 SYN cookies are certainly a hack, since they weren't designed into
the protocol, so there ends up being trade offs.  But the loss of
features only happens during an attack and they allow services to
scale *much* further than they would otherwise.  It's really quite
dramatic the difference between services which turn on cookies under
load versus those which don't.

The scheme I developed was primarily built to provide SYN cookies like
protection for all services, not just TCP based ones.  The port
knocking like behavior was just a side effect of the scheme.  I didn't
want to get into these other details and benefits of the protocol on
this list, since they are quite a bit more complex than the port
knocking replacement, but you may be interested.


Back to IPSec: there are a few reasons I wouldn't come out and say
"Look, IPv6 offers integrated IPSec which is a great improvement":

1. We already have IPSec tunneled over other protocols.  For most
people, it's just as easy to use that.

2. IPSec offers no security if you can't authenticate services.  PKI
is the elephant in the room on this one, and most PKIs suck.

For most people there's probably just not much tangible benefit to
having it integrated.  Yes, it's more elegant and should be more
efficient, but features are selling points to most people, not a few %
of speed.

tim