Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security

From: Cameron Byrne <[email-masked]>
Date: Sat, 2 Feb 2013 18:16:28 +0000

I support the WG adoption of this I-D.

I believe it would be helpful to call out that the drop rules can be
statelessly implemented in the provider network while the ratelimiting
function is stateful and is a better fit for the CPE.

I would also suggest the the term residential be changed to include
mobile.  Perhaps "consumer grade" internet service or something like
that.

CB

---

From: <[email-masked]>
Date: Sun, 3 Feb 2013 00:02:11 +0000

> De : Eduard Metz [mailto:[email-masked]]
> Envoyé : jeudi 31 janvier 2013 14:50
>
> I general I think having different (defined) "security profiles" is something
> that could be beneficial (e.g. CPE's having multiple predefined modes of
> operation) so in that respect this is a good initiative. At the same time it
> would also be good if there would be some sort of applicability statement for
> these different profiles that describes which profile is most suitable for
> specific cases. Because, even though the draft claims this is sufficient for the
> proverbial grandma, I'm not convinced this category of users would also
> actually need this (that they would be protected is also a rather big claim). It
> may even be confusing since their Internet access service behaves
> differently for IPv4 and IPv6.

Yes, but on the other hand there are many more differences between v4 and v6 (starting with privacy extensions). We have to live with potential confusion during the few decades that this transition will last.

Otherwise I agree that we should mitigate the "protected" word here.

> Targeting for a fixed policy (Sec 3) doesn't seem realistic to me. As
> mentioned in the draft, the policy must be maintained to ensure it lives up to
> it's goals / intention. In my opinion it's also this aspect that makes it more or
> less unsuitable for the average user. How do the authors feel about policy
> maintainance (e.g. responsiblity of the end-user, or the operator/ISP)? In
> particular the protection of weak services, or services in general would be
> better I think, seems a complex task given the large variation in devices in the
> home environment. Some guidelines on policy maintainance would be
> usefull I think.

The list of ports for this predefined setup is not an RFC recommendation, it's just an example. It should ideally be maintained by the ISP and enforced in the CPE, when the CPE is provided by the ISP.
Ideally again, the user should be able to modify his firewalling rules on the CPE to match his own needs.

> Is it correct that this draft suggest to implement RFC6092 except REC-
> 11/18/33, and proposes alternatives for these requirements? This was at
> least my interpretation of 3 & 4 in section 3.1 (note: 3 mentions REC-
> 11/17/33, whereas 4 mentions REC-18 instead of 17).

Re-reading 6092, it's REC-17 indeed. Thanks for the notice.

> Section 3.2 describes that technical users could "open other applications",
> not sure what is meant here. I thought the point was the CPE would be
> open? Other applications then being the exceptions/weak services that are
> prohibited?

You're right; the wording is not appropriate. The idea is to say that the user should be able to configure his rules.
 
> Not sure the policy really prevents unauthorised access. The policy prevents
> (any) access to some known ports (that may have weaknesses), but other
> services/devices are still accessible and vulnerable to unauthorised access
> (e.g. a NAS using a web-based management interface, running on a different
> port). Also, do  the statements in Section 6 mean that the balance-policy
> does not protect against other threats as mentioned in Section 2?

It's clear that the set of ports can't cover every single product existing on the market that might introduce vulnerability in the customer network.
However, this list is just an example in the RFC. Therefore every implementation of this policy will be different. 

We'll probably have to complete the security section to make this more transparent.

> 
> There is no mention about the use of privacy extensions, although this does
> influence the end-to-end connectivity this draft attempts to restore.
> Something to include?

Could make sense. Let's see if we find a nice place to talk about it.

Thanks for the review!
Guillaume

---

From: <[email-masked]>
Date: Sun, 3 Feb 2013 00:14:43 +0000

> De : Cameron Byrne [mailto:[email-masked]]
> Envoyé : samedi 2 février 2013 19:16

> I believe it would be helpful to call out that the drop rules can be statelessly
> implemented in the provider network while the ratelimiting function is
> stateful and is a better fit for the CPE.
> 
> I would also suggest the the term residential be changed to include mobile.
> Perhaps "consumer grade" internet service or something like that.

Hi Cameron,

I understand very well your point and I guess your arguments (from a mobile point of view), but this RFC wants to focus on the CPE features, and we don't want to talk about ISP filters.
And regarding the mobile: nothing prevents the residential CPE uplink to be mobile, and with LTE connectivity we'll certainly see that more and more.

Guillaume

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Feb 2013 19:07:23 -0800 (PST)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Sent: Sunday, 3 February 2013 11:14 AM
> Subject: Re: [v6ops] new draft: draft-v6ops-vyncke-balanced-ipv6-security
> 
> statelessly
> I understand very well your point and I guess your arguments (from a mobile 
> point of view), but this RFC wants to focus on the CPE features, and we 
> don't want to talk about ISP filters.

Why not?

Internode here in Australia provide their customers with a default packet filter on the BRAS/BNG for both IPv4 and IPv6. Customers can switch it off via the customer portal if they want to. I can think of a few advantages of doing it there rather than on the CPE -

