[DNSOP] EDE forwarding options to discuss in Singapore

Wes Hardaker <wjhns1@hardakers.net> Sat, 02 November 2019 18:41 UTC

Return-Path: <wjhns1@hardakers.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2931612022C for <dnsop@ietfa.amsl.com>; Sat, 2 Nov 2019 11:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id asjoHYNbrqLy for <dnsop@ietfa.amsl.com>; Sat, 2 Nov 2019 11:41:09 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1A9120052 for <dnsop@ietf.org>; Sat, 2 Nov 2019 11:40:47 -0700 (PDT)
Received: from localhost (unknown []) by mail.hardakers.net (Postfix) with ESMTPA id 3CB8520F20 for <dnsop@ietf.org>; Sat, 2 Nov 2019 11:40:45 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: dnsop@ietf.org
Date: Sat, 02 Nov 2019 11:40:38 -0700
Message-ID: <yblftj6ceah.fsf@wu.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/shhnxqpWQZIJx7v4UEYvaQkbpSI>
Subject: [DNSOP] EDE forwarding options to discuss in Singapore
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2019 18:41:11 -0000

After multiple discussions with dnsop members (including
implementers) on the mailing list and in person, we've come up with
a number of mechanisms that might work for passing EDE options
through a DNS forwarder or similar.  Though some of us already have
preferences, we're listing the ideas we have so far below.  We would
like to hold a discussion about the path forward in dnsop in

Options for how to deal with EDE forwarding:

  1. We could mandate that no forwarding of EDE happens
  2. We could mandate that resolver/forwarders should copy from one
     packet to the next
  3. We could indicate they can adjust the extra-text field to add
     additional information, such as adding where it came from.
  4. We could tracing elements to the packet -- like the address where
     it came from
     a. A single source added by the entity generating the EDE option.
        See below.
     b. Multiple sources, with each box adding another one as it
        traverses (note: significantly more complex)
     c. We could RECOMMEND putting a source indication into the
        extra-info field
  5. We could add a new EDE code for supplemental information to be
     added after a previous one, indicating a chain.  But this
     requires order preservation which is probably not a good idea
     since EDNS0 doesn't require order preservation.
  6. Make the document experimental, and publish as it is now and deal
     with it after deployment experience has been obtained.
  7. Your idea here - we'll discuss all options at singapore

Additional information for adding source information for part 4a/b: we
need to specify how to indicate what to add as a source field format.
We expect any option to need to include a NSID value as a likely good
choice.  There are a number of other types that we came up with that
might be source indicators:

    1. nsid
    2. hostname (fqdn)
    3. ip address
    4. URL (eg from doh)
    5. ip:port
    6. cert subject name
    7. ...

We are, again, listing all options for completeness though we have
personal views on which might be best.  We note that NSID is already
listed as a binary field, and thus to a large extent the rest of these
could, technically, be NSID values already anyway.  We could leave it
free-form, or we could (adding complexity) add a source type field
(and another IANA registry).

The resulting packet format would look something like this:

                                              1   1   1   1   1   1
      0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5  
0:  |                            OPTION-CODE                        |
2:  |                           OPTION-LENGTH                       |
4:  | INFO-CODE                                                     |
6:  | SRC_LENGTH                                                    |
8:  / SRC_FIELD (which can be zero length)                          /
10: / EXTRA-TEXT (can be zero length)...                            /

Wes Hardaker