Re: deprecating Postel's principle- considered harmful

Dave Cridland <dave@cridland.net> Wed, 08 May 2019 14:17 UTC

Return-Path: <dave@cridland.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA5312011C for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 07:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
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 ODOgjo4ENY9Y for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 07:16:58 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 9E1DD12010C for <ietf@ietf.org>; Wed, 8 May 2019 07:16:58 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id l25so22224941eda.9 for <ietf@ietf.org>; Wed, 08 May 2019 07:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HkWfVLPzDK2HHkbxa0G4tsbXteDEqDK0LvBMEVlvNC0=; b=G/ELzkJjwrEwViJ4jcYbobC9WF0zjYl/xwuRpRvMbbCgYaKXU1cS8qtLvGlk/YhEDa zi1GEZxxPveWfLxdykRFbJ/x5CFKtoxucY43nO4fnpe1qB6MkRKseVNt3pyfAglOLCXR H4PH1lD+jikuWwTHvcif1p/DQef0ypWdVqbVE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HkWfVLPzDK2HHkbxa0G4tsbXteDEqDK0LvBMEVlvNC0=; b=LAYbopB4SjR7uVTKorZVIknu85SMQlCclQnTOOs96zgutwF7l9ZmnSjlVrSZxxVYV3 cobL38B7ZhgS6/GtV6Itdv3cE43VxFmqf/l3JMm3ZPSDwHp+xXF0P4kVEt41rkhX0/Q7 KC5X1MRm8a/GqjYLzuaQwifOpXJAx5YFW58Y7DJy9+XB9MJvltubAIkeGBs7wDvoD5BM KX3vjv5aJb2A6JIluT/eXcN6Tzu8/I5bb35QdNx5Dd3JX3PZuoUX8FkirL7huOtY14jN m20Hh2wciiLtX4qqSPpi0WPcNrAGnQkJ+WzufOyYZFTIqulDtr9AxYd4SHKrmOi8Oeik Md9A==
X-Gm-Message-State: APjAAAWeBtKx0TSBtgJu5fEzErFEzE0Lc7bCoLniL4QS5z6YCZZgXJun x+czl3lgmNKgHZVLfI+YDFOQqPgmTyUf2LWetecLjg==
X-Google-Smtp-Source: APXvYqxI/8KMNCaU++TTxYVx4y2SVpmpPnqlqMSnRpZ5isf6ghr3hpMHhVfwTsCps3N3JWjeZxAvZPjA4lddH0m/BhU=
X-Received: by 2002:a50:b78b:: with SMTP id h11mr39207788ede.134.1557325017115; Wed, 08 May 2019 07:16:57 -0700 (PDT)
MIME-Version: 1.0
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <DBD4837F-299B-497C-8922-AFF858B06C0F@strayalpha.com> <CAKHUCzwa89Qd6PD2EtkZU1LnT+1ZSsNiMQGAPnu5P_r=bvgMLg@mail.gmail.com> <alpine.LRH.2.21.1905081009330.4912@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1905081009330.4912@bofh.nohats.ca>
From: Dave Cridland <dave@cridland.net>
Date: Wed, 08 May 2019 14:16:40 +0100
Message-ID: <CAKHUCzw1fc0yhS9XjFNtcw7xiv-tRdfDwVvYDo27gNKp5q8MxA@mail.gmail.com>
Subject: Re: deprecating Postel's principle- considered harmful
To: Paul Wouters <paul@nohats.ca>
Cc: Joe Touch <touch@strayalpha.com>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007200e3058860fc37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/V9u6Jqdqb6okfcE5bQw4jHkCRFk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2019 14:17:01 -0000

On Wed, 8 May 2019 at 15:11, Paul Wouters <paul@nohats.ca> wrote:

> On Wed, 8 May 2019, Dave Cridland wrote:
>
> > Sure about that?
> >
> > From RFC 760:
> >
> > That is, it should be careful to send well-formed datagrams, but should
> accept any datagram that it can interpret (e.g., not object to technical
> errors where
> > the meaning is still clear).
> >
> > The parenthetical example is explicitly stating that a datagram with a
> technical error should still be accepted.
>
> Many UDP encapsulations of IP packets do not recalculate the outer UDP
> checksum. It's a good thing we accept these datagrams with technical
> errors.
>

There's two observations to be made here, if I understand correctly:

a) The lack of properly checking the outer UDP checksum means that
implementations could avoid recalculating it.

b) We could not enforce such checking now, because of such implementations.

I appreciate what you're saying, but it's unclear if either is a good thing.

Dave.

>