Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11
"Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com> Wed, 07 July 2021 21:03 UTC
Return-Path: <Glenn.Deen@nbcuni.com>
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 689503A285F for <add@ietfa.amsl.com>; Wed, 7 Jul 2021 14:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.594
X-Spam-Level:
X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=nbcuni.onmicrosoft.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 XKeKUO435ZwS for <add@ietfa.amsl.com>; Wed, 7 Jul 2021 14:03:00 -0700 (PDT)
Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.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 4391B3A2864 for <add@ietf.org>; Wed, 7 Jul 2021 14:03:00 -0700 (PDT)
Received: from pps.filterd (m0193506.ppops.net [127.0.0.1]) by m0193506.ppops.net-00176a04. (8.16.0.43/8.16.0.43) with SMTP id 167KuSZL016360 for <add@ietf.org>; Wed, 7 Jul 2021 17:02:59 -0400
Received: from usecmgip001.mail.tfayd.com ([50.228.147.33]) by m0193506.ppops.net-00176a04. with ESMTP id 39jmn8kvc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <add@ietf.org>; Wed, 07 Jul 2021 17:02:58 -0400
IronPort-SDR: mYWmcqbt7VC0vd/Qd1rzS8uZbDE8vALL1Qw6et6ayKACbiQe2t1fpN+9WjFKX3tQFMFqbPasF/ iBHDhu5eRmCg==
Received: from unknown (HELO ashemwp00004.mail.tfayd.com) ([100.126.24.28]) by USECMGIP001.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 07 Jul 2021 17:02:57 -0400
Received: from ashemwp00007.mail.tfayd.com (100.126.24.31) by ashemwp00002.mail.tfayd.com (100.126.24.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2106.2; Wed, 7 Jul 2021 17:02:56 -0400
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (10.56.130.76) by ashemwp00007.mail.tfayd.com (100.126.24.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.2106.2 via Frontend Transport; Wed, 7 Jul 2021 17:02:56 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E67Lt7k2AbUQ7A7e2sqerC4QjsWWCrysfzykuUNy1O1AJ2S4fZXYcnnZJIBuhSyN3aAZcbUTpU9wonbPoCKl97zdRDhTbQUiKuhN4QvR3kuu0j9h4gCw/a7cdLW6ePtN31lXrWOR6ox8KKUSCbL99bWaVrJcZC9jL9Wn1VXIu3lUN5lQd+4CNF8mcPwCTJWq41xOUlNJ59eIqVe93+WR2hwsMvssV8KDFa6/uvM4HeD+liQ+USrl8vfZwxv3pX+JHlrImz4G975FcGyrrkewwHiP/sGV/bbyhGrZerqrqaJSQDgEJslCxSMvdnyON36FS42IUxSrF15mriY9fimQYA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6jJCEFmxhOSZ3h/j+0LIiPLvSWOKNRDmFGBSoFxZftQ=; b=WUYqhV6Sr4Y+n5MlGaKJxQ8oV04OF1iKCuvnCGYitPfmraDqLeSzzY6b9+DTjVGGTmQTmuOXHVcAnf9wNbG4wQ2Zj49YHMcpAOrW4ltFwAfcwVzsE1pbnOrEuSMJtNYOrCdy2IRem763x/tqmMCdimpHep1tB6cTn3aB8PZcsci40IBcZE5lKNh2muC/ABCLXn8sqKN42xT6bdVKDv6CdxUmdY32T1IpIRiqqqCjsXa4yV8HZZLM6vc8OMNj2BOrO4hkIRnBnc9RyKYG8TT1iOV2ukttyqBnhFs4Ni4rzvrWaV2Fxy+W1sWokTRMV5wWmmjwQAJumjMrCZDPW7+sPg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6jJCEFmxhOSZ3h/j+0LIiPLvSWOKNRDmFGBSoFxZftQ=; b=wBMCniUWHsGKqJCv2ATol5kjSaWY7xO9NYKi9eVDuq8qviJOQnffPdLGWL8usey94mqPjXqgzypBkLRlGc8iXKTvxorg6PbEusZr/c+/GbVvzSPlkuEJnRGLiNCk5ciomXNmhEe1N5fEkgxlCuQbgkKL5YyZQZQVV7UGQJtx9rI=
Received: from SJ0PR14MB4235.namprd14.prod.outlook.com (2603:10b6:a03:2eb::22) by BY5PR14MB4115.namprd14.prod.outlook.com (2603:10b6:a03:20e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.31; Wed, 7 Jul 2021 21:02:54 +0000
Received: from SJ0PR14MB4235.namprd14.prod.outlook.com ([fe80::d5c9:7a2f:dd56:ab55]) by SJ0PR14MB4235.namprd14.prod.outlook.com ([fe80::d5c9:7a2f:dd56:ab55%7]) with mapi id 15.20.4287.033; Wed, 7 Jul 2021 21:02:54 +0000
From: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
To: Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>, "ekr@rtfm.com" <ekr@rtfm.com>, "add@ietf.org" <add@ietf.org>
CC: "Deen, Glenn (NBCUniversal)" <Glenn.Deen@nbcuni.com>
Thread-Topic: [Add] [EXTERNAL] Private IPs, DDR, and PR#11
Thread-Index: AQHXc0+nmuuDLxjpCEW1mVR4W3U7Tas3ivAA
Date: Wed, 07 Jul 2021 21:02:54 +0000
Message-ID: <6C328F58-80D0-48BF-A59C-B09F7EDC7B60@nbcuni.com>
References: <CABcZeBOf2C9dSoYr2w6tEOLkpL_pBu5EhBh3HJWKf+iyAfafKg@mail.gmail.com> <MW2PR00MB03470E2B9FB76B4BB2E2CDD7FA1A9@MW2PR00MB0347.namprd00.prod.outlook.com>
In-Reply-To: <MW2PR00MB03470E2B9FB76B4BB2E2CDD7FA1A9@MW2PR00MB0347.namprd00.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-07-07T16:38:03Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=52b6bc0a-99b2-41b4-86b2-f98fe89fdf5a; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=nbcuni.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8607c6bd-30bf-4f9c-4b35-08d9418a9732
x-ms-traffictypediagnostic: BY5PR14MB4115:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BY5PR14MB41151402262499029FCC9FFBE21A9@BY5PR14MB4115.namprd14.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dYqD32TDcPiIf/Gm1CxewqVwQXjMhvjK2xveIMqrJ3JFSpNVMUSYx3xkT79tbIW9GROdD6MkHlYlmRGM1Vmzqq9wObgkGo/PAom4q5rPnsn8m4dMtu25pbjHkvDdOOuIBDzwgH5+CQrR2FE5CtJS/8OYFUmxTriB9iZlld/4OUV+ivgqcU4tCjli7FN0B8alXUxfn4G8BhS/fxbo5l7ERrE7iiAWaBRT2irf6USVJd57cxZzNP565DD0pVVhd3Mz5/7pwL81SSjJVVgeHycqaET/xbE1U9bsPeMZjJm/3FyucP2zxf0IdBl7uxtof2P4a+JREpxZaUKEIkCyZcML3ky7f/7rzJKl1ZeoyQJpAeHVKjZu+ismcFYzl8fOnetG1tcPtl4F08dmLWOP6cw07E8SwgQdg9CGUW9cPE7uI5EORZo7I8QsUB54ZDjSXo5a1OxVPgE9TcXgxAXZI/iBA/7YmRx4rjj4niCIJT7JL9PD4qvk+8IMn2RNXpeV0meTU+aKUve8H8C5Y3yywfivWic4+K+rQ1O6ZD9PuVzGdv36YBZDLYCtfVnpAFMge5bVDzxMa79ZZd1RsJ1QTZyakxEWv86OKvOJ/g9DfvomcNCXTlVp6smQWKjYytB/2XNvszhiBEfwkNprmnhJAHaJnVLD+rUBJe6RYn/SiLqNoFDn5a5HCNy0slkOcqeou201YXC5DJsaqvhBllVAq21fsA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR14MB4235.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39860400002)(366004)(346002)(136003)(66946007)(64756008)(4326008)(66446008)(316002)(478600001)(8936002)(53546011)(38100700002)(5660300002)(33656002)(76116006)(2616005)(66556008)(66476007)(110136005)(122000001)(71200400001)(86362001)(6512007)(2906002)(8676002)(83380400001)(107886003)(6506007)(186003)(36756003)(6486002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: AxNYQninDDS1ac73ihZWSbQCVueUJAOkvuRK6JYCav350Ebdp42n47cpPfHWEP2xVkg7niareU9AJwMLw4GKFBBEh469cw5Im9m+wgJYSxxntBy9IK0vgpuy5cWKZerswBNK89SbimUWF6Iendw36x062v+/gpxppAgLBypjFtTOT7bvpBlA7sOXJa5KWFhhWCOeTSVmgtxcgJjiUiRzqzxKo3xhLp6+X5bdswa1ERoN7NCkO0N1jfhadWnUxIJ/mAZqf7nuyF1e52Hp3OIwgWumVmpObrjqabYa8b3ulCoZ6rMqKseryII2qcF93+y3u0MSNDwiGdaopPAbTYI3VSpxpCAQT8r9K4fnbw7b9lGDBZIGaGC0+S9R/e8YMBvzaOE5vHkcN+DF9g3vqYFA+yu08/6hyK5aXHkn8grv4g4N88KOT7p+fD9nQlqKilyZLg9UG6l8BlnpR3rXo+JKhRCmA/Ghqj7K0jAzercNZNaDV+Jk9FenmyhT9srdoTCZLEQBxHrrv097SnDLX7jsV7MOYipcncPWuTOf97d2hyTpI/bqYed/I0cccCXXqD2X7+F6SjLRXboc9EIGWrjFy+4ZWSUSWuecmxIff3Kf7DYTXsmUti189hTvojxC8yFWUb37LZpa9bS/hRss/iCjlOX3S8Wj9KMsszBmoBQxCxFryVbEj+PUlo28eXLiMTAMzg0iOCCzKXZmfrEwUv5chHFArDcSoOYS1WktLy2Iv46/D67v/njr5Feqi3ZQELaxo3x1wabHwiSJro3hUCyivBjqGFbuFEdQ9I5ePIT9TqFO0QCP3Nf6F2OZyXBklMB9y4M4dcbPllFPPnhZe6EVDzOIfUDItTGJEEaDZB2ND9jshzNyNHydv1nATbTGP92kB8xUo6XjhgU9Y0VVkK2QiYnlqNqy/Ds4JGWK6R6czLGpUGuRPI8yBdxd5bQ+M4DduOEh6LioVaYklpj+0HXIRsQvDqCuuo3y7BpuxTsw6tqtgLX3G7vGY9YfR9i+uGlUmfcvdrKezINNYIj1tt0anUN7uJwtwsw6bNcIw0qWyTDAswd8n3zOE3TE92C0refdr5g/Utp5r8dmaVP2aFMC1xCB3vAdR8aTYpFaU4ytU9WYIl1wHLcno+xcr7lVuiLn0zUgW2IifxvMhwc5N0QB8J3QA8x9oY9WPmIhs4zix9Mp03GUF38u6CCKTuLJLQq+qnwCxavrFHZ19YIp9A0sDCCebtEAf35wokg7J9nr+D3AzOxYD/PXLoQWDWg1ZabneJo4CRgPhlYkGm2O+uaNuZA63wvLEcRmXQkh9IsVl5Zfi8ZHyqk2jTIpcF6iNmk4mekt9HAxgQz2q58iZhFeTU5hRiP0KGlx1amB5L/uDx8YI4kl1AxnvQLXGC5lREoUPf6aVyRx+f6NL3ZC68C5jw==
Content-Type: multipart/alternative; boundary="_000_6C328F5880D048BFA59CB09F7EDC7B60nbcunicom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR14MB4235.namprd14.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8607c6bd-30bf-4f9c-4b35-08d9418a9732
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 21:02:54.6229 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: DSiV0OVf6cb89GOT3rV/dgJL1klK/HwRse1GaIjb/5nqMrIbHUhGdXGtwgsVTNRgPUDjdl2ThWLDIdRjGP61jA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR14MB4115
X-OriginatorOrg: nbcuni.com
X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45
X-Proofpoint-ORIG-GUID: 9Ywans-pv2PF5dle_L6eI-n7zERC5sYw
X-Proofpoint-GUID: 9Ywans-pv2PF5dle_L6eI-n7zERC5sYw
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-07_09:2021-07-06, 2021-07-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 mlxscore=0 malwarescore=0 phishscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 spamscore=0 priorityscore=1501 bulkscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107070120
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/Iv1DQ2AGjuMG9qv9iAQEVmyuzGo>
Subject: Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11
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: Wed, 07 Jul 2021 21:03:03 -0000
This is an important discussion and I’m a little worried that it’s not getting enough eyes on it at the moment – which is why there isn’t a lot of traffic discussing it – very possibly due to it being a popular vacation time in the US and elsewhere for summer and people busily on other drafts/things. So making a big decision on list traffic alone at the moment might be a bit rushed. I do recall that previously the WG had discussed the scenario and it was important to an number of people and we’ve already had a lot of discussion that went into building up the requirements Doc around this. Suggestion: Before anything gets even seriously considered for removal, we should discuss the proposition during the ADD session for IETF111, and in any post IETF111 list traffic that discussion may trivver. Is someone(s) willing to put together a couple of slides documenting the scenario at IETF111? -glenn as ADD co-chair On 7/7/21, 9:46 AM, "Add on behalf of Tommy Jensen" <add-bounces@ietf.org<mailto:add-bounces@ietf.org> on behalf of Jensen.Thomas=40microsoft.com@dmarc.ietf.org<mailto:Jensen.Thomas=40microsoft.com@dmarc.ietf.org>> wrote: > Are there an appreciable number of networks with these properties? If so, can we write down where that happens and put it in Security Considerations? If not, we should consider removing this mode. Just my 0.02: I would support removing this whether in PR#11 or DDR as it stands. The reason we added this “same IP is allowed without verification” mechanism was in response to WG feedback that expecting ecosystem members to accomplish this on our own was unreasonable (the authors originally said “we leave that to DoT knocking which is already suggested in RFC7858”). I see Michael already commented on this; it would be useful to hear more WG commentary on this point. I was under the impression that there is some subset of network operators who found that useful. If not, we should revisit. Thanks, Tommy From: Add <add-bounces@ietf.org> On Behalf Of Eric Rescorla Sent: Thursday, July 1, 2021 3:18 PM To: ADD Mailing list <add@ietf.org> Subject: [EXTERNAL] [Add] Private IPs, DDR, and PR#11 I've been spending some time thinking about PR#11 and trying to figure out the threat model where it brings value. This message is an attempt to get to a better understanding. As should be clear, I'm a little confused, so if people want to tell me why I'm wrong, that would be helpful. First, let's start with what I take to be the network topology: ISP Resolver 192.0.2.1 | | <- ISP Network | 192.0.2.100 CPE/DNS Proxy 10.0.0.1 | | <- Home network | 10.0.0.100 Users device We have the ISP's resolver with a public address of 192.0.2.1. The user has some sort of CPE with an external address of 192.0.2.100 and an internal address of 10.0.0.1. The user's device has an IP of 10.0.0.100. When the user's device does DHCP, it gets the address 10.0.0.1 for its resolver, presumably because the CPE intends to proxy or cache DNS, otherwise it could just serve the ISP's resolver address (192.0.2.1) in DHCP. The general assumption for the DDR threat model so far is that: 1. The user's device gets the address of its resolver securely (presumably because DHCP is secure in some way). If that's not true, then I think we can agree that DDR does not provide much additional security benefit because the attacker can just substitute their own resolver [0]. 2. Either the home network or the ISP network is insecure, otherwise you don't need DoX. OPPORTUNISTIC MODE So, first, its not entirely clear to me what the Opportunistic mode of S 4.2 provides. In this scenario, presumably the client will be doing TLS to the CPE (because otherwise the IP address would be the resolver's public address), which means that we are concerned with the attacker controlling the home network. So, in this scenario, we are only getting value if you have a network in which: 1. The attacker can *see* traffic not destined for their IP address (otherwise there's not much point in encrypting). 2. The attacker cannot forge traffic from another IP address (otherwise they can just impersonate the CPE because there is no certificate). Are there an appreciable number of networks with these properties? If so, can we write down where that happens and put it in Security Considerations? If not, we should consider removing this mode. PR #11 The idea with PR#11 seems to be to bootstrap up from a local IP address issued via DHCP to some other address. PR#11 doesn't do that great a job of describing the setting, but I'm assuming the scenario is that we want to start from a situation in which we have a CPE-based proxy and move to a situation in which the user's device talks directly to the ISP resolver. Otherwise, presumably, we could just make do with the mode in S 4.2. Is this right or am I missing something? And the reason we're not just vending the ISP's resolver directly via DHCP is that the CPE isn't upgradeable or potentially under the user's control and not the network's? So, first, what threat model are we concerned with: 1. If it's control of the home network, then why can't the attacker block the _SVCB record between the user and the CPE stopping them from upgrading? 2. If it's control of the link to the ISP, then why can't the attacker just block the resolution of the _SCVB record between the CPE and the ISP's resolver? Maybe the CPE is using DoX, but we're trying to protect against *future* compromise of the user's network? Can we get this documented before we start designing mechanisms? That would also help understand the effectiveness of the 5 minute timeout. Finally, assuming I've understood things correctly, reaching through the CPE in this way seems like it has the potential to bypass any CPE-specific filtering that the user has has installed. Suppose I have some CPE that uses the ISP DNS but filters out certain names; if the ISP posts a _SVCB record that directs me to their resolver, doesn't that cause that filtering not to work? -Ekr [0] Modulo cdisco-style steering where the address is matched up against a trusted list.
- [Add] Private IPs, DDR, and PR#11 Eric Rescorla
- Re: [Add] Private IPs, DDR, and PR#11 Michael Richardson
- Re: [Add] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 Tommy Jensen
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 Deen, Glenn (NBCUniversal)
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] [EXTERNAL] Private IPs, DDR, and PR#11 STARK, BARBARA H
- Re: [Add] Private IPs, DDR, and PR#11 Eric Rescorla
- Re: [Add] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] Private IPs, DDR, and PR#11 Andrew Campling
- Re: [Add] Private IPs, DDR, and PR#11 Eric Rescorla
- Re: [Add] Private IPs, DDR, and PR#11 Ben Schwartz
- Re: [Add] [EXTERNAL] Re: Private IPs, DDR, and PR… Tommy Jensen
- Re: [Add] Private IPs, DDR, and PR#11 Eric Rescorla