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

[Ray Hunter <[e-mail]>]

> Lorenzo Colitti <mailto:[e-mail]>
> 20 November 2013 11:17
> 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.

Thanks to the authors for sharing experiences, and kudos to them, but I
am still confused about why this draft should be stamped approved as a
v6ops WG document, because it hasn't really been widely debated as a
generic security model, and it seems more geared to describing what one
provider has done.

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

<operational hat> There is nothing to say that an ACL on a router and an
end user device are mutually exclusive, depending on whose security
model you are implementing (ISP's or end user's).

But IMHO "Half an ACL" is worse than no ACL at all, or a complete
blocking ACL:  It stops legitimate users performing their normal tasks,
whilst leaving the system wide open to the abusers. And it's a complete
pain to debug or explain to a help desk or users. If you're going to
block a function because it's a threat, then block all of the associated
ports.

Thinking about this further: if port 8080 and 443 were open for the
duration of this trial, and there were no incidents,  doesn't that
rather suggest that there were no real issues with allowing incoming
sessions to web servers in general, and thus the block on port 80 was in
fact redundant?

Similarly if LPD was open for the duration of the trial, doesn't it
suggest that there was no real problem with remote (ab)users printing to
customer's printers?

regards,
>
> Cheees,
> Lorenzo
>
>

-- 
Regards,
RayH