[OPSEC] Mail regarding draft-gont-opsec-ipv6-host-scanning

Rama Darbha <radarbha@cisco.com> Wed, 07 November 2012 13:43 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 3778F21F85E2 for <opsec@ietfa.amsl.com>; Wed, 7 Nov 2012 05:43:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.252
X-Spam-Level:
X-Spam-Status: No, score=-10.252 tagged_above=-999 required=5 tests=[AWL=0.347, 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 vw0AFbzT+PYd for <opsec@ietfa.amsl.com>; Wed, 7 Nov 2012 05:43: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 24FD221F85DA for <opsec@ietf.org>; Wed, 7 Nov 2012 05:43: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 qA7DhV16017596; Wed, 7 Nov 2012 08:43:31 -0500 (EST)
Received: from dhcp-10-150-53-244.cisco.com (dhcp-10-150-53-244.cisco.com [10.150.53.244]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA7DhVl1011739; Wed, 7 Nov 2012 08:43:31 -0500 (EST)
Message-ID: <509A6581.4030702@cisco.com>
Date: Wed, 07 Nov 2012 08:43:29 -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
Cc: Fernando Gont <fernando@gont.com.ar>
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: Wed, 07 Nov 2012 13:43:37 -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/