- it is CPE vendor and model independent, and here in Australia ISPs don't usually operate the CPE for the customer. This has recently become an option, however ISPs still don't insist you buy their CPE.

- Internet usage in Australia is monthly quota based (with traffic policing after the quota is exceeded to avoid bill shock, and associated outrage segments on tabloid current affairs shows), and therefore the ISP dropped traffic doesn't count against the customers' quotas

One general concern I have with this model though is that it doesn't encourage customers to fix their malware infections, because it will usually hide it from them. Over time, within the customer base, there could eventually be a large number of hidden infections. If the filtering system fails (e.g. error in applying RADIUS attributes or a faulty filter list update), then the malware would be unleashed. I don't see how shifting this filtering function to the CPE would avoid that possibility. I prefer the model where customers who appear to be infected with malware are quarantined so that they suffer a consequence and therefore are taught to take preventative measures.

> And regarding the mobile: nothing prevents the residential CPE uplink to be 
> mobile, and with LTE connectivity we'll certainly see that more and more.
> 
> Guillaume
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Eduard Metz <[email-masked]>
Date: Mon, 4 Feb 2013 10:34:56 +0100

Isn't it up to the ISP's to decide where to implement these filters? As
long as it results in  the same functionality for the end-users.

/Eduard

On Sun, Feb 3, 2013 at 1:14 AM, <[email-masked]> wrote:

> mobile.
> I understand very well your point and I guess your arguments (from a
> mobile point of view), but this RFC wants to focus on the CPE features, and
> we don't want to talk about ISP filters.
> And regarding the mobile: nothing prevents the residential CPE uplink to
> be mobile, and with LTE connectivity we'll certainly see that more and more.
>
> Guillaume
>

---

From: Eduard Metz <[email-masked]>
Date: Mon, 4 Feb 2013 10:43:18 +0100

>
> It's clear that the set of ports can't cover every single product existing
> on the market that might introduce vulnerability in the customer network.
> However, this list is just an example in the RFC. Therefore every
> implementation of this policy will be different.
>

Indeed this is should be pointed out clearly. Also if the draft does not
describe a policy in itself, but a way to define a more open policy this
should also be clear. And again, an applicability statement / some usecase
would be helpful to provide some understanding in which cases this (type
of) policy would be benefical over that defined in RFC6092.

/Eduard

---

From: "Anfinsen, Ragnar" <[email-masked]>
Date: Mon, 4 Feb 2013 23:30:37 +0000

Eduard, all,

That is totally right, this draft describes the principal of allowing all traffic, both inbound and outbound, except some ports that the ISP/CPE manufacturer/end-user decides.

I also see the challenge in how do define/update a list of ports that should be blocked. I can see a possibility that someone makes a public, well maintained list, which a CPE/ISP can subscribe to in order to keep the list up to date. However, I also see that such task involves a lot of trust and maintenance.

Maybe some trusted body, like ISC or HoneyNet, should consider maintaining such list. But keeping in mind that this should not be a list that is to frequently updated.

Just my 5 cent.

/Ragnar

On 04.02.13 10:34, "Eduard Metz" <[email-masked]<mailto:[email-masked]>> wrote:

Isn't it up to the ISP's to decide where to implement these filters? As long as it results in  the same functionality for the end-users.

/Eduard

On Sun, Feb 3, 2013 at 1:14 AM, <[email-masked]<mailto:[email-masked]>> wrote:
> De : Cameron Byrne [mailto:[email-masked]<mailto:[email-masked]>]

Hi Cameron,

Guillaume

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Feb 2013 12:48:10 +0000

IMHO documenting this apparently successful approach as an
Informational RFC is a fine thing to do. I don't see much point
in debating this particular set of choices; in fact this could
be a non-IETF Independent Submission RFC.

I did wonder what the policy is for ICMPv6. RFC 4890?

    Brian

On 25/01/2013 16:08, Eric Vyncke (evyncke) wrote:
> Some explanations about this new draft... (which should also be of interest to OPSEC WG)
> 
> IPv6 CPE have always the issue of the default security policy especially around allowing inbound connections:
> - Some say allow (fully open) to restore end-to-end
> - Some say block (fully closed/valve like) to mimick the IPv4 NAPT stateful behavior.
> 
> RFC6092 describe a simple security policy for IPv6 CPE. Together with Mark Townsley and Andrew Yourtchenko, we wrote the advanced-security draft something in the line of fully open but use IPS in line (what is called Universal Threat Mitigation) but this is expensive and the I-D did not gather momentum.
> 
> This I-D is based on Swisscom deployment which is 'balanced' between open and close. It is simply allowing all traffic inbound EXCEPT for well-known TCP/UDP ports linked to malware or vulnerable services.
> 
> The authors are the Swisscom engineers who initiated this balanced security and Ragnar from Altibox (a Norvegian ISP).
> 
> Hope this helps
> 
> -éric
> 
>> -----Original Message-----
>> From: Fred Baker (fred)
>> Sent: vendredi 25 janvier 2013 14:45
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: new draft: draft-v6ops-vyncke-balanced-ipv6-security
>>
>>
>> A new draft has been posted, at http://tools.ietf.org/html/draft-v6ops-
>> vyncke-balanced-ipv6-security. Please take a look at it and comment.