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

From: <[email-masked]>
Date: Fri, 25 Jan 2013 05:45:00 -0800 (PST)

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 25 Jan 2013 16:08:10 +0000

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.

---

From: Eduard Metz <[email-masked]>
Date: Thu, 31 Jan 2013 14:49:40 +0100

Hi,

Some comments and questions on the balanced IPv6 security draft:

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.

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.

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

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?

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?

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?

cheers,
   Eduard

On Fri, Jan 25, 2013 at 5:08 PM, Eric Vyncke (evyncke) <[email-masked]>wrote:

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