Comments on draft-ietf-v6ops-tunnel-security-concerns
Fernando Gont <fernando@gont.com.ar> Mon, 13 September 2010 00:22 UTC
Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504053A689D for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 12 Sep 2010 17:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.856
X-Spam-Level:
X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgjVhH6dWliB for <ietfarch-v6ops-archive@core3.amsl.com>; Sun, 12 Sep 2010 17:22:47 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 04FC03A672F for <v6ops-archive@lists.ietf.org>; Sun, 12 Sep 2010 17:22:47 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Ouwir-000F3C-Rp for v6ops-data0@psg.com; Mon, 13 Sep 2010 00:16:37 +0000
Date: Mon, 13 Sep 2010 00:16:37 +0000
Message-Id: <E1Ouwir-000F3C-Rp@psg.com>
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: draft-ietf-v6ops-tunnel-security-concerns@tools.ietf.org
CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Comments on draft-ietf-v6ops-tunnel-security-concerns
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>
Folks, * Abstract (nit): > The primary intent of > this document is to raise the awareness regarding the security issues > with IP tunnels as deployed today. s/the awareness/awareness/ * Section 2.1.3: > Security administrators who do not consider tunneling an acceptable > risk should disable tunnel functionality either on the end-nodes > (hosts) or on the network nodes. However, there may be an awareness > gap. Thus, due to the possible negative security consequences, we > recommend that explicit user action be required to enable tunneling, > at least for the first time. If tunnels are a concern to the secadmin, they should be disabled at the perimeter. The sec admin has no control over, e.g. a user that connects his laptop to the enterprise network. * Section 2.1.3 > For example, when Teredo is being enabled or when it is going to be > used for the first time, there could be a descriptive warning about > the possible reduction of defense in depth that will occur. This makes sense for a technically-savvy user. The typical non-technical user will simply press "Ok". * Section 2.2.2 You never talk about filtering incoming packets based on their source address. i.e., you should not allow packets with a source address that belongs to your network to enter your network from the outside. * Section 2.2.3 > Tunnel clients should by default discard tunneled IP packets that > specify additional routing, as recommended in [RFC5095], though they > may also allow the user to configure what source routing types are > allowed. All pre-existing source routing controls should be upgraded > to apply these controls to tunneled IP packets as well. RFC 5095 talks about IPv6 "source routing". You should also be concerned about IPv4 source routing. See: * http://www.cpni.gov.uk/Docs/InternetProtocol.pdf * draft-ietf-opsec-ip-security * Section 3.1.3 You don't mention filtering proto 41 packets * Section 3.2.2 > For some protocols, it may be possible to monitor setup exchanges to > know to expect that data will be exchanged on certain ports later. > (Note that this does not necessarily apply to Teredo, for example, > since communicating with another Teredo client behind a cone NAT > device does not require such signaling. However, deprecation of the > cone bit as discussed in [RFC4380] means this technique may indeed > work with Teredo.) Even with deprecation of the cone-bit, you don't want a user with a customized or legacy Teredo implementation to bypass these controls. So security-wise, this control "does not work". * Section 4.2.2: > 2. In some protocols (e.g., Teredo), the external IP address and > port are contained in the client's address that is used end-to- > end and possibly even advertised in a name resolution system. > While the tunnel protocol itself might only distribute this > address in IP headers, peers, routers, and other on-path nodes > still see the client's IP address. Although this point does not > apply directly to protocols (e.g., L2TP) that do not construct > the inner IP address based on the outer IP address, the inner IP > address is still known to peers, routers, etc. and can still be > reached by attackers without knowing the external IP address or > port. This is actually worse: the addresses might be stamped in, e.g. SMTP envelopes. See Fred Baker's I-D on greynets. Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
- Comments on draft-ietf-v6ops-tunnel-security-conc… Fernando Gont