[OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning
Rama Darbha <radarbha@cisco.com> Tue, 06 November 2012 02:53 UTC
Return-Path: <radarbha@cisco.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6281D21F85A8 for <opsec@ietfa.amsl.com>; Mon, 5 Nov 2012 18:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stbuI5l2seZ7 for <opsec@ietfa.amsl.com>; Mon, 5 Nov 2012 18:53:36 -0800 (PST)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 9302121F8457 for <opsec@ietf.org>; Mon, 5 Nov 2012 18:53:36 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA62rZwZ005106 for <opsec@ietf.org>; Mon, 5 Nov 2012 21:53:36 -0500 (EST)
Received: from rtp-radarbha-8712.cisco.com (rtp-radarbha-8712.cisco.com [10.116.50.243]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA62rZvk018401 for <opsec@ietf.org>; Mon, 5 Nov 2012 21:53:35 -0500 (EST)
Message-ID: <50987BAF.60909@cisco.com>
Date: Mon, 05 Nov 2012 21:53:35 -0500
From: Rama Darbha <radarbha@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: opsec@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 07 Nov 2012 06:46:52 -0800
Subject: [OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsec>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2012 23:59:06 -0000
To Opsec Subscribers, I originally emailed the feedback below directly to Fernando Gont and he requested I provide the feedback directly to the alias. I have some feedback regarding this document. I feel documents like this are primarily used by industry professionals as guides to secure their networks. As a result, my feedback pertains specifically to helping network administrators better apply the knowledge outlined in your RFC: 3.1.3. Manually-configured addresses "This is typically the case for IPv6 addresses assigned to routers, since routers do not employ automatic address configuration." I would not state that routers do not universally employ automatic address configuration. In order to state that, I would at least suggest referencing an RFC where it is not recommended to use automatic address configuration. One of the functions of IPv6 is its "plug-and-play" nature. I feel a statement like this may be misinterpreted by the more general audience. "On the other hand, the search space for IPv6 wordy-addresses is probably larger and more complex, but still greatly reduced when compared to the original 64- bit search space." The terminology used in this sentence does not sound technically confident. Words like "probably" make the sentence sound unimportant. I understand what you're getting across, but the sentence itself doesn't feel technically strong. 3.2. IPv6 address scanning of remote area networks "While in IPv4 networks attackers have been able to get away with "brute force" scanning attacks (thanks to the reduced search space), successfully performing a brute-force scan of an entire /64 network would be infeasible. " When I first read this, I immediately agreed that performing a brute-force attach on a /64 network would be infeasible. But then I started to reflect on why it would be so infeasible? Computers are getting faster, and NICs have more capacity, so their ability to create faster mappings scales in relation. Do we have current research numbers to state how long it takes to do a brute force scan of a /64? I think referencing research would go a long way to convincing readers of this statement. "Unfortunately, a number of IPv6 implementations have been found to be unable to properly handle large number of entries in the Neighbor Cache, and hence these address-scan attacks may have the side effect of resulting in a Denial of Service (DoS) attack [CPNI-IPv6] [I-D.ietf-v6ops-v6nd-problems]." It might be worth mentioning that stateful devices in the network path, like firewalls, will track neighbour cache and connection information. Since these values are so much larger in IPv6, these intermediate devices are also subject to such DoS vulnerabilities. I am new to providing feedback on IETF documentation. So let me know if I've missed the mark on this email. I don't know the exact format or procedures for providing this feedback but I thought there would be no harm in emailing the authors directly with my thoughts. Regards, Rama -- Rama Darbha, CCIE#28006 919-574-5071 radarbha@cisco.com Cisco TAC - Security Solutions RTP, NC, USA Hours: 8h30 - 17h00 (EST) http://www.cisco.com/tac/
- [OPSEC] Mail regarding draft-gont-opsec-ipv6-host… Rama Darbha
- [OPSEC] Mail regarding draft-gont-opsec-ipv6-host… Rama Darbha
- Re: [OPSEC] Mail regarding draft-gont-opsec-ipv6-… Gert Doering
- Re: [OPSEC] Mail regarding draft-gont-opsec-ipv6-… Rama Darbha