Subject: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt

From: [email-masked]
Date: Fri, 06 Dec 2013 07:38:34 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Balanced Security for IPv6 Residential CPE
	Author(s)       : Martin Gysi
                          Guillaume Leclanche
                          Eric Vyncke
                          Ragnar Anfinsen
	Filename        : draft-ietf-v6ops-balanced-ipv6-security-01.txt
	Pages           : 9
	Date            : 2013-12-06

Abstract:
   This document describes how an IPv6 residential Customer Premise
   Equipment (CPE) can have a balanced security policy that allows for a
   mostly end-to-end connectivity while keeping the major threats
   outside of the home.  It is documenting an existing IPv6 deployment
   by Swisscom and allows all packets inbound/outbound EXCEPT for some
   layer-4 ports where attacks and vulnerabilities (such as weak
   passwords) are well-known.  The policy is a proposed set of rules
   that can be used as a default setting.  The set of blocked inbound
   and outbound ports is expected to be updated as threats come and go.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-balanced-ipv6-security

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-balanced-ipv6-security-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Guillaume Leclanche <[email-masked]>
Date: Fri, 6 Dec 2013 10:51:57 -0500

Hello,

This is a new version of the draft after having analyzed the WGLC
comments and the Security Directorate review.

A lot of text was modified to make sure that the document could not be
mistaken for a recommendation. The filtering concept and examples are
not changed, as the authors have chosen to stick to describing the
documented practice.

There are new mentions of PCP and UPnP, and the Security
Considerations part was also detailed.

Guillaume

2013/12/6  <[email-masked]>:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 6 Dec 2013 18:29:47 +0000

> not changed, as the authors have chosen to stick to describing the

Wearing my "chair" hat.

I'd like to understand the authors' guiding principle here. Is it 
(a) to document the Swisscom experience, 
(b) to "sell" an approach as having the attribute of being "balanced", or 
(c) to reflect the viewpoints of the working group?

(a) would be well handled as an individual submission, whether to the working group or in the independent stream, and should contain the word "Swisscom" in the title. Cisco examples of this approach (and there are ample other examples from Ericsson, Microsoft, and others) include

	http://www.ietf.org/rfc/rfc1613.txt
	http://www.ietf.org/rfc/rfc2105.txt
	http://www.ietf.org/rfc/rfc2281.txt
	http://www.ietf.org/rfc/rfc2341.txt
	http://www.ietf.org/rfc/rfc2741.txt
	http://www.ietf.org/rfc/rfc2892.txt
	http://www.ietf.org/rfc/rfc3488.txt
	http://www.ietf.org/rfc/rfc3924.txt
	http://www.ietf.org/rfc/rfc3954.txt
	http://www.ietf.org/rfc/rfc4332.txt
	http://www.ietf.org/rfc/rfc4463.txt
	http://www.ietf.org/rfc/rfc5171.txt
	http://www.ietf.org/rfc/rfc5517.txt
	http://www.ietf.org/rfc/rfc6037.txt
	http://www.ietf.org/rfc/rfc6218.txt
	http://www.ietf.org/rfc/rfc6656.txt
	http://www.ietf.org/rfc/rfc6759.txt
	http://www.ietf.org/rfc/rfc6812.txt

(b) would similarly be an individual submission, either to the working group or the independent stream. It would treat Swisscom as a proof case, not a controlling consideration, working instead on the concept that it wants to promote.

(c) would require the authors to consider the working group to be in control of the document, not the authors, and not Swisscom. 

What is the guiding principle here?

---

From: Guillaume Leclanche <[email-masked]>
Date: Fri, 6 Dec 2013 14:10:51 -0500

> (c) to reflect the viewpoints of the working group?

Definitely (a). By adopting it, the WG showed interest in having this
document saying "Hey look, this is done somewhere, v6ops thinks it's
an interesting approach to CPE filtering.". Especially from people
operating a network.

How do you want to proceed ?

Guillaume

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2013 20:23:34 +0100

Hi,

> an interesting approach to CPE filtering.". Especially from people

Indeed very interesting. Eventually I would like to see something like this as (c), but that might be a bit to far for now.

Cheers,
Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Dec 2013 09:47:13 +1300

> Indeed very interesting. Eventually I would like to see something like this as (c), but that might be a bit to far for now.

Sander, from the experience that the authors of RFC 4864 in getting
anything close to rough consensus, I'd say that the chances of
achieving (c) are very low, since there's a wide range of opinion
(due to a wide range of requirements).

I think (a) is a wise path to get this useful document out
in public. This really is a case where the market makes
a choice.

    Brian

---

From: Sander Steffann <[email-masked]>
Date: Fri, 6 Dec 2013 21:52:38 +0100

