Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets

Philipp Kern <phil@philkern.de> Fri, 17 August 2012 16:53 UTC

Return-Path: <pkern@spike.0x539.de>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B6B21F85DD for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2012 09:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOtcml4DFarX for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2012 09:53:32 -0700 (PDT)
Received: from hub.kern.lc (hub.kern.lc [IPv6:2a00:1158:3::c7]) by ietfa.amsl.com (Postfix) with ESMTP id C02B821F84B9 for <v6ops@ietf.org>; Fri, 17 Aug 2012 09:53:32 -0700 (PDT)
Received: from [2001:470:720c:0:2567:7561:401d:6b98] (helo=spike.0x539.de) by hub.kern.lc with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <pkern@spike.0x539.de>) id 1T2Pn9-0005Od-CZ for v6ops@ietf.org; Fri, 17 Aug 2012 18:52:59 +0200
Received: from pkern by spike.0x539.de with local (Exim 4.80) (envelope-from <pkern@spike.0x539.de>) id 1T2Pnd-00034E-Oc for v6ops@ietf.org; Fri, 17 Aug 2012 18:53:29 +0200
Date: Fri, 17 Aug 2012 18:53:29 +0200
From: Philipp Kern <phil@philkern.de>
To: v6ops@ietf.org
Message-ID: <20120817165329.GA7568@spike.0x539.de>
References: <67832B1175062E48926BF3CB27C49B240674C2@xmb-aln-x12.cisco.com> <97EB7536A2B2C549846804BBF3FD47E10C3A2A@xmb-aln-x02.cisco.com> <001f01cd7a4e$d05c7390$71155ab0$@asgard.org> <EDA14A02-F441-44AA-B54A-FE0FE8C8C5B8@kumari.net> <20120817001116.AA2D123ABFA7@drugs.dv.isc.org> <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0"
Content-Disposition: inline
In-Reply-To: <000001cd7c8b$2fb8a1e0$8f29e5a0$@asgard.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [v6ops] [OPSEC] 3 Volunteers wanted - Draft: draft-gont-opsec-ipv6-implications-on-ipv4-nets
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 17 Aug 2012 16:53:33 -0000

Lee,

am Fri, Aug 17, 2012 at 11:15:49AM -0400 hast du folgendes geschrieben:
> Finally,
>    some transition/co-existence mechanisms (notably Teredo) are designed
>    to traverse Network Address Translators (NATs), which in many
>    deployments provide a minimum level of protection by only allowing
>    those instances of communication that have been initiated from the
>    internal network.  Thus, these mechanisms might cause an internal
>    host with otherwise limited IPv4 connectivity to become globally
>    reachable over IPv6, therefore resulting in increased (and possibly
>    unexpected) host exposure.  That is, the aforementioned technologies
>    might inadvertently allow incoming IPv6 connections from the Internet
>    to hosts behind the organizational firewall.

and how is that different from obtaining a global IPv4 through a VPN connection
to the outside? If you allow the UDP communication to the Teredo relays, you're
probably not stopping such VPNing neither. The lesson being that you need to
know what passes your organizational firewall and whitelist if you care about
that. But then I guess your point is that such tunnels are automatic and not
necessarily user-initiated. But that's an implementation detail with one
vendor's implementation… \:

Kind regards
Philipp Kern