Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC

[Lorenzo Colitti <[e-mail]>]

On Wed, Nov 20, 2013 at 7:01 PM, Ray Hunter <[e-mail]> wrote:

> So what does the draft really say?
>
> Here's some filtering rules, that you may or may not like, which may or
> may not be overridden, which may change over time, which only mitigate a
> very limited number of threats, and maybe the ISP will manage the
> security policy but maybe the end user wants to take this responsibility
>

Pretty much. Oh, and "this ISP has rolled it out and has not seen any
issues so far".


> Where's the evidence to say that this approach is any better than an
> open security policy of "allow everything bi-directionally" ?
>

None, but none is required because nobody is trying to make such a
statement. Which is good, because there is zero chance of this or any other
IETF working group (or actually, any group of more than... oh, about 3
engineers) agreeing on such statement.


> The threats are listed in the draft as:
>
>    o  denial of service by packet flooding: overwhelming either the
>       access bandwidth or the bandwidth of a slower link in the
>       residential network (like a slow home automation network) or the
>       CPU power of a slow IPv6 host (like networked thermostat or any
>       other sensor type nodes);
>
> not covered.


>    o  denial of service by Neighbor Discovery cache exhaustion
>       [RFC6583]: the outside attacker floods the inside prefix(es) with
>       packets with a random destination address forcing the CPE to
>       exhaust its memory and its CPU in useless Neighbor Solicitations;
>
> not covered.


>    o  denial of service by service requests: like sending print jobs
>       from the Internet to an ink jet printer until the ink cartridge is
>       empty or like filing some file server with junk data;
>
> not covered.e.g. port 515
>
>    o  unauthorized use of services: like accessing a webcam or a file
>       server which are open to anonymous access within the residential
>       network but should not be accessed from outside of the home
>       network or accessing to remote desktop or SSH with weak password
>       protection;
>
> not covered. e.g. port 8080.
>
>    o  exploiting a vulnerability in the host in order to get access to
>       data or to execute some arbitrary code in the attacked host such
>       as several against old versions of Windows;
>
> not covered.
>
>    o  trojanized host (belonging to a Botnet) can communicate via a
>       covert channel to its master and launch attacks to Internet
>       targets.
>
> not covered.
>

Right. And the draft doesn't claim that to addresses those threats.


> And in the Security section, the draft only addresses "Unauthorized
> access because vulnerable ports are blocked" ?
>

Yep. As the abstract says, it's a balance.

But the point about this draft is not the filtering policy itself, and in
fact, the document makes no claims about what the policy should be. (This
is good, because there's no chance of the WG ever agreeing on any specific
policy.) It simply says, "here are some threats. here's what we rolled out.
here's what we found out." IMO this is perfectly acceptable for an
operational group such as this one, and it is of value because it
represents real operational experience.

IMHO this threat is anyway blocked by machine firewalls running on every
> modern OS shipping today (any device that is likely to support IPv6)
>

I agree with you, but good luck finding lots of other people who do.

As an aside, I'm confused how can you simultaneously make the argument that
the draft doesn't cover port 515 and port 8080, and then in the same breath
say that that threat is blocked anyway by any device that is likely to
support IPv6. But again, neither is really the point of this draft.

Cheees,
Lorenzo