Re: [OPSEC] Call for Adoption: draft-gont-opsec-ipv6-nd-security-01

"George, Wes" <wesley.george@twcable.com> Wed, 11 September 2013 20:16 UTC

Return-Path: <wesley.george@twcable.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 CCF6511E822C for <opsec@ietfa.amsl.com>; Wed, 11 Sep 2013 13:16:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level:
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MgK6oXbl1+X for <opsec@ietfa.amsl.com>; Wed, 11 Sep 2013 13:16:09 -0700 (PDT)
Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A5F4C11E820C for <OpSec@ietf.org>; Wed, 11 Sep 2013 13:16:09 -0700 (PDT)
X-SENDER-IP: 10.136.163.13
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.90,886,1371096000"; d="scan'208";a="129938919"
Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 11 Sep 2013 16:14:04 -0400
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 11 Sep 2013 16:16:08 -0400
From: "George, Wes" <wesley.george@twcable.com>
To: Warren Kumari <warren@kumari.net>, "OpSec@ietf.org" <OpSec@ietf.org>, "draft-gont-opsec-ipv6-nd-security-01@tools.ietf.org" <draft-gont-opsec-ipv6-nd-security-01@tools.ietf.org>
Date: Wed, 11 Sep 2013 16:16:07 -0400
Thread-Topic: [OPSEC] Call for Adoption: draft-gont-opsec-ipv6-nd-security-01
Thread-Index: Ac6u+dfIXlfeJm2cQjGMqqbpvMrNTgALoKUg
Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923043A688E64@PRVPEXVS15.corp.twcable.com>
References: <522B3D9F-07EA-4595-80E4-50B406F0B3A0@kumari.net>
In-Reply-To: <522B3D9F-07EA-4595-80E4-50B406F0B3A0@kumari.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OPSEC] Call for Adoption: draft-gont-opsec-ipv6-nd-security-01
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, 11 Sep 2013 20:16:14 -0000

I think that this is worthwhile work for Opsec to undertake, because ND security is definitely something that not all vendors and SPs have a handle on yet, and it's really useful to have all of the information in one place to be able to point vendors at when trying to improve the state of ND security.

That said, I have some concern about the current format of this document vs. its name and intent. This is supposed to be a security assessment, but rather than simply identifying the current vulnerabilities, it also provides recommendations on how to secure against them. This is certainly good information that I support being in a document, we just need to decide if it belongs in this document and whether that drives a title and abstract change to reflect the document's purpose more accurately, or whether we want to split out mitigation from assessment.
The doc is currently informational, and does not include any RFC2119 boilerplate, but it makes recommendations for behaviors that are not explicitly required by the existing protocol implementation. Many of the places where "...should..." appears in the document look prescriptive/normative to me, and it's not always clear from the text/references whether this is simply reiterating what is already in the standard, or making a new recommendation for better security.

e.g. section 3.1: " If
   the packet does not pass this check, it should be silently dropped.

      While this is not explicitly required in [RFC4861] this provides
      an additional counter-measure (other than the validation of the
      Hop Limit) for non-local malicious nodes willing to make use of
      Router Solicitation messages for reconnaissance purposes."

Perhaps BCP would be a better choice, or info with 2119 keywords, I don't know.

I'd also recommend moving the current section 6 much earlier in the document, so that you start by discussing the vulnerabilities, and then you can go into the recommendations on ND validations (current section 3). I'm not sure how sections 4 and 5 fit into that framework, since they appear to be talking about vulnerabilities as well, but I know that the current one doesn't seem very intuitive to me.


Thanks,

Wes George




> -----Original Message-----
> From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf
> Of Warren Kumari
> Sent: Wednesday, September 11, 2013 10:17 AM
> To: OpSec@ietf.org; draft-gont-opsec-ipv6-nd-security-01@tools.ietf.org
> Cc: Warren Kumari
> Subject: [OPSEC] Call for Adoption: draft-gont-opsec-ipv6-nd-security-01
>
> Dear OpSec WG,
>
> This starts a Call for Adoption for draft-gont-opsec-ipv6-nd-security-
> 01.
>
Anything below this line has been added by my company's mail server, I have no control over it.
-----------------

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.