[secdir] secdir review of draft-ietf-mpls-ipv6-only-gap-02

Tobias Gondrom <tobias.gondrom@gondrom.org> Wed, 22 October 2014 22:16 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 748281A875A; Wed, 22 Oct 2014 15:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.665
X-Spam-Status: No, score=-96.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yKbR2DFx1FJC; Wed, 22 Oct 2014 15:15:58 -0700 (PDT)
Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35161A8028; Wed, 22 Oct 2014 15:15:58 -0700 (PDT)
Received: from [] (bcdefac2.skybroadband.com []) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 2ECDC62C1F; Thu, 23 Oct 2014 00:15:56 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=I6rY+HGPWKPb2zya+tky4f5TQZGB+c/Kn3oY+o2FoOgkmqHwnxhzlJTeOS7y5pK1VTdihJ4oPog9bw8c/mtzrH5A074hEFBFrCUENtV0vdpQHElV2v9FHXG3/j4XMpq5nAEh4oQLaIBeDhdO9g93BgDFGW2w3Uu8qXuvN2c37oM=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Message-ID: <54482C9B.6070703@gondrom.org>
Date: Wed, 22 Oct 2014 23:15:55 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: draft-ietf-mpls-ipv6-only-gap.all@tools.ietf.org, iesg@ietf.org
References: <53E00686.7030909@gondrom.org>
In-Reply-To: <53E00686.7030909@gondrom.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/0lbCR87E0m2UuM4t7hpS8WWaZmE
Cc: secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-mpls-ipv6-only-gap-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 22 Oct 2014 22:16:00 -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.

The draft is informational and identifies and analyses gaps that must be 
addressed in order to allow MPLS-related protocols and applications to 
be used with IPv6-only networks.

The document appears ready for publication.

The security considerations section (section 8) only states that 
changing the address family used for MPLS network operation does not 
fundamentally alter the security considerations of the existing 
protocol. Which is basically correct. It could have been interesting to 
look at the gaps analysis from a security perspective and see which of 
the MPLS IPv6-only gaps has security implications that need to be 
addressed. I.e. which gaps are security related. However, that is not 

1. Abstract and Section 1:
the sentence "This document is not intended to highlight a particular 
vendor's implementation (or lack thereof)" sounds odd. Is there a WG 
discussion background or why is this document speaking of one 
"particular vendor's implementation"?

- section EVPN
formating: do you want to add one line at the end of the section: "Gap: 

I did not find anything else in my review.

Thank you and best regards.