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

[Tassos Chatzithomaoglou <[e-mail]>]

First of all i would like to note that i find this draft very interesting, giving food for thought.
If this was going to be a BCP then i would have major objections. Since it's informational, it would be nice to see it published.

A general comment:

Personally i believe it's too early to decide on anything about IPv6 default security, especially when referring to devices "protecting" grandmas. The percentage of IPv6 eyeballs is way too low to change the current stateful "kind-of-protection", just based on the number/type of recorded ipv6 attacks. I don't see how can someone guarantee that in one year from now when a new exploit will have been found, it will be easily blocked using this type of protection.

Threats/attacks evolve at the same speed (or even faster) than the measures we take against them and moving to a default open policy gives them the advantage of knowing how to exploit these weaknesses easier. Instead of focusing on http/sql/rpc/etc attacks we might see other types of attacks rising from the bad guys, since we give them the space to do so. Also, having some means of a centralized homenet security device can be proved valuable, when all "protected" hosts are of different (and sometimes unknown) capabilities.

So, although i support this, i would like to see a note warning about some of the above dangers and noting that extra caution is to be used when following this.


And some specific comments:

>  The blocked inbound ports is expected to
>    be updated as threats come and go.

>    This document is applicable to off-the-shelves CPE as well to managed
>    Service Provider CPE or for mobile Service Providers (where it can be
>    centrally implemented).

>    The basic goal is to provide a pre-defined security policy which aims
>    to block known harmful traffic and allow the rest, restoring as much
>    of end-to-end communication as possible.  This pre-defined policy can
>    be centrally updated and could also be a member of a security policy
>    menu for the subscriber.

>    These example lists will probably evolve with the time as new
>    protocols and new threats appear.  The update of the specific rules
>    could be done by firmware upgrade, policy update (for example by
>    Broadband Forum TR-69).

Experience has shown than CPE updates from vendors are much slower than host updates, so i would expect that new threats would take a while to be fixed in the firmware. TR-069 would solve that only for managed CPEs, assuming a policy could be applied.


>    3.  Rule ProtectWeakServices: drop all inbound and outbound packets
>        whose layer-4 destination is part of a limited set (see
>        Section 3.2, the intent is to protect against the most common
>        unauthorized access and avoid propagation of worms (even if the
>        latter is questionable in IPv6); an advanced residential user
>        should be able to modify this pre-defined list;

Set is limited because of a specific reason? hw resources?
Comparing this implementation (default permit) with an opposite one (default deny), i would see much more deny entries in this than permit entries in the other. I can't predict the possible growth of each one, but i would give much more chances to denies than to permits.

>    The authors of the documents believe and the Swisscom deployment
>    shows that the following attack are mostly stopped:
>
>    o  Unauthorized access because vulnerable ports are blocked

It would be nice to have a report with some numbers backing this up.


--
Tassos


Fred Baker wrote on 10/11/2013 21:00:
> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security.  Please read it now. If you find nits
> (spelling errors, minor suggested wording changes, etc), comment to the
> authors; if you find greater issues, such as disagreeing with a
> statement or finding additional issues that need to be addressed,
> please post your comments to the list.
>
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>