Re: [arch-d] deprecating Postel's principle- considered harmful

Mark Andrews <marka@isc.org> Tue, 07 May 2019 23:52 UTC

Return-Path: <marka@isc.org>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B929C1202BA; Tue, 7 May 2019 16:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 h3k_6xU63Xzt; Tue, 7 May 2019 16:52:50 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1415120251; Tue, 7 May 2019 16:52:49 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 1EB073AB060; Tue, 7 May 2019 23:52:49 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D1E9E160075; Tue, 7 May 2019 23:52:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 922A8160074; Tue, 7 May 2019 23:52:48 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uhfA_Zwe1CuN; Tue, 7 May 2019 23:52:48 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D58CF160054; Tue, 7 May 2019 23:52:46 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CACgrgBahawkXbyXoYHbwYSkfCG9zxn6M8jgwswDpcFjfZVcffw@mail.gmail.com>
Date: Wed, 08 May 2019 09:52:42 +1000
Cc: Christian Huitema <huitema@huitema.net>, "ietf@ietf.org" <ietf@ietf.org>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>, "iab@iab.org" <iab@iab.org>, The IESG <iesg@ietf.org>, Barry Leiba <barryleiba@computer.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6095149F-F4BE-400D-BD1E-F25BC60FDA8A@isc.org>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <CAA=duU1TxZx9W8huPp5md25Wf+9=f50WYGpU=Bb1OQ+OdF6k6A@mail.gmail.com> <CACgrgBYs95Q4hb=y-6i7SW9mEx9Bg-gp0TrpAYpsP-aODSx+YA@mail.gmail.com> <eb979c24-e9d2-4ebb-1d4b-94b8c9aa16e1@huitema.net> <CACgrgBahawkXbyXoYHbwYSkfCG9zxn6M8jgwswDpcFjfZVcffw@mail.gmail.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/-4dQ1XNNGesAjZmcsv4cfBbANX8>
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 May 2019 23:52:56 -0000

The fix for that is to implement the new feature and get customers to log
bug reports against the other implementation.  It does work.  Even Fortune
500 companies listen to their customers.

Implementations can be fixed and with regular update mechanisms in place
the fixes do get deployed.

In early 2018 the open source DNS vendors declared a flag day on Feb 1, 2019.
We where no longer going to treat timeout as “the server doesn’t understand EDNS”.
I.e. we where intending to deliberately break interoperation with servers that
where stuck in the last century.  We set up a site where you could test your
servers to see if your servers where broken.   We also had that site report
a whole lot of other EDNS protocol violation.  You got RED if there was a
fatal fault, ORANGE if any other fault was detected and GREEN if the server
passed the test queries.  The number of sites which would get RED was << 1 in
10000.

We advertised this flag day, in a number of places.  The testing server got
overwhelmed and DNS vendors with broken servers got thousands of “this
site says your product is broken, when are you going to fix it” complaints.
Implementations got fixed and the fixes got deploy.  This included firewall
vendors fixing their default blocking rule.

https://ednscomp.isc.org/ has lots of graphs which show failures of various
populations of servers and how things changed in the lead up to Feb 1 and
later fixes being released and deployed.  In particular
https://ednscomp.isc.org/compliance/ts/au.optfail.html show Microsoft fixing
their servers (see the “echoed” line).  The Jan 28 was when they fixed their
Azure service.  The drop around April 11 is when fix pushed out in the March
patch Tuesday release started to take effect.

The March 1 failure spike was when one of the links from the testing site
started dropping DNS UPD packets but passed DNS TCP packets.  It took a
couple of days to track down the bad (wrong style for the conductor) RJ48
connector that caused that failure.

> On 8 May 2019, at 8:53 am, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
> 
> It's kind of the inverse robustness problem - lots of perfectly-well documented protocol features are not usable in practice since they break "lazy", but important, implementations. The SIP crowd will remember the endless discussions about MIME multipart.
> 
> In those cases, it would probably be wise to simply declare that a well-intentioned feature is no longer recommended for new implementations and possibly look for alternative options. (We seem to get into the circular arguments of "We need X", "use standard mechanism M to do X", "but none of the major implementations do M and are unlikely to in the foreseeable future", "but we cannot have two ways to do X and M is actually a better idea"; wait two years; repeat. Alternative: people develop a kludge that kind of works.)
> 
> The old, rarely-exercised, promotion-to-Draft-Standard step was supposed to catch this, but that process protocol path obviously was also rarely exercised.
> 
> Henning
>  
> 
> And then for a counter example, also related to IPv6. The IPv6 specs
> allows implementations to insert a variety of intermediate headers
> between the IPv6 header and the transport packet, but many router
> implementations just don't like that and slow down or drop packets if
> such intermediate routers are present. A case where the spec is arguably
> too permissive, or the implementations too strict.
> 
> -- Christian Huitema
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org