Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt

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

So the one question that does not seem to be answered is why is the CPE the best place to do this? Why not do it on the BNG/BRAS? The draft does say "or for mobile Service Providers (where it can be centrally implemented)." however the rest of it is taking about doing it on the CPE.

This sort of thing has been done here in Australia by Internode on the BNG/BRAS since around 2007/2008, using both ingress and egress ACLs applied to each customer's session. Customers can opt out of it if they choose. It doesn't require any special CPE capabilities, and keeps the unwanted traffic off of the customers link. It is used/available for both IPv4 and IPv6.

I also think there should be some discussion of host based firewalls that are likely if not ubiquitously available on IPv6 hosts, in the context of this security model. This document seems to be presenting a view that the CPE is the only security mechanism present.

This document seems to be being half way between documenting what Swisscom have done, and providing general advice derived from what Swisscom have done. Yet I'd disagree with a number of things Swisscom have done, such as doing this in CPE rather than the BNG/BRAS, and e.g., blocking SSH to the customer(!), but not SNMP(!). If it is going to be an advice document, the other topics should be covered such as this idea in the context of (near) ubiquitous host based firewalling, expansion of the pros/cons of doing it on the CPE verses the BNG/BRAS, and things such as what if the central updating mechanism either fails or is subverted by an attacker. Otherwise, I think it should very explicitly only document exactly what Swisscom have done.

As a side note, I generally disagree with the whole idea, as it seems to me that once you start blocking specific applications, you're not providing "Internet access" any more, you're providing "certain Internet application access". I don't think it is an ISPs place to say what applications a user can or can't use. SNMP is a good example - v1 and 2 are quite insecure, but v3 is very secure - yet they all use the same UDP port, so v3 would be dropped if SNMP was included in the Swisscom list. There is also a form of encrypted telnet (RFC2946), and it would seem my Fedora 19 box supports it (-x option). Encrypted telnet may not be popularly used, but the assertion that telnet is not secure cannot be made (people of course use SSH instead, but that is dropped too!). In general, the customer opt-out that Internode provide makes it somewhat tolerable to me. Customer opt out is easy to do on the BNG/BRAS, but if it was embedded in the CPE, it is up to the CPE
 vendor as to whether it is able to be switched off or not and the rule sets are and can easily be kept up to date by customers, assuming they have the competence to do so. We really don't want something like this to happen again :

AutoSecure Bogon Filter Potentially Causes Blackholing of Internet Traffic

http://www.cisco.com/en/US/ts/fn/610/fn61971.html



Regards,
Mark. 



----- Original Message -----
> From: Eric Vyncke (evyncke) <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Cc: 
> Sent: Tuesday, 22 October 2013 4:35 PM
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt
> 
> Here are the main changes based on the Berlin meeting discussion:
> 
> In order to avoid that this document appears as an IETF 'blessing' of a 
> specific ACL (or layer-4 ports), a lot of verbiage has been added to show the 
> list as EXAMPLE and we have removed all 'proposals' and 
> 'recommend' in favor of the word 'example'.
> 
> We kept the list of ports as an example but clearly mentioned that this list was 
> based on known vulnerabilities in protocols (e.g. Telnet is in the clear) or 
> implementations (still some worms active on 445 for old Windows 
> implementations). Again, examples.
> 
> Another generic rule was added to allow for remote management (in the case of 
> managed CPE).
> 
> A mention is also added about whether to do stateless or stateful filtering is 
> not that relevant for this I-D as its only objective is to give an example of 
> what a SP did.
> 
> 
> As a side note, Ragnar (a co-author) has presented this approach at the RIPE 
> meeting => several positive discussions
> 
>>  -----Original Message-----
>>  From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>  [e-mail]
>>  Sent: lundi 21 octobre 2013 19:19
>>  To: [e-mail]
>>  Cc: [e-mail]
>>  Subject: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-
>>  00.txt
>> 
>> 
>>  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-00.txt
>>      Pages           : 7
>>      Date            : 2013-10-21
>> 
>>  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 based on an actual 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 blocked inbound 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-00
>> 
>> 
>>  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/
>> 
>>  _______________________________________________
>>  v6ops mailing list
>>  [e-mail]
>>  https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>