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

Jeroen Massar <jeroen@unfix.org> Fri, 17 August 2012 16:58 UTC

Return-Path: <jeroen@unfix.org>
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 B0CC311E80A5 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2012 09:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 4YpSR8kW7kVU for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2012 09:58:18 -0700 (PDT)
Received: from icaras.de.unfix.org (icaras.de.unfix.org [IPv6:2a01:4f8:130:74c1:5054:ff:fec4:f7d4]) by ietfa.amsl.com (Postfix) with ESMTP id ECC3411E809B for <v6ops@ietf.org>; Fri, 17 Aug 2012 09:58:17 -0700 (PDT)
Received: from kami.ch.unfix.org (211-46.62-188.cust.bluewin.ch [188.62.46.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jeroen) by icaras.de.unfix.org (Postfix) with ESMTPSA id E7DE3801C2B5; Fri, 17 Aug 2012 18:58:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=unfix.org; s=DKIM2009; t=1345222696; bh=dlvyLiZ9ELtmBUI92hF1YombmXQ/ixlMZF7kDjv2ckk=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sJeBqCCXJue9wMOoucpMTY2vzADWkIOMnJhK0b4fRlehGRSTLHawdjmt9shYFyF48 LbBapTWpOA346WzG72wsGCwf/hddUBYoy+DGHchFZZE8RJOEj/xew6qpNHT95rBx8T xYPi7Chma7BpAvo2rY1JBSYl/LY/eNcALG2nl4wob7M0BDDYOwa8q7gQ9oxbIYABFL mn89eZyk4EmO1Z1m4Tyk2WvRIo5sR/p6afw6CnskfhGqLuwyqoP1dYJALK/X9s2WFK xfrePCjpqRR3k7mnaWeuk5ruZrykdY0PqWXKdKQaZZ80VKWlfJ0gf9bZE6Wtei7rkQ 6bBTHuhuf+XSg==
Message-ID: <502E7826.2080000@unfix.org>
Date: Fri, 17 Aug 2012 18:58:14 +0200
From: Jeroen Massar <jeroen@unfix.org>
Organization: Unfix
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Philipp Kern <phil@philkern.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> <20120817165329.GA7568@spike.0x539.de>
In-Reply-To: <20120817165329.GA7568@spike.0x539.de>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: v6ops@ietf.org
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:58:18 -0000

On 2012-08-17 18:53, Philipp Kern wrote:
> 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
[..]
> 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… \:

That one vendor you mean, being Microsoft, actually disables Teredo when
the host PC is inside an Active Directory/Windows domain, as such, this
covers most organizations. But even then, per default Teredo on Windows
is configured to not allow incoming connections when the standard
Windows Firewall is active.


And indeed, if you want to properly firewall, then you need to educate
your users and whitelist, anything else does not work as there are way
too many ways that one can get out and play...

Also note that the NAT there is obviously not a firewall, as it allows
any connection to be made and tunnels to be punched through it.

Greets,
 Jeroen