A challenge (was Re: Default security functions on an IPv6 CPE)
Mark Smith
nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Wed May 18 23:49:32 CEST 2011
On Wed, 18 May 2011 08:48:36 -0400
Jon Bane <jon at nnbfn.net> wrote:
> On Wed, May 18, 2011 at 8:13 AM, Mark Smith <
> nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
>
> >
> > What saved your smartphone from being hacked?
>
>
> You are trying to assert that because someone didn't get hacked "today",
> that the risk doesn't exist.
I'm directly saying the risk doesn't exist. If it did, the would be
evidence it does. Yet where are all the "smart phone hacked because of
no firewall by default, vendor taken to court" articles in the press?
With the huge popularity of smartphones in the last 5 years, surely
there'd be plenty of articles. With the shear number of them, it isn't
just luck that has stopped them from being attacked over the
IPv4 Internet.
> Several of us have pointed out simple vectors
> for initiating an attack.
I haven't seen a complete list of specific attack vectors
mentioned, because this discussion has already been constrained to
discussing IPv6 CPE firewalls. That then constrains the discussion to
the threats that CPE firewalls mitigate against.
In fact, you've indirectly pointed out exactly what the problem with
this discussion is. It is focused on a specific mitigation for a very
specific potential threat. It is not considering the security
landscape, including what is to be protected, the variety of threats
that exist in it, and how likely those threats are. In other words, a
current threat model needs to be developed.
The part of the threat model that people are using to justify IPv6 CPE
firewalling is invalid, because it is based on the invalid assumptions
that:
o IPv6's address space is the same size as IPv4's
o that hosts are not actively protecting themselves,
o that hosts have fixed physical locations and single points of
attachment to the Internet that rarely change,
o that inbound unsolicited address scanning is the most likely attack
vector.
All of these assumptions are easily demonstratively false. Some
of them may not have been prior to 2005, or earlier, but we're
discussing a security measure that is being put in place today, for
today and for the future, not the past.
Security is a convenience trade off. The key to getting security right
is to make sure you don't give up too much convenience, otherwise the
security measure becomes more of an imposition that the threat and the
consequences it is trying to protect against. Security measures are
only useful if they're appropriate for the situation.
In security it is important to recognise when the security landscape
has changed, so that threats are re-evaluated, and both now
inappropriate security measures are removed, and now appropriate
security measures are added or strengthened.
> Those vectors haven't been mitigated or
> invalidated.
I think a number of them have.
> Secondly, you do not take into account the fact that v6
> deployment is less than 1% across the internet today, which makes it a low
> value target. Within a few years, adoption will account for a significant
> percentage and draw the attention of the malicious.
>
That's debatable. The lack of recognition of the recognition of IPv6
security can mean that people have been lax about it, making it a more
interesting target.
Even then, how is a IPv6 CPE firewall going to protect users when it is
at home and they've got their laptop at the local cafe - both now and
in 5 years time? If you tell your SP customers that you've enabled IPv6
firewalling for them, isn't there a risk that they won't exactly
understand what you're saying, and believe that they're protected where
every they access the IPv6 Internet? While typical SP customers won't
understand security measures, what they do, and where they apply, they
are far more likely to understand if you tell them you're not providing
them with any and that it is completely their responsibility.
Regards,
Mark.
> -Jon
More information about the ipv6-ops
mailing list