Hi Brian,

> in public. This really is a case where the market makes

Indeed. (a) is the wisest now. If the market chooses this approach then (c) might happen in the future.

Cheers,
Sander

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 6 Dec 2013 22:33:53 +0000

> an interesting approach to CPE filtering.". Especially from people

My problem is that (a) isn't a working group document; it's an experience report from Swisscom. Using Swisscom's experience as an example of the working group's outcome is fine, but then the document has to reflect the working group's viewpoint. Swisscom can be an example, but not the controlling interest.

---

From: Marc Lampo <[email-masked]>
Date: Mon, 9 Dec 2013 08:48:30 +0100

Section 2, Threats, still lists 6 threats of which only one (the fourth) is
addressed by the proposed implementation and then, only partially.

In my opinion this is very misleading as Swisscoms customers might get the
impression their ISP's approach helps against the 5 other threats as well,
which it doesnot.
I'd delete the section altogether.

Kind regards,

Marc

On Fri, Dec 6, 2013 at 4:51 PM, Guillaume Leclanche <[email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Mon, 09 Dec 2013 15:39:19 -0500

Le 06/12/2013 17:33, Fred Baker (fred) a écrit :
> Using Swisscom's experience as an
> example of the working group's outcome is fine, but then the document
> has to reflect the working group's viewpoint. Swisscom can be an
> example, but not the controlling interest.

Let's try to untie this knot...

Guillaume initially wrote: "The filtering concept and examples are not 
changed, as the authors have chosen to stick to describing the 
documented practice."

I understood this meant that the editors had interpreted WG consensus to 
be that they should not change the draft, not that they themselves 
decided to ignore WG consensus. Indeed, the WGLC generated a lot of 
discussion and I guess it was hard to extract clear guidance. In those 
cases, status quo looks attractive from an editor's viewpoint.

That hints at what is needed now: clear guidance on what the WG 
consensus actually is.

(Just as a WG participant closely following this draft since the 
beginning, and eager to see where it will go...)

Simon

---

From: Mark ZZZ Smith <[email-masked]>
Date: Thu, 26 Dec 2013 23:22:29 -0800 (PST)

Hi,

I've had a brief look, I'd still like to see some evidence that what is described has actually been effective. As has been mentioned, there are a number of reasons why Swisscom's customers have not suffered from attacks, such as ubiquitous per-host firewalls, IPv6's large address space or IPv6 temporary addresses. If there was no measurement before this method was deployed and then no measurement afterwards, it isn't possible to assert that this method is effective and the reason for lack of attacks.

I think it should be fairly easy to produce evidence that the ports that are blocked in this draft are actively being attacked - ACLs match counters with permit statements on Swisscom's BRASes/BNGs with permit statements for the specific ports that are blocked would be evidence.

I don't think the dshield port report is evidence, as it doesn't report IPv4 and IPv6 separately, meaning that the report could be all IPv4 data, or that the IPv6 ports are only to obvious unsolicited addresses such as ::1, and therefore the attempted attack is less likely to be effective anyway with EUI-64 based IIDs or the future stable and opaque IIDs.

Regards,
Mark.

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Saturday, 7 December 2013 2:38 AM
> Subject: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-01.txt
> 
>

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 27 Dec 2013 00:33:30 -0800 (PST)

----- Original Message -----
> From: Mark ZZZ Smith <[email-masked]>
> To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Friday, 27 December 2013 6:22 PM
> Subject: Re: [v6ops] I-D Action:	draft-ietf-v6ops-balanced-ipv6-security-01.txt
> 
> Hi,
> 
> I've had a brief look, I'd still like to see some evidence that what is 
> described has actually been effective. As has been mentioned, there are a number 
> of reasons why Swisscom's customers have not suffered from attacks, such as 

should have been "customers may not have".

> ubiquitous per-host firewalls, IPv6's large address space or IPv6 temporary 
> addresses. If there was no measurement before this method was deployed and then 
> no measurement afterwards, it isn't possible to assert that this method is 
> effective and the reason for lack of attacks.
> 
> I think it should be fairly easy to produce evidence that the ports that are 
> blocked in this draft are actively being attacked - ACLs match counters with 
> permit statements on Swisscom's BRASes/BNGs with permit statements for the 
> specific ports that are blocked would be evidence.
> 
> I don't think the dshield port report is evidence, as it doesn't report 
> IPv4 and IPv6 separately, meaning that the report could be all IPv4 data, or 
> that the IPv6 ports are only to obvious unsolicited addresses such as ::1, and 
> therefore the attempted attack is less likely to be effective anyway with EUI-64 
> based IIDs or the future stable and opaque IIDs.
> 
> Regards,
> Mark.
> 
>