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
- Re: [secdir] SECDIR review of draft-ietf-bess-pta… Christian Huitema
- [secdir] SECDIR review of draft-ietf-bess-pta-fla… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-bess-pta… Eric C Rosen
- Re: [secdir] SECDIR review of draft-ietf-bess-pta… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-bess-pta… Eric C Rosen
- Re: [secdir] SECDIR review of draft-ietf-bess-pta… Christian Huitema