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
- secdir review of draft-ietf-v6ops-scanning-implic… Jeffrey Hutzelman