Re: [Stackevo] Fwd: New Version Notification for draft-hardie-path-signals-02.txt

Martin Thomson <martin.thomson@gmail.com> Wed, 03 January 2018 22:26 UTC

Return-Path: <martin.thomson@gmail.com>
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 77D491273E2 for <stackevo@ietfa.amsl.com>; Wed, 3 Jan 2018 14:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_MUTUALBENEFIT=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aRGdZKBHvmLc for <stackevo@ietfa.amsl.com>; Wed, 3 Jan 2018 14:25:59 -0800 (PST)
Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C80F126BF7 for <stackevo@iab.org>; Wed, 3 Jan 2018 14:25:59 -0800 (PST)
Received: by mail-ot0-x22b.google.com with SMTP id d10so2497130oti.7 for <stackevo@iab.org>; Wed, 03 Jan 2018 14:25:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ec3cvMZKhXkWQ1g5C3d3/gJTs1yiJvVauIcfI5ZBcZY=; b=H+3NgbBjyUSa7bUn5S324I/E3PdDMY8qB5QoK4WxsKAFxdVAGeLwXUGUCRybq5pivX F3lVcMAaBC1sz9JKS7xr9xvv3QhC+m4pcANe8/sjgyAQghmzKi6HzbY5PpPj+e7JtJRL CwgNLiszFAfiNJWzC4XFFaKLKVUSl0K9vAHvxEZwNuVtzWRSHXrfl8QeF2OopPCjaKk5 PK8TYi3Ah4BuPq4J8nnJ0uvYwvhOTDO4R9+F22V8hcBFB2c7lrI23Q4izYCwG9/hbkWq TCJ3dlBYyqoU3EAbZDRb3jg15uHrL4Np5/B62XPh5M3YlxRltkEDO3oEGl/RjnX8O0Ne nSGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ec3cvMZKhXkWQ1g5C3d3/gJTs1yiJvVauIcfI5ZBcZY=; b=NQ2P7fHn1pDoYAbhRywjkFIvSYQxEHWv5bxapEhZMOOSWeVoNcpo/oibMpR4xYzybo cpZX7Qv+UmNSE7pQbp0cOxma8W+DXrJZPrTsSW7ucuoYVhfSdH9KjFfoQcBJJkodq7t3 xKOWLFm4lQPBzDd7+rQ1R8HgCf+PXenkpYf9Yxa4n64HGuSAs66kVowYdz2lH96wjuwj OBER0ZCS7RSqGJAtPvdLaqtRt1aUuHVksL70Vsfj4afoaXStp2Dm1wtHgueedS+liIvV lTv5ZDP9N/iA0HTQ/xi6JQ6XAy0ovx2rvtw3hgvh1etGVFpXki9LNZlA7ajLyYBk62H9 9o6w==
X-Gm-Message-State: AKGB3mKiQacnvQvirAinq5/UpmYRhopXJmtJMtbgy0h2Yvc/OHC03eE5 kcFAYiynQiGkR7DpjC5aJFWZgw3HOWBc7lcjCYI=
X-Google-Smtp-Source: ACJfBovKA28mtz49JUX9fQS8MOatsBh6Nj/HQuHAhWX0Zgz8UpKVmklcYW5dtRvo1lWDAURDjnZ7sYVUIHn4WldYjLo=
X-Received: by 10.157.88.140 with SMTP id x12mr1620746otg.175.1515018358539; Wed, 03 Jan 2018 14:25:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.46.182 with HTTP; Wed, 3 Jan 2018 14:25:58 -0800 (PST)
In-Reply-To: <42a159ed-f104-49fa-264e-d530356655dc@cisco.com>
References: <151208514657.11969.10317537698734955463.idtracker@ietfa.amsl.com> <CA+9kkMAFdXX2YJ=pBiMc5Jsp7GwkW+ovcn-dwiMZE9DK_cmsbA@mail.gmail.com> <1809c3fe-78b4-a151-87e5-b42c9c0c6f9c@cisco.com> <CABkgnnVV66b=L8o7DKFayLb85eRGjfBzP8vWOTufsWgc2xyf2Q@mail.gmail.com> <42a159ed-f104-49fa-264e-d530356655dc@cisco.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 04 Jan 2018 09:25:58 +1100
Message-ID: <CABkgnnUY1_uaitrm2ihFRat_T_nLx_7ApvMeeR4p3s__eo0+pQ@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Stackevo <stackevo@iab.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/MGuhAYu1lkWqSr-qQMBkSx7osqc>
Subject: Re: [Stackevo] Fwd: New Version Notification for draft-hardie-path-signals-02.txt
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: Wed, 03 Jan 2018 22:26:00 -0000

On Thu, Jan 4, 2018 at 3:33 AM, Eliot Lear <lear@cisco.com> wrote:
>> I don't think that we need any specific mitigation, but we should
>> recognize that this is a natural consequence of the recommendations in
>> the draft.  That isn't strictly a negative outcome either.  One
>> conceivable - but actually highly unlikely - outcome of designing
>> explicit signals is that intermediaries might insist on a certain set
>> of signals before a packet is allowed to pass ("give me SNI or I kill
>> your flow").  A signal that isn't directly coupled to the actual
>> protocol machinery can be falsified to appease a middlebox, even in
>> cases where the endpoint might otherwise prefer not to provide the
>> information.  I wouldn't include all that exposition though, just note
>> that falsification is possible, without affecting the e2e protocol
>> operation.
>
> I think it's probably worth expanding this point.  Falsification of
> signaling means that middleboxes will not trust it.  To what degree that
> holds true will depend on circumstances, but if it becomes the general
> case, one has to ask what the point of including it was in the first
> place?  That way lies dragons.

That's why I think we are better avoiding saying anything.  The value
of signals will depend greatly on whether endpoints provide accurate
values, and that in turn will depend on the consequences that are
attached to either faithful or falsified values.  I can't predict the
outcome, which remains the big open question in this entire space.
It's certainly true that there is a case for mutual benefit to be
gained by filling explicit signals accurately, but it's not clear if
the gains are as well understood as for other voluntary things, such
as using a sane congestion control algorithm [1].

[1] Side discussion for bonus credit: In TCP, an endpoint that fails
to observe proper sender behaviour with respect to congestion control
can be managed in the network by terminating their TCP connections.
End-to-end protection of the transport prevents that.