Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Lorenzo Colitti <lorenzo@google.com> Mon, 16 November 2015 06:35 UTC

Return-Path: <lorenzo@google.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9843B1B2DFE for <v6ops@ietfa.amsl.com>; Sun, 15 Nov 2015 22:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.963
X-Spam-Level:
X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
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 gEtY5cBesJJK for <v6ops@ietfa.amsl.com>; Sun, 15 Nov 2015 22:35:22 -0800 (PST)
Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D50F1B2DF7 for <v6ops@ietf.org>; Sun, 15 Nov 2015 22:35:14 -0800 (PST)
Received: by ykdv3 with SMTP id v3so223822140ykd.0 for <v6ops@ietf.org>; Sun, 15 Nov 2015 22:35:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wY7L68hdO5pF2woP/PNzgxe5cIhMtd8cV1xOUD6/hHk=; b=Q3sP9I3lV2ZhnigdMntsO2V82BoB6PXVGnukk2bAvo/VFBICu9vpUQetQOKjnjKMlX lL8lCLq0Js9UwtLvKru7d2SSPXXt3PpSHSFfoO9gn5vFI9u9bQhG2m7M9zmfzNoQZqvj clYrA3IkREKyyH+hqEfo/8fV1kzUK1EkWMwq4GFENiZ4kTU5XjnF5QL+npxTxuS509B0 Sjfjwd4i1USeHr5qaOyNznliHR7MjCMnTrW2TM7RdU1j4UzjDV/bnskFVeDv5BB7Rhsj ETzByi/nopVblQfcShAGBj8snbWi1dMhDWOShgKBpyMs8m8UfUNQoCRFTHysezJUkgq8 N7rQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wY7L68hdO5pF2woP/PNzgxe5cIhMtd8cV1xOUD6/hHk=; b=R5ZoCvzvmgfu2TjdrSybfk9k0SicIwcJLVK+1KU9v3dboymz9tkxI6hu6m+VehydHk DBgrsyq1oiYAx0U8GIt59h2mX/fi2uSu0vtKRT/OyhQP07i33smEEgZQYDVRtenxL+ek 1o/637p74kEqt86N8nJgIEqw+53REvEEal7qEveIkd3vJszoKr7bJANI8RUf4yTpCGMQ ftWZjd+y2zbpxPhyTwkXDI9ZqIGO25swcBXiwex5A3xPnJq5ftV2GLWxlF3rhvBjcSmF 8r6d/p1TK4O6VpfWXFJY8bDOnG4HwSrOa+Q8rD7dNezrUXhhxq23ApJDio+vOrjBOL7o t9LA==
X-Gm-Message-State: ALoCoQnaUDyj2m/E8Wy7QwUvTPor6fpf8EnOCzPZSWKoy9wv101VzRG/DQFG2D2+gcpyb5AOU0pO
X-Received: by 10.129.44.3 with SMTP id s3mr32762724yws.141.1447655713784; Sun, 15 Nov 2015 22:35:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.37.115.131 with HTTP; Sun, 15 Nov 2015 22:34:53 -0800 (PST)
In-Reply-To: <56489030.2010808@si6networks.com>
References: <D25D5920.C914E%Lee.Howard@twcable.com> <CAKD1Yr1EqbiGJ8EZo8E909zujUt49skcz1SNe8stEWfHnbUsTw@mail.gmail.com> <CAG6TeAsHMTyhbRrOenb1kA9XEDdOCBBbuN3ZGF3LJ=8ToyGtiQ@mail.gmail.com> <CAKD1Yr3RUc9FEw7VyJ=ENH_sJY85m1BESo77v_maShPvCkj6rA@mail.gmail.com> <CAG6TeAv9DPYUCsNG_vHCTOpwwJ8KdhjWeGE=-s6dEuMgaVHf1g@mail.gmail.com> <CAKD1Yr2VXVFareTk-J_+pcr_UW9Do-zf_uYcyjNW-MTPts6hRQ@mail.gmail.com> <CAG6TeAt2JJJmALy=pJFaojbnZrQRE0e0i-D=XtTce=rmbf08tQ@mail.gmail.com> <CAKD1Yr1H2HgxBNOZBrx-ttoB6z6caLAck3csF=ti6CDUzW57ng@mail.gmail.com> <D267B9E3.5DB8C%evyncke@cisco.com> <CAKD1Yr2zY9qr76f-KO7DTnYXQEmMJ0O6M22nFczfjGfL5Dk=dA@mail.gmail.com> <564537A7.90102@si6networks.com> <CAKD1Yr3dUMEoG-De5YWDFyjGehhxBq-uyN-NSqbYgvinDUy8Wg@mail.gmail.com> <56455ACD.6040804@si6networks.com> <CAKD1Yr0V_8DYOCm_BcB-xjKmCJc6AX25J8QZRE-c0CgYnnUM7g@mail.gmail.com> <CAG6TeAsrKe28qLcKyvjxr57PZaD9KZQTZMd0qPx3+ctLPutDsg@mail.gmail.com> <CAKD1Yr3NxyHd5zgVMjoBepLAkocv_ee+8n5PGW19x4tgY=mggg@mail.gmail.com> <56489030.2010808@si6networks.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Mon, 16 Nov 2015 15:34:53 +0900
Message-ID: <CAKD1Yr3JN7Ggrkf59YfsXoyM2LjW9nf+Yz5VhuTxJKDBVLdFkg@mail.gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary="001a114278de943b300524a29c32"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/lzm6E72pXMs6GeAEPZqz-oPPE9o>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2015 06:35:24 -0000

On Sun, Nov 15, 2015 at 11:01 PM, Fernando Gont <fgont@si6networks.com>
wrote:

> > Not for NFC, bluetooth, smoke signals, or well-known ports you
> > don't. And even if you do need a third party, there's a huge
> > difference between a third party that relays / snoops your traffic
> > vs. a third party that just puts the two parties in touch and then
> > disappears from the equation.
>
> Could you please elaborate how this would work:
>
> 1. A is behind a diode firewall
> 2. B is behind a diode firewall
> 3. A initiates a TCP connection with B.
>

A and B exchange ports out of band using NFC. A says to B "I am at port
1111". B says to A "I am at port 2222". A binds to port 1111 and connects
to B port 2222. A's firewall creates a mapping A:1111 -> B:2222. At the
same time B binds to port 2222 and connects to A port 1111. B's firewall
creates a mapping B:2222->A:1111. Once both mappings are created, TCP works.

This works behind a simple stateful firewall, but does not work behind a
NAT because the port numbers are rewritten as well. Yes, if the firewall
checks the sequence numbers as well, then A and B need to agree on those
too. It's true that you can't do that as an unprivileged app on today's
host OSes, but rogue apps are certainly able to do this.


> I fully disagree. NAT can be the most evil device ever. But all this
> things we've being talking about have to do with an incomplete
> architecture that NAT is making evident rather than about a complete
> architecture that NAT is breaking.
>

I know you disagree with that. All I'm saying is that we've gone back to
that.


> I disagree. Your claim can be correct for an enterprise with BYOD. BUt
> it is certainly not true for virtually every home network where a number
> of devices are attached to it -- possibly un-updated, with bad defaults,
> etc.
>
> In any case it's possible to DoS a device with a single packet, or
> worse, that you can root a device with a single packet (see one of the
> few openbsd remotely exploitable vulns, alas IPv6-based), a diode
> firewall would prevent such devices from being owned from the Internet.
>

But that's really hard. You have to scan Internet space at random, scanning
OUI space for remotely exploitable devices... much easier to use a browser
trojan to compromise the user's host and DOS the device from there.