secdir review of draft-ietf-v6ops-scanning-implications-03

Jeffrey Hutzelman <jhutz@cmu.edu> Wed, 31 October 2007 23:14 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMlY-0007yL-5C; Wed, 31 Oct 2007 19:14:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InMlW-0007xu-PB for ietf@ietf.org; Wed, 31 Oct 2007 19:14:26 -0400
Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1InMlR-0002gE-Gi for ietf@ietf.org; Wed, 31 Oct 2007 19:14:26 -0400
Received: from minbar.fac.cs.cmu.edu ([127.0.0.1]) by minbar.fac.cs.cmu.edu id aa19249; 31 Oct 2007 19:13 EDT
Date: Wed, 31 Oct 2007 19:13:35 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
X-X-Sender: <jhutz@minbar.fac.cs.cmu.edu>
To: ietf@ietf.org, secdir@mit.edu, tjc@ecs.soton.ac.uk, fred.baker@cisco.com, kurtis@kurtis.pp.se
Message-ID: <Pine.LNX.4.33L.0710311841370.7282-100000@minbar.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: jhutz+@cmu.edu
Subject: secdir review of draft-ietf-v6ops-scanning-implications-03
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document discusses implications of IPv6's larger address space and
larger typical subnet size for traditional network address range scanning
techniques often used to identify nodes.  It discusses other methods which
may be used by attackers to discover IPv6 notes, approaches that can be
used by network administrators to counter them, and techniques by which
adminstrators can take advantage of IPv6's large address apace to make it
harder to identify potential targets for attack.

This document provides a lot of good advice on how to make node addresses
on an IPv6 network difficult to discover.  That is, it discusses ways to
obscure addresses.  According to traditional wisdom, "security through
obscurity is worse than no security at all".  Put another way, obscuring
addresses can be a useful tool in building a defense-in-depth, but relying
solely on obscurity of node addresses is asking for trouble.  I would like
this point stressed in the security considerations for this document,
possibly including references to other sources on techniques that can be
used to secure hosts, communication between hosts, and/or network access.

-- Jeff


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf





s are now combined with the Single Unix
> Specification, maintained by the Open Group, which provides an HTML
> version free of charge on its website.
>
> http://www.opengroup.org/
>
> There may be a free registration procedure required to obtain access.
>
> ---Tom


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf