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

[Mark ZZZ Smith <[e-mail]>]

>________________________________
> From: Lorenzo Colitti <[e-mail]>
>To: Ray Hunter <[e-mail]> 
>Cc: "[e-mail] WG" <[e-mail]> 
>Sent: Wednesday, 20 November 2013 9:17 PM
>Subject: Re: [v6ops] draft-ietf-v6ops-balanced-ipv6-security WGLC
> 
>
>
>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".
> 

How do they know? What methods have they used to be sure of that? All it sounds like is that they've passively waited for any complaints after deploying this, and as they haven't heard any, they've decided that the _only reason_ they haven't heard complaints is because their measure has worked. That is not evidence.

How do they know IPv6's large address space isn't the actual thing that has prevented their customers being attacked?

How do they know that host based firewalls isn't the reason that there hasn't been a successful attack?


How do they know that there hasn't been an attack, and it is just that they don't know about it? 

Where is the _measurement_ of the effectiveness or not of this, and where is the evidence that some other measure isn't the reason that there haven't been any known attacks?



>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
>
>_______________________________________________
>v6ops mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/v6ops
>
>
>