Re: [Add] ADD State of Things Observations

Joey S <joeysalazar@article19.org> Thu, 22 October 2020 00:14 UTC

Return-Path: <joeysalazar@article19.org>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C693A0CD5 for <add@ietfa.amsl.com>; Wed, 21 Oct 2020 17:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.244
X-Spam-Level:
X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=article19.org
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 78bsK8La3zkp for <add@ietfa.amsl.com>; Wed, 21 Oct 2020 17:14:40 -0700 (PDT)
Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (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 6DF2A3A0CC4 for <add@ietf.org>; Wed, 21 Oct 2020 17:14:39 -0700 (PDT)
Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <joeysalazar@article19.org>) id 1kVOFX-0007BM-Vp for add@ietf.org; Thu, 22 Oct 2020 02:14:37 +0200
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=article19.org; s=mail; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:To:From:References:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wuQk00Fn57gyc8bbVs+hkl+2iaeKit1vEWQKm2oLwio=; b=RGP1po6wUu/M4M99MhTsMOb3j MUToLos6cRob327b/TpIEU1r2Tfh7yaP1GnNxtzcnqUAJGbVCZ9eW5zsn06TWsohgsXZkNLbOWcK4 EnlnomCFuU4x3yd3QPbyHULGw0/dMBnC9dzAFXqkUiitZOr3uS3QZzYvTBk9yWYv8MpOs=;
References: <22A74993-38FD-4A59-BFAF-4917ABEFC2CB@comcast.com> <CACJ6M14+t3b_sWWC9+SxvdCADBtdbNVAxZ4TgpWMj7cpHJP32g@mail.gmail.com> <BYAPR11MB3111C6005774E0BD073B8F46EA020@BYAPR11MB3111.namprd11.prod.outlook.com> <LO2P265MB0573C0129D0DE9847AED28EBC2020@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
From: Joey S <joeysalazar@article19.org>
Autocrypt: addr=joeysalazar@article19.org; keydata= mDMEXZTRnBYJKwYBBAHaRw8BAQdAR3jTF7OBMWWAdkeA/J2YINHL+F73joqExbmXuMyaSbi0 IkpvZXkgUyA8am9leXNhbGF6YXJAYXJ0aWNsZTE5Lm9yZz6IlgQTFggAPhYhBG6cleVb7ZQT XQhV1QpAQTYN8BqRBQJdlNGcAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJ EApAQTYN8BqRUG4BAJlToAdbX8ybZY/YEE6Cx9MWMw5UAc3PNxtsqBjxT+wwAQDwnkiVMvS5 919yL+Hql44fdZSA2Uu75Xlc4Zz57S5fB7g4BF2U0ZwSCisGAQQBl1UBBQEBB0B0/M0aJaYC uThNCIaFiPrneHwKTCA91gjgthVzKNg6EwMBCAeIfgQYFggAJhYhBG6cleVb7ZQTXQhV1QpA QTYN8BqRBQJdlNGcAhsMBQkJZgGAAAoJEApAQTYN8BqROEYA/3LPYUyagV/7uKHN62bBa6UW dfqgIn6ie7XOw+jPy1tgAP40i23dbN7AAnZ5CljjLbRsbVF6YlDe1nZHcAo3/xZiCg==
To: add@ietf.org
Message-ID: <868d5b2c-141a-4b44-cfa3-beef1840e624@article19.org>
Date: Wed, 21 Oct 2020 18:14:28 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <LO2P265MB0573C0129D0DE9847AED28EBC2020@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="qHCfOA7wPPewcsC5TK0z6OH31OcAmQDj6"
X-Virus-Scanned: by clamav at smarthost1.samage.net
X-Scan-Signature: c4d37daad8bbee4d9ce4f192a2f1dac2
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/WDFdY8o9XsJmucEi6duu-BavNR4>
Subject: Re: [Add] ADD State of Things Observations
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2020 00:14:43 -0000

do people feel the general observations around complexity and path proposed to be reasonable?
Yes. Adding to what Andrew said, defining pending input in the narrative and requirements sections of the draft will be helpful in further clearing the division line in complexity first and later correlating that to the deployment scale of specific scenarios if/when needed.

This could also help in avoiding fragmenting the scope of the 2-3 groups too much so we don't go back to a need for consolidation like we had during the previous IETF meeting.
--
Joey
On 10/15/2020 2:06 PM, Andrew Campling wrote:

Glenn

The approach you’ve suggested seems like a reasonable way forward, especially if the split is along the lines suggested by Chris.  Ideally we’d first flesh out the user requirements a little more and then have the WG adopt the document so that there is an agreed record of the use cases and associated requirements that we’re aiming to solve. 

 

Andrew  

 

From: Deen, Glenn <Glenn_Deen@comcast.com>
Sent: 15 October 2020 16:16
To: ADD Mailing list <add@ietf.org>
Subject: Re: [Add] ADD State of Things Observations

 

Chris,

 

Thanks for the comment.

 

I meant the proposed complexity grouping as starting points, but if it’s possible to merge RFC1918/CPE with a less complex case that’s very nice.  There do remain other complex environments that won’t be as easy.   Ultimately such lines are drawn are drawn by  authors and the WG group so we choose to draw as appropriate. 

 

Regardless of where the lines are drawn, for now do people feel the general observations around complexity and path proposed to be reasonable?

 

Glenn 

 


From: Chris Box (BT) <chris.box.ietf@gmail.com>
Sent: Thursday, October 15, 2020 2:12 AM
To: Deen, Glenn
Cc: ADD Mailing list
Subject: Re: [Add] ADD State of Things Observations

 

Glenn,

 

I'm happy with the general principle of splitting into 2 or 3 areas and working on those in parallel.

 

But I'm not entirely sure I agree with where you've drawn the distinction.

 

(1) Low-complexity environments.  – this would include the case that started the “My single use case” thread

 

(2) High-complexity environments – this would include the RFC1918 situations,  networks with more advanced technical controls, networks/devices with applied policy controls.

 

I would see RFC1918-addressed forwarders as very much in the scope of "My single use case".

 

In fact as Martin said:

This might need the full matrix of DoT/DoH, v4/v6, with/without a forwarder, but this is fundamentally just a single use case.

 

As others have said, such non-upgradeable forwarders are so common that any "tell me how to contact your encrypted version" protocol will need to deal with them.

 

Likewise, a consequence of selecting the network's recommended encrypted resolver is that network-applied policy controls may be in scope. So they are not solely found in "high-complexity environments".

 

But I do agree that it is useful to separate out such more complex items as Enterprise, and the provision of useful information about each possible resolver, such that the client can make a more informed decision if it wishes to.

 

Chris