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

Mark ZZZ Smith <> Tue, 22 October 2013 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E587921F9C3A for <>; Tue, 22 Oct 2013 13:22:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qjfSe26cXBiB for <>; Tue, 22 Oct 2013 13:22:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D9E9421F9FAE for <>; Tue, 22 Oct 2013 13:22:36 -0700 (PDT)
Received: from [] by with NNFMP; 22 Oct 2013 20:22:36 -0000
Received: from [] by with NNFMP; 22 Oct 2013 20:22:36 -0000
Received: from [] by with NNFMP; 22 Oct 2013 20:22:36 -0000
X-Yahoo-Newman-Property: ymail-3
Received: (qmail 22411 invoked by uid 60001); 22 Oct 2013 20:22:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1382473355; bh=kykSwcetqebs4DROuS+cZa8ah1TpdYaGbWMOoG+/Xgk=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UDR/bKotJtnWoSa4oW7IUfWytOd2KLKrdfc0zlxPHAY9pYJ6zGnD9H0stJomO4e+TbQSdERoBlweMr0xkRf3w26LGSWNYTELo00WdGusRZQo6TT7lKEd/9fGog+IaMhTtLzwdLPQ7wgqBBct/RIfIaXZIRrqXRjva8ZNqYh2G80=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=rYeiqLa2ZZykFv9Qy3HWDCDDw2qhR6qc7QZUEu0rFbdkqDnzcg5XsU2uhJGm43mv7ufhzJ7VX1It/syxkNgcORUM2aXImg1GbE5Dhm5+hup/ElcaoXtZwh/DrfAlV4tTDvHk7MS/aynU6UBEELjrGbGu0pvcxC0g6hJKjbhQmEQ=;
X-YMail-OSG: iAH2bfQVM1m_RXSrvOj67vJHfR6LZF4u_bLbvIdXGJjnydq F1h4a6pkjFmgZX401PInWL2kUZdlrToMVSYtYrUP8SNlzaLGLpU4Q76eBqGX wzD03yXcQX2fu29CQMm6D9gnh8Isy4vGY8zmMqZlxQYLR2xMAbjOTQWkJwwg VPbtiFJcjkXB7FlNAxUSxjJuUPNm7HY.5p8ed3g6BLvuw8mixCB8nun2KJE8 A.65cRY7I2wA69cUJqsUSMlC5D929WD8ZOvZtmOX36XFIuEoE6vjiYcWnmY9 eRBxvup7z2b5OPsRq3vxaTfaMFkLV_R5bfWiPewzsadJcDIWEt3wYC5_ZAmq ZSVghlB3Tbvk7bQYzUTs9pjfzGUJ9uurGWllGo1WSO99u6eiMcNwwrKYC6yR FSU0FSGXfi5a_lKQj9MZm5rJotwmU38fJhXaP4GZRDHQ48ntHn_pz_nZnFkt DHvn5uc3kwbdJZciXdT7HJPts_f2pJO0JHCIsEFEoDlTxAZDuoMUNObz4Tmi z23IvAhPYbSr6S1u_cj8bW8ZDFI7ANcskGK7hkYLbRojE1eL04xRJQEhI5Bw y7fBEp3uhC2V99Fmw6BrcYC6g.mCOjUP0u3cwMFJsj.M-
Received: from [] by via HTTP; Tue, 22 Oct 2013 13:22:35 PDT
X-Rocket-MIMEInfo: 002.001, U28gdGhlIG9uZSBxdWVzdGlvbiB0aGF0IGRvZXMgbm90IHNlZW0gdG8gYmUgYW5zd2VyZWQgaXMgd2h5IGlzIHRoZSBDUEUgdGhlIGJlc3QgcGxhY2UgdG8gZG8gdGhpcz8gV2h5IG5vdCBkbyBpdCBvbiB0aGUgQk5HL0JSQVM_IFRoZSBkcmFmdCBkb2VzIHNheSAib3IgZm9yIG1vYmlsZSBTZXJ2aWNlIFByb3ZpZGVycyAod2hlcmUgaXQgY2FuIGJlwqBjZW50cmFsbHkgaW1wbGVtZW50ZWQpLiIgaG93ZXZlciB0aGUgcmVzdCBvZiBpdCBpcyB0YWtpbmcgYWJvdXQgZG9pbmcgaXQgb24gdGhlIENQRS4KClRoaXMBMAEBAQE-
X-Mailer: YahooMailWebService/
References: <> <>
Message-ID: <>
Date: Tue, 22 Oct 2013 13:22:35 -0700 (PDT)
From: Mark ZZZ Smith <>
To: "Eric Vyncke \(evyncke\)" <>, "" <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-balanced-ipv6-security-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Oct 2013 20:22:47 -0000

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


----- Original Message -----
> From: Eric Vyncke (evyncke) <>
> To: "" <>
> 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: [] On Behalf Of
>>  Sent: lundi 21 octobre 2013 19:19
>>  To:
>>  Cc:
>>  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:
>>  There's also a htmlized version available at:
>>  Please note that it may take a couple of minutes from the time of
>>  submission until the htmlized version and diff are available at
>>  Internet-Drafts are also available by anonymous FTP at:
>>  _______________________________________________
>>  v6ops mailing list
> _______________________________________________
> v6ops mailing list