Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)

Mark Andrews <marka@isc.org> Thu, 16 November 2017 22:26 UTC

Return-Path: <marka@isc.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B011271FD for <ipv6@ietfa.amsl.com>; Thu, 16 Nov 2017 14:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7iHPwOrcL69 for <ipv6@ietfa.amsl.com>; Thu, 16 Nov 2017 14:26:12 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64114126BF3 for <ipv6@ietf.org>; Thu, 16 Nov 2017 14:26:12 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 7C5663B69CB; Thu, 16 Nov 2017 22:26:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 433E1160087; Thu, 16 Nov 2017 22:26:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DBDB016008D; Thu, 16 Nov 2017 22:26:09 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wdPO3o4zv31X; Thu, 16 Nov 2017 22:26:09 +0000 (UTC)
Received: from [172.30.42.89] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9F1F5160087; Thu, 16 Nov 2017 22:26:08 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: PCP, and 6434bis (was Re: IPv6 only host NAT64 requirements?)
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20724B57-F88D-4F19-9DF8-F492B733A03C@google.com>
Date: Fri, 17 Nov 2017 09:26:06 +1100
Cc: Tim Chown <Tim.Chown@jisc.ac.uk>, Ca By <cb.list6@gmail.com>, 6man WG <ipv6@ietf.org>, Ole Troan <otroan@employees.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5AF93DAF-CFB0-458C-BEE9-96DBACE1E366@isc.org>
References: <m1eEGbJ-0000EhC@stereo.hq.phicoh.net> <D43E103C-27B8-48CF-B801-ACCF9B42533E@employees.org> <m1eEHPS-0000FyC@stereo.hq.phicoh.net> <59B0BEC0-D791-4D75-906C-84C5E423291B@employees.org> <m1eEIGX-0000FjC@stereo.hq.phicoh.net> <73231F8D-498E-4C77-8DA8-044365368FC9@isc.org> <CAKD1Yr1aFwF_qZVp5HbRbKzcOGqn==MRe_ewaA8Qc8t3+CVu_Q@mail.gmail.com> <44A862B7-7182-4B3A-B46E-73065FC4D852@isc.org> <D42D8D7A-6D19-4862-9BB3-4913058A83B6@employees.org> <CAFU7BARCLq9eznccEtkdnKPAtKNT7Mf1bW0uZByPvxtiSrv6EQ@mail.gmail.com> <183A8772-6FEF-43BD-97F9-DD4A2E21DB90@google.com> <5D9D33A8-88F0-4758-84FA-BCB364E8013F@employees.org> <16B61573-E233-40ED-8A22-CD145EBB8F98@google.com> <A89E7192-0FD4-4750-8745-147AFCC364DC@jisc.ac.uk> <CAD6AjGQcF=+FRFke1P0+vcmEEqWQ0NUsfprS6qBvfsG+3HMXhA@mail.gmail.com> <75C8CD33-AF67-4669-8548-EF318FC69BDE@jisc.ac.uk> <20724B57-F88D-4F19-9DF8-F492B733A03C@google.com>
To: james woodyatt <jhw@google.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/v3d6D40etWZfxDjlW1h8yPvD_q4>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 22:26:14 -0000

> On 17 Nov 2017, at 7:06 am, james woodyatt <jhw@google.com>; wrote:
> 
> On Nov 16, 2017, at 07:26, Tim Chown <Tim.Chown@jisc.ac.uk>; wrote:
>> On 16 Nov 2017, at 12:42, Ca By <cb.list6@gmail.com>; wrote:
>>> 
>>> I assumed PCP was designed with an eye firmly on future routed home networks where firewall holes need to be opened. […]
> 
> It was. In fact, that was the reason NAT-PMP evolved into PCP in the first place: because we needed to extend NAT-PMP to support punching holes in RFC 6092 firewalls.
> 
>>> The alternative is secure host and no firewall. There is no firewall at the ietf conference right now, right?  Are you secure ? Is there a malware outbreak?
> 
> That’s the alternative, but it’s not the dominant practice.
> 
>> Yet in practice pretty much every ISP deploying IPv6 to residential is doing so with RFC 6092, or stricter. Perhaps with a toggle to turn off firewalling, but that’s the reality.
> 
> Surveys I’ve seen show that most IPv6 residential networks outside of a few large providers in USA are using something like RFC 6092 with no prior user action. Home users either have no option to disable the firewall or they have no knowledge of it. Anybody planning to deploy IPv6 applications in residential networks (and I’m absolutely one of them) would be absolutely stupid to expect any way for passive listeners to receive inbound flows from arbitrary remote endpoints. Both REC-48 and REC-49 in RFC 6092 are widely ignored in the field. (Which is the outcome I warned against when I was writing it.)

Then those ISP’s are delivering a broken Internet connection to their customers.

There is a significant customer base that configure their border routers to allow
incoming connections today.  The ability to do this is built into retail routers today.
Customers that need this ability don’t buy routers that don’t support it.

Personally I would prefer that a router just did anti spoofing filtering and nothing else by
default but that wasn’t the consensus.   Allow only allocated source addresses out
the north interface.  Block allocated source addresses in on the north interface.  This
stops compromised internal machines successfully spoofing someone else.   The
also prevents someone else using spoofed address you are using coming in at the
cost of not being able to send a source routed packet to yourself.

Mark

>> OTOH it seems that PCP support in hosts / CPEs isn't exactly widespread.
> 
> Is there support in FreeBSD, Linux or Windows? I don’t think so.
> 
>>> The fatal flaw in PCP (aside from the name) is that it assumes the host needs protection yet it gives the host the power to control the firewall.  Next gen malware will come via email (just like today), it will encrypt your hard drive, and then setup and c2 network on your pc via pcp controls.  Sad!
>> 
>> True, and that happens with UPnP today…
> 
> UPnP has the added festival of third-party option enabled by default. It’s truly a magical wonder.
> 
> 
> --james woodyatt <jhw@google.com>;
> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org