[spring] Benjamin Kaduk's Block on charter-ietf-spring-01-01: (with BLOCK)
Benjamin Kaduk <kaduk@mit.edu> Thu, 05 July 2018 12:57 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37670130E29; Thu, 5 Jul 2018 05:57:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: spring-chairs@ietf.org, spring@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153079545917.11265.16492788162863031098.idtracker@ietfa.amsl.com>
Date: Thu, 05 Jul 2018 05:57:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/r65pzWgyKMmEpVNBH8ObK0rLkSQ>
Subject: [spring] Benjamin Kaduk's Block on charter-ietf-spring-01-01: (with BLOCK)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.26
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 12:57:40 -0000
Benjamin Kaduk has entered the following ballot position for charter-ietf-spring-01-01: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-spring/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- This proposed charter has minimal text on security concerns, asserting that the scope is limited to a single trust domain and only applying a weak requirement to "strive to identify and address" security considerations brought up by its technologies. The text concerning a single trust domain seems to implicitly assume that there is thus no need for cryptographic assurance of the integrity and/or authenticity of origin for route information, a position whose accuracy remains unclear to me. A commitment to "strive" to do something is hardly any commitment at all, in that failing to do that thing remains consistent with the commitment. Additionally, the current charter text includes some security-related items, noting that "there are a number of serious security concerns with source routing at the IP layer", committing to define the SRv6 header so that blind attacks are never possible (and with options to provide additional security in some networks), and committing to provide a security analysis for each protocol being developed. Has anything changed in the intervening five years to render these items unnecessary? I don't see any justification for why these commitments are being abandoned.
- [spring] Benjamin Kaduk's Block on charter-ietf-s… Benjamin Kaduk