Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt

"Christian Huitema" <huitema@huitema.net> Sun, 24 April 2016 23:29 UTC

Return-Path: <huitema@huitema.net>
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 A72B912D17A for <secdir@ietfa.amsl.com>; Sun, 24 Apr 2016 16:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IUQJLsE-ynC for <secdir@ietfa.amsl.com>; Sun, 24 Apr 2016 16:29:07 -0700 (PDT)
Received: from xsmtp04.mail2web.com (xsmtp04.mail2web.com [168.144.250.231]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6127E12B01B for <secdir@ietf.org>; Sun, 24 Apr 2016 16:29:07 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1auTSb-0007Zz-JL for secdir@ietf.org; Sun, 24 Apr 2016 19:29:06 -0400
Received: (qmail 25382 invoked from network); 24 Apr 2016 23:29:04 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-bess-pta-flags.all@ietf.org>; 24 Apr 2016 23:29:04 -0000
From: Christian Huitema <huitema@huitema.net>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bess-pta-flags.all@ietf.org
Date: Sun, 24 Apr 2016 16:29:00 -0700
Message-ID: <033501d19e81$1697ec40$43c7c4c0$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdGegQTs2dkO8CpOSNm3gn0kEh7hDg==
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/NX2SnpPqRpQrTHTBXFtFUun5JFs>
Subject: Re: [secdir] SECDIR review of draft-ietf-bess-pta-flags-02.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 24 Apr 2016 23:29:08 -0000

Resending with the proper IESG address. Sorry.
=================================================
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 document is ready with issues.

The document defines an extension mechanism for the "flags" field in the
"P-Multicast Service Interface Tunnel (PMSI Tunnel) attribute" used to carry
information in BGP about multicast routing inside VPN. RFC 6514 describes an
8-bit flag, with 7 bits reserved and 1 bit defined. The draft reserves one
of the 7 bits as an extension mark, and proposes to create an IANA registry
for the remaining 6 values, and for the values of the newly defined
extension field.

The draft is pretty simple, but it poses the generic issue of extensions.
What happens if some routers in a domain are aware of the newly assigned
extension and some are not? The authors argue that this behavior is properly
defined in the documents describing the future extensions. This is
plausible, but the draft does define a generic mechanism, and does switch
the meaning of one of bits marked as "reserved" in RFC 6514. We have thus
two possible issues:

1) A router supports RFC 6514 but does not implement the extension
mechanism.
2) A router supports the extension mechanism, but does not support the
specific extension.

I am able to guess a plausible behavior based on the text in the draft and
the reference to " Treat-as-withdraw" option of RFC 7606, but I would much
prefer if there was a recommended behavior in the draft. 

-- Christian Huitema