Some additional comments on

[Fernando Gont <fernando@gont.com.ar>]

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