Re: [arch-d] Chaff in protocols

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 29 June 2019 23:41 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 AED6A120058 for <architecture-discuss@ietfa.amsl.com>; Sat, 29 Jun 2019 16:41:07 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 aSd5F3DD-XCU for <architecture-discuss@ietfa.amsl.com>; Sat, 29 Jun 2019 16:41:05 -0700 (PDT)
Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (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 5BAE812001E for <architecture-discuss@ietf.org>; Sat, 29 Jun 2019 16:41:05 -0700 (PDT)
Received: by mail-pl1-x643.google.com with SMTP id a93so5288998pla.7 for <architecture-discuss@ietf.org>; Sat, 29 Jun 2019 16:41:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=giBpUw/CgTSirs80GKUSxZTHfRaRkzNZS1Mkz3OjhfQ=; b=HtaRXn+hNLvEUFfUwIX3Z+D9vGMIbABQc29caTmY8cHBEFhKS+JFbHjc8jS0BoF66+ HbJNknfQDFlL/dm+kTMYbTCd9NaAo34GlItamqr/e8kKLPV9K1DzhO/VXb/GSrZg/SJm 4Zzee6kz8ndgKBTd7xLKqBHC2ZoCh87BYCYLm9niZlXz155+PfngGJRBGt/Tggbd22tw kVE2l5GetQy1zCrbHZ/0f+GXoU5PqiVom86IypQEsP02VZCwvCKtOkz7sqJHo8G7KLMn Si/UgAh79Mffhbedhtn7Hh+vffXv1pelc645ZXAPn0bxPuwNi+QfspvA8HFbYRsabHVP AURw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=giBpUw/CgTSirs80GKUSxZTHfRaRkzNZS1Mkz3OjhfQ=; b=Nu9/ABuEui+W9RDtrw+VWCAyTgcWDTRvPsP5shje6BAMj4xq2ujH7NZFUgaTNmZJ9b NhOaMnoZFJi/fLI6wJhfpShPk9G907g0EoGnybXmA4lMyKyP88YPzOu4s1M/cwB5M1TN IE4awFrO2T4h00v5XY1PGSR0RXrEyzFC59uPJzpP6blxGfir6CF7c5rIBueiDJMDdWEA ZMV6Hkqg5OahVkVbgaDfEj8NF1Y2CNZRxahXSyldej0M7BaLx7YiiHz3KUJ+Ei2pw10l dZhOKAe/m2KnZEi4feEU2P9XCyR4GRVhLN5P9543Q0HZkygMG5O7bBTUJZV0hOZOW0Wk D5cw==
X-Gm-Message-State: APjAAAW6j32OX0Wn7KBgn5Vn/9UzqLRj5EpWNNTqQQqRsWYgtjJ8AZ2g vCN29pdDbQRLftxedVMUuk9P4Lxe
X-Google-Smtp-Source: APXvYqzhWFFgIitCaURCu9xVQuoT8l18Wv0TwZc3JfG/j2nXcxi9UOCrq97dXhkDsidSJdp7gsyqNw==
X-Received: by 2002:a17:902:165:: with SMTP id 92mr20575687plb.197.1561851664535; Sat, 29 Jun 2019 16:41:04 -0700 (PDT)
Received: from [192.168.178.30] (32.23.255.123.dynamic.snap.net.nz. [123.255.23.32]) by smtp.gmail.com with ESMTPSA id i36sm5223736pgl.70.2019.06.29.16.41.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jun 2019 16:41:03 -0700 (PDT)
To: Martin Thomson <mt@lowentropy.net>
References: <a33aad56-7ca9-4913-98a7-dd96113815e7@www.fastmail.com> <CANMZLAbfkh+cNanqBExWOe=O6TspnufCnQKt=CF_aK__xDC3Mg@mail.gmail.com>
Cc: architecture-discuss@ietf.org
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <5d84a5a6-41b7-d302-607b-0b0cd7ec554c@gmail.com>
Date: Sun, 30 Jun 2019 11:41:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CANMZLAbfkh+cNanqBExWOe=O6TspnufCnQKt=CF_aK__xDC3Mg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/7TRrjghDb1yx2IwQ_feeDw9cFEY>
Subject: Re: [arch-d] Chaff in protocols
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: Sat, 29 Jun 2019 23:41:08 -0000

On 27-Jun-19 16:13, Martin Thomson wrote:
 
> Esteemed colleagues,
> 
> The IAB is looking for historical examples of deliberate additions to
> a protocol that are added not to enable new behaviour, but to test
> that the ability to do so remains viable.
> 
> This comes up in the context of assessing the concept of "grease" (see
> draft-ietf-tls-grease), a practice of adding meaningless extension
> points to messages in the hope that it will reveal, and perhaps
> prevent, intolerance toward real extensions.  This is a practice we
> have seen deployed with some success in TLS.  That has produced some
> enthusiasm about the practice.  I think that it would be fair to say
> that the IAB maintains some reservations about the general
> applicability of the technique.
> 
> Are there protocols (in either specification or deployment) that have
> experimented with this sort of thing in the past?

This isn't exactly what you're describing, but https://tools.ietf.org/html/rfc7872 (Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World) seems relevant. IMHO, IPv6 extension headers are an *unintentional* form of chaff by their design.

Recent proposals for piggy-backed OAM options seem to be continue this. See draft-ioametal-ippm-6man-ioam-ipv6-options, draft-ioametal-ippm-6man-ioam-ipv6-deployment.
  "In order for IOAM to work in IPv6 networks, IOAM MUST be explicitly
   enabled per interface on every node within the IOAM domain.  Unless a
   particular interface is explicitly enabled (i.e. explicitly
   configured) for IOAM, a router MUST drop packets which contain
   extension headers carrying IOAM data-fields."

Whoops, there's another limited domain protocol. All limited domain protocols become potential chaff outside their domain.

Apart from that, I wonder whether you don't need to dive into the history of formal OSI conformance testing to find examples. All I recall personally is a converse example: the anecdote of an OSI TP4 implementation that passed a conformance test with flying colours because whatever it received, it sent back a RESET, which according to the standard was allowed at any time. No doubt it would still have passed even in the presence of undefined extensions.

   Brian

> 
> The concept of fuzzing software isn't new (see
> https://en.wikipedia.org/wiki/Fuzzing) and testing for resilience to
> unusual behaviour is similarly well-established (e.g.,
> https://github.com/Netflix/chaosmonkey).  But are there cases of this
> in network protocols prior to its use in TLS?
> 
> Regards,
> Martin
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>