Re: [Stackevo] [IAB] draft-hardie-path-signals and draft-trammell-wire-image
Mark Nottingham <mnot@mnot.net> Thu, 05 April 2018 00:55 UTC
Return-Path: <mnot@mnot.net>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A671127077; Wed, 4 Apr 2018 17:55:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=0iUuTqBD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YimSyK0p
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 sWHYsS2gQsGx; Wed, 4 Apr 2018 17:55:27 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A118F1201F2; Wed, 4 Apr 2018 17:55:27 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 134C221E30; Wed, 4 Apr 2018 20:55:27 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 04 Apr 2018 20:55:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=SNDqs0cRGMAYT3FA4fqSEiB86dpWj 0qMKF0gFj0WpYw=; b=0iUuTqBDveDSj5DtlADq+pwJhUJn0ukzH+xPLrIcsQXOh JJM06gI79I639j5fPJRNHXxlhn7e5AXek/Gz6E7ZCv957hU39vzU4hf0cYlgN0RV eKe/Sif2lBCNa1+f7yIonh4zwZmcxJBelRWpRc+4Uxz9pCdMwCV8iIRrRYh+3lFL QaNM19cRikC5fxIqCWSOL4p77u2Vv6SUvJP+saZMv5SjQMSqQWXqtpqh1la7FPhO cgh1oNi2jmiugUrQb0Aon3pDFpt1FsruAPs8K2LqYaQZCK56i7EJuG9ywvPgZntd KLva9povk8bMuH1/01syzyzCF/najGI7x1fUH4aYg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SNDqs0 cRGMAYT3FA4fqSEiB86dpWj0qMKF0gFj0WpYw=; b=YimSyK0pgre1iNrv02zDy0 v94EFBDPis4FdoOplmjiG2tE5e3XQMlbqk/9gDErlFpf5mQJwgAGTz5eQFEVhIJq EwhjH1wbsar69vo/ISnu1Ay3gF9T9CPdE0rPcOw3rUDRf3GxruOrByuajzFvfQX7 KCsmquccfmRXgs92vxiF7ANOFjWUOH0mob7Sg7AlBx6mc9J8iN4MfF1EG2K2rTXj XRF3h0tb8O20EUvmiaR8+qvuUWPKX/8+AKqCLPbtxw5gb/Qm5MAZkQBceR5kjLNx mzmUjAPTXfZRMpC7EskoIXTzbDRx3qo6mevS99/e7651udz5cYRExIG+dRtHD/4Q ==
X-ME-Sender: <xms:_3PFWslhIGtCbNTp3ZD8X9SLI1M96MQJe8Z-ajyj9RvRKOlgBLvLkg>
Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id D79A010252; Wed, 4 Apr 2018 20:55:25 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <C986EAB5-CFE3-49AF-A19A-B087E63EE365@trammell.ch>
Date: Thu, 05 Apr 2018 10:55:23 +1000
Cc: IAB IAB <iab@iab.org>, Stack Evolution Program <stackevo@iab.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1641F7D4-E7E9-4A8D-88F2-3A07A0082AFD@mnot.net>
References: <C986EAB5-CFE3-49AF-A19A-B087E63EE365@trammell.ch>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/_HhCHV25TcDYvCxOQwrG6D0_Lso>
Subject: Re: [Stackevo] [IAB] draft-hardie-path-signals and draft-trammell-wire-image
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IP Stack Evolution Program Mailing List <stackevo.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo>, <mailto:stackevo-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo/>
List-Post: <mailto:stackevo@iab.org>
List-Help: <mailto:stackevo-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo>, <mailto:stackevo-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 00:55:30 -0000
Hi Brian, > On 4 Apr 2018, at 6:50 pm, Brian Trammell (IETF) <ietf@trammell.ch> wrote: > > Greetings, > > After discussion at our Friday morning London meeting (and thanks, all, on the program for your remarkable Stack Evolution Program would like the IAB to consider two documents for publication on the IAB stream: > > https://tools.ietf.org/html/draft-trammell-wire-image-03 I like this document. Two comments: * 1. Introduction seems to skip around a discussion of whether participants in lower-layer protocols are also participants in "higher" layer protocols -- i.e., is participation transitive? * 3.3.1. Invariants begs the question of what networks will do with the parts of the message that are *not* invariant, and the resulting strategies that protocol designers might take -- i.e., some form of encryption, greasing, etc. Not sure if we intend to publish a separate doc here, but it might be worth mentioning. > https://tools.ietf.org/html/draft-hardie-path-signals-03 Section 3 seems very good; the rest seems very... tentative. That's probably appropriate, except: * 4.3 Replace These With Per-Transport Signals - the last two sentences here seem very wishy-washy. In combination with 4.4, it feels like it's trying to steer towards a PLUS-like solution, but only justifying it in terms of vague impact upon ossification. Also, in 5. Recommendations, do we want to say anything about whether a protocol should *enable* path elements to add signals (at least within the protocol's control)? > The wire image draft describes what a protocol's wire image is, and explores the situations that arise when a protocol splits its visible wire image from the information it uses for its own operation. (It started as a draft I wrote during the extended Singapore plenary discussion on encryption of protocols, riffing off Ted's observation from the dais that protocols with explicit wire images were a completely new thing, in part to describe what I mean when I use the term.) > > The path signals draft recommends that protocol machinery be confidentiality protected, and that any signal exposed to on-path devices (outside confidentiality protection) be *explicitly* so exposed and integrity protected. It reiterates that metadata injection is considered harmful. > > Thanks, cheers, > > Brian (stackevo lead hat) Cheers, -- Mark Nottingham https://www.mnot.net/
- [Stackevo] draft-hardie-path-signals and draft-tr… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Martin Thomson
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Mark Nottingham
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Mark Nottingham
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Spencer Dawkins at IETF
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Mirja Kühlewind
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Martin Thomson
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Brian Trammell (IETF)
- Re: [Stackevo] [IAB] draft-hardie-path-signals an… Alissa Cooper
- [Stackevo] draft-thomson-use-it-or-lose-it Brian Trammell (IETF)
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Ted Hardie
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Brian Trammell (IETF)
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Ted Hardie
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Martin Thomson
- Re: [Stackevo] draft-thomson-use-it-or-lose-it Aaron Falk