Some additional comments on

Fernando Gont <fernando@gont.com.ar> Mon, 13 September 2010 02:36 UTC

Date: Mon, 13 Sep 2010 02:30:53 +0000
Message-Id: <E1Ouyon-000ODe-6p@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: Some additional 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,

Meta comment:
Being an ops I-D/RFC, I would expect some concrete advice on, e.g., how
to filter well-known tunneling mechanisms. IMO, one should be able to
answer the questions "How should I filter Teredo?", "How should I filter
6to4?", and others (without this being an invitation to do so).


Another specific comments:

> 6.  Additional Security Concerns
> 
> 6.1.  Attacks Facilitated By Changing Tunnel Server Setting
> 
> 6.1.1.  Problem

The I-D seems to assume that the tunnel endpoint *is* configured by
resolving a domainname, and that there's no workaround.

Firstly, while e.g. Windows does configure e.g. the Teredo server and
the 6to4 relay by resolving domain-names, this need not be the case.
Secondly, one could override such setting and eliminate *this* attack
vector by configuring a hardcoded IP address (e.g., the 6to4 anycast
address)

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

Some additional comments on Fernando Gont