[secdir] SecDir review of draft-ietf-v6ops-ra-guard-implementation-04

<kathleen.moriarty@emc.com> Thu, 12 July 2012 14:01 UTC

Return-Path: <kathleen.moriarty@emc.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBDA21F86B0; Thu, 12 Jul 2012 07:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level:
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 kP+4H7KMvpvG; Thu, 12 Jul 2012 07:01:04 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 930B221F8847; Thu, 12 Jul 2012 07:01:04 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6CE1SMl022618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jul 2012 10:01:29 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 12 Jul 2012 10:01:07 -0400
Received: from mxhub36.corp.emc.com (mxhub36.corp.emc.com [10.254.93.84]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6CE16jl014336; Thu, 12 Jul 2012 10:01:06 -0400
Received: from mx15a.corp.emc.com ([169.254.1.189]) by mxhub36.corp.emc.com ([::1]) with mapi; Thu, 12 Jul 2012 10:01:05 -0400
From: kathleen.moriarty@emc.com
To: secdir@ietf.org, draft-ietf-v6ops-ra-guard-implementation.all@tools.ietf.org, iesg@ietf.org
Date: Thu, 12 Jul 2012 10:01:05 -0400
Thread-Topic: SecDir review of draft-ietf-v6ops-ra-guard-implementation-04
Thread-Index: Ac1gNsc++cRE89ymRHadHZMhFDfvaw==
Message-ID: <F5063677821E3B4F81ACFB7905573F2403AAA236@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_F5063677821E3B4F81ACFB7905573F2403AAA236MX15Acorpemccom_"
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: fgont@si6networks.com
Subject: [secdir] SecDir review of draft-ietf-v6ops-ra-guard-implementation-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Jul 2012 14:01:07 -0000

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.

draft-ietf-v6ops-ra-guard-implementation-04 updates RFC6105 as a BCP.
   The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
   employed to mitigate attack vectors based on forged ICMPv6 Router
   Advertisement messages.  Many existing IPv6 deployments rely on RA-
   Guard as the first line of defense against the aforementioned attack
   vectors.  However, some implementations of RA-Guard have been found
   to be prone to circumvention by employing IPv6 Extension Headers.
   This document describes the evasion techniques that affect the
   aforementioned implementations, and formally updates RFC 6105, such
   that the aforementioned RA-Guard evasion vectors are eliminated.

Review Summary:
The draft is mostly ready (the draft introduces new requirements to protect against specific attack vectors and addresses them well), but I would recommend some stronger language in the Security Considerations section in the following areas:

In the start of the security considerations section, it says that 'advice' is given to correct the problems.  Reading through the draft this updates and this draft, would saying 'new requirements' or 'additional requirements' be better?  The updates proposed in this draft use RFC2119 language with MUST statements to correct a few issues (RA guards were not handling fragmentation or paying attention to IPv6 extension headers).

Also, to be compliant with this BCP, shouldn't the security considerations section just require compliance with RFC5722?  The indented paragraph in the security considerations section could be updated to state this requirement to make it a clear requirement from this draft.

Thank you,
Kathleen