A challenge (was Re: Default security functions on an IPv6 CPE)
tedm at ipinc.net
Thu May 19 02:13:23 CEST 2011
On 5/18/2011 3:20 PM, Mark Smith wrote:
> On Wed, 18 May 2011 15:10:01 -0700
> Ted Mittelstaedt<tedm at ipinc.net> wrote:
>> On 5/18/2011 2:49 PM, Mark Smith wrote:
>>> 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.
>> Any Smartphone running a Windows OS does not have critical mass to make
>> hacing it worth anyone's time. It's like hacking Macintoshes running
>> MacOS X, - there have been cracks made up in the lab and some have even
>> won contests, but there's not enough Macs in the wild for a virus to
>> As for Android, well I have to ask you, how in blazes do you think that
>> people root their phones to get free tethering?
> Not by address scanning the Internet for their attached phone I presume.
None of the major cell carriers have switched to IPv6 at the current
time. It's coming, though. Thus an IP scan would probably work in the
absense of a carrier's firewall. I wonder how reachable other android
phones are from an android phone?
>> Half of the rooting
>> software out there uses cracks that exploit holes in Android.
>> It's only matter of time before we get a self-replicating virus that
>> attacks Android. Android is getting close to critical mass and has
>> already surpassed the iphone.
>>>> 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
>>> 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
>> Bull Shit!
>> I already posted the most likely attack vector days ago to this thread
>> that does NOT involve IP scanning and you are ignoring it.
> So how will an IPv6 CPE firewall protect against that?
Layers. Onions have layers, ogres have layers, good security has layers.
An IPv6 CPE is generally going to be built on a Linux platform. The
soft candy inside behind it is generally going to be a Winders box.
The same kind of attack that works against a Linux CPE to breach it
isn't likely to work against the Winders box. So the attacker has
double the work to do.
The owner of the winders box may not care that his CPE is being used to
DDoS someone's IRC channel, he may be a lot more concerned about his
credit card info saved in his soft candy inside Winders box.
>>> 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
>>> 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.
More information about the ipv6-ops