Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt

Esko Dijk <esko.dijk@iotconsultancy.nl> Tue, 10 October 2023 12:57 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21A6C1AE9DB for <dnssd@ietfa.amsl.com>; Tue, 10 Oct 2023 05:57:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancy.nl
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0BaTuKeWufS for <dnssd@ietfa.amsl.com>; Tue, 10 Oct 2023 05:57:23 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2124.outbound.protection.outlook.com [40.107.8.124]) (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 43B9FC1516E0 for <dnssd@ietf.org>; Tue, 10 Oct 2023 05:57:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AjejYuS7RMcDdwCj50UjJvp6Dwc0hEvWvtWxEGB1Ii6esSKALGNxNo0kONylCpnsLGoJ9jYZGTbxoBopLfQBGsLJAUUkM6no86RgGMh1U+VgbNzD0V9xtOKe0K58x7MDoUYrumS64GiVEWGb8ek9/rv8T0Mt28sHxawOvGtUj+3v67qjU7dPhBhFcFwhJb/TpOdrMr2lg11t9k1vjGEWuQNuMwtySxH/B+m/39lbAaNvdA3+sa9uIh3NuXWg7hHrD4s3P9n+X7FKH9F+HE6jtHFhqxv5n4NrfLs/z3D0bGeYpvOOdgJcI3mryQ9kKaHjI74kf4gp2Qn06tu+9xGx8Q==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=+JBkMxYeEIKMnbx55oMDlgLuhSLyoZBuuq1ZpDeuK4E=; b=boJSFtHvi3F1eyB38l+AVjxVhCWKdgzYCj3qLUzX/vFggm9lAAEqaSf0QSfW0Iq5WrZcHLYnzWlxbUmJHobxtnH6lAExUZE2mLB+yDgTeV1AFc62WstbjFenwh2kyBLAZy+BXqA4T2i2y+5hkswLy7ZqRvCyoPMNwm8eV+qhiND/aFYEmV9WpIM78VWxnTLoGqEcQyY9V/NDaKhp0GFBzzmHCu09CBCqpCHXiTrtwp8PqHhtWzejnGj/kLuIUYjnq4XfCr2aieYFnZeY4yN+2boGwIwgIWIyIKOpR6i/LS6ayxHn9v3bEpbyleE2fTVIIcz0Ag8Orv2hQhWTO7VWjw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=iotconsultancy.nl; dmarc=pass action=none header.from=iotconsultancy.nl; dkim=pass header.d=iotconsultancy.nl; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancy.nl; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+JBkMxYeEIKMnbx55oMDlgLuhSLyoZBuuq1ZpDeuK4E=; b=xzlYWleawLBDA609kEmEA8Y11+kWliLRcQA44xfNhdu6csBC21cEo9+yaILArms4bDvvwuJvVBn3RjSTIzMWWxZNtd5OtMLg+aMT3r5Y6BgFIENKUu5NB/a5UIdfS0IHo7q0Oz3Pn8n/1VkSfrSRyRFvxd/pFr7+xa/nu74pbFI=
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:3b9::20) by DB9P190MB1386.EURP190.PROD.OUTLOOK.COM (2603:10a6:10:22d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6863.38; Tue, 10 Oct 2023 12:57:16 +0000
Received: from DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::6cab:dca2:fbc5:20d9]) by DU0P190MB1978.EURP190.PROD.OUTLOOK.COM ([fe80::6cab:dca2:fbc5:20d9%3]) with mapi id 15.20.6838.040; Tue, 10 Oct 2023 12:57:16 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: Ted Lemon <mellon@fugue.com>, Alexander Clouter <alex+ietf@coremem.com>
CC: "dnssd@ietf.org" <dnssd@ietf.org>
Thread-Topic: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt
Thread-Index: AQHZxyROoxLcDP8FdEKzoOzOZ1E/t7A4ckUAgAAFdgCAABqVgIAABDOAgArLGiA=
Date: Tue, 10 Oct 2023 12:57:15 +0000
Message-ID: <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
References: <169118866241.13601.15936262706231533955@ietfa.amsl.com> <ee7f1fcc-ed24-457e-9fad-0248cd2d7fee@app.fastmail.com> <CAPt1N1kxtBAyAMbp=pwneNJEWUE300CGGQtr0wMdPbdUye7YYA@mail.gmail.com> <65676093-1ec8-4693-af49-79141507b6c3@app.fastmail.com> <CAPt1N1ndBC-yqd9T+08xoenT1stm5c0mP=2b2hWBFtF4VExJxQ@mail.gmail.com>
In-Reply-To: <CAPt1N1ndBC-yqd9T+08xoenT1stm5c0mP=2b2hWBFtF4VExJxQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=iotconsultancy.nl;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: DU0P190MB1978:EE_|DB9P190MB1386:EE_
x-ms-office365-filtering-correlation-id: 3261c756-edea-45fa-3517-08dbc9906def
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7U6vWUjQMuKxBPNypMeH5FToR4DjyUMtgBoWS6gbmlk4QTb+onaN2P1Deug+wKpdb5soVN0/+9WbR/6GqG6Grz6AOZFu4/RiD+KegK6KUMXnRM2p8Tmzhp/GDSAHwtuDAdtMKMJ9PLNNhcYw2V3tMgp1RqYMDIYJNZ+L9UQVcZfU6fDpa2pQ6NO6NHleyKseS26HTPAQmVx6wBrIx8GOUJC8FARHBpa6zRClfIyIKObh+xZxY6y46KkVV4M/241C0jm6toEMuVdKiv9rRoJDsfRdcpB3WJ0xZkoyuUs48O9FSEodQkzTceTsxfV8hQSWXvzqSa6ajnKpCv4iud4w7CJVlXDJEzAUHh4Xm1IiL4iNrx9nSNsM512zxt3RN1h4eAANIPg3dhXyNEmxhc/3LpJBDBRkJ9YnB4+3EOyec1zWDbd3/cPc5goVTp+DCCfy9UBBK8nvPx5yiLf0CL3wFicH3bCTH5g1MPRoEffnS6hFb/UZi5aRN0c0PVvpB2hnraIJdJdlLKW4nwUOpx/XDagt79hxbeNuSe5qO7qN+BZuONvx8zZdHh7UiVTdHDvQiSXE8MO98/EYKk83yC/T3YMVcLSYo80W1UAlNVzYvXo=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DU0P190MB1978.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(376002)(346002)(366004)(136003)(396003)(39830400003)(230922051799003)(1800799009)(64100799003)(186009)(451199024)(478600001)(26005)(71200400001)(166002)(38100700002)(122000001)(53546011)(316002)(66556008)(76116006)(66946007)(9686003)(33656002)(66476007)(110136005)(6506007)(7696005)(66446008)(64756008)(5660300002)(83380400001)(44832011)(66574015)(4326008)(41300700001)(8936002)(8676002)(52536014)(86362001)(55016003)(2906002)(38070700005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 71yi+vV0M5gGEss8PKYFekdmVJunjVLiDU41MZKx2X3z0TPvWpu7d7YALmUBnej+sziZhC9z4z3p41DPB9aePc26beauRJLMGNrffzMaTFHMY6lXEoItWIloW0putQzGxP43NTyYATu11NvkOjqpL6Ru5Mz+mWdRAFAH4y8Who/n1DYv4WhZlMqICEEYUvIG6MtUwawDMlL97lXp1ZcOEONH0mW1jRFSHXUKLMxb3uv0xR+n8odQbsCibFqs7IwUsAc9iiXbsygQqVUc646pyFpY6T9atwzWErbq3+jPYKch1L1qmdw6VefefIR1MTs1aejDbHE9GuvtFZ6BF1ya6fMVz8LydTriOlLdCcdSGztPgFoi87mEnB+vS8L2gXEXpSmSjopNhH6wLzc1NXA6wjIfSepsMqBObskae5BdDMuwThdl4XF+bvGGkCO62fjH7kudadNLrifXawZD83p9iS3hjeI4FgIJ0tiK+eDqL0l4Wjwrdncp8Rj1bxs95tGiQpoPmbLR46uJcL1zohiyOLBn7kQ8YDR/6m287dw1t30kjszQlnnaKdhGcHvt3Q0KFoi3JIk/0G9PjXA1o6Z9DwPjHc3zkW2lCiBe554KBWNy6A0OLlL54Y/7uJ1ajjs6UUzMjDK6UANKKdl2xysPZ+ZGckCJ8bSwxfYE4BIEmuM+xirs864dy6WDS4X3zQpFynFtS9cttfTX2aMwRIsmI3FawlF+QDemWlDjqa515L5Df19TvrFCJq3mUrYsEmes8uNn+MJijfkKazawWqZz59SjvoJHx07Er8mBm6S1auZbcGiUuOKGeBYh+V7+cWbbzoEiYuq8h8bXSu/5JwXv4rk6kmBZkxZEaA568tpCWosQg1OKExasiK0XLeE5J1mcnF1lD4QdbraIzF+vhi7qMSpqTpRONEeOvaKgifx/JBUDopL+1OnhNVb3/MTFD1xYiqq/tNeHHzdiyIyPRo6jGTjT7FnMcVG9E+bze+QK9h6qosNwg0FzAs4mB1GGxdBmFJn55V6st7FfQcDDPmNiYMEadhwyKHbai3XCAYdpAVXAysFZNqszyNkF56/Cxu0T593JWC47asqRmccYitRRyrLP4ig55exmC3fdN3XYIj0DRYlv/aHITqT0BFKgvxey5tfjyk/niwBWTQxS5tsSNJshrPp1M60uzE3oshr+M8JwjxJ3Urnhoa4skwh+sMQe5H/C21rC3fTuhaRamqMDQfFpmzHHgBkkANjddVScUXksOzSr0w8LIOOcPGwgEEiEe+ZqXJbUb3PHN3lQsGa9PyWODQd2sH/kvduKoMpTeDPFMKq8UpGCle9on30Jzp4ji0LVo3fkOJon2Fo/MqV9HLotVp1kLgY5HL0KyY4ggCgHgiH+jvYTJA72njW7OoxL/GO9JXrGsSCXpFm4kvSlBL+zzi4foXm2F+R5GnI2no5Da6ZoEJ2vUFzSfVlG6YbZ4TkNJJVUeCV+/2swNMdLBwwWvc8cF/66EXa9gNs/uEfHDcKnVmdyvoWdn7AeP5QX4In2bHwyYFQbQZ2PLftI9bs/+rhRw7+JClLkNcIhhm5LtstoQExmHjlpm7B9LYJf
Content-Type: multipart/alternative; boundary="_000_DU0P190MB197824A5BFCF64175FBF48ECFDCDADU0P190MB1978EURP_"
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0P190MB1978.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 3261c756-edea-45fa-3517-08dbc9906def
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2023 12:57:15.9689 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: MDht8f7iodI+vxFgyEAERtO0bJNxNYvbKY8Z+MYxsV0BdpsWGxl/+IF1qH2jQqMli02goFOE7PhhsQTyavVlzgarCIi9niSq9IJOc+gJd4U=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9P190MB1386
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ZON9XMWaXNO7RopiqW1hOZg_T0w>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Oct 2023 12:57:27 -0000

I’m not sure I understand what the problem is here and what the proposed solution is.  Based on the proposed text, it looks like a large change.

The context text is (if I’m correct):

For example, a stub router [I-D.ietf-snac-simple<https://datatracker.ietf.org/doc/html/draft-ietf-snac-simple-02>] for a constrained network might only accept UDP updates from source addresses known to be on-link on that stub network, and might further validate that the UDP update was actually received on the stub network interface and not the interface connected to the adjacent infrastructure link.

My contextual assumption here is that the stub router is also the SRP Registrar – and that “UDP update” here means an SRP Update over UDP.

Now if SRP is being used in a stub network, with a stub router, then I assume the stub router would know how to determine that an UDP update came from a source address that is “on-link” or “on-mesh” on that stub network.
This could be based on the interface via which the stub router received the update. By definition it’s a stub network, so if it came from the stub interface, then it came from a node on the stub network.

It could also be based on the address prefix: if it’s from a prefix that is configured as “on-link” or “on-mesh” for the stub network, then it came from one of the stub network nodes.

If the stub network is a technology that only allows a single link (no mesh) then it could check of course that the IPv6 Hop Limit field is 255 in the received UDP update. But that’s not sufficient, the stub router also needs to check that it came from the right network: the stub, not the AIL.

For a mesh network I don’t know if the IPv6 Hop Limit setting to 255 makes sense: there could be any number of IPv6 hops potentially before the stub router is reached.
So why not just let this determination to the specific (stub) technology being used, and avoid talking about this in the SRP draft?  That doesn’t seem to help and is only confusing as I see it now.

Regards
Esko

From: dnssd <dnssd-bounces@ietf.org> On Behalf Of Ted Lemon
Sent: Tuesday, October 3, 2023 17:58
To: Alexander Clouter <alex+ietf@coremem.com>
Cc: dnssd@ietf.org
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt

Current constrained node applications have the registrar and the router on the same node. There is a passthrough mode for infrastructure support, but in principle at least I think the SRP spec says (although doesn't clearly specify how to do this) that in this case there ought to be a relay of some sort on the router that validates that the update is from the local network and attests to that fact when sending to the infrastructure registrar. Maybe this should be a follow-on document.

I agree that the worry of excessive traffic due to routing loops shouldn't be an impediment to this—this should be a very low-traffic protocol whether the node sending the update is constrained or not.

On Tue, Oct 3, 2023 at 11:43 AM Alexander Clouter <alex+ietf@coremem.com<mailto:alex%2Bietf@coremem.com>> wrote:
On Tue, 3 Oct 2023, at 15:07, Ted Lemon wrote:
>> > Section 6.1 -  Source Validation
>> >
>> > [snipped]
>> >
>> > For example, a stub router [I-D.ietf-snac-simple] for a constrained
>> network might only accept UDP updates from source addresses known to be
>> on-link on that stub network, ...
>>
>> An IP header TTL of 255 can also provide proof of being on-link where the
>> registrar verifies if the received TTL is 255; this technique is described
>> in RFC 5082.
>>
> This is a good point. We're a bit delayed in updating for reasons the
> chairs are aware of. This might actually be a good way of addressing one of
> the points that I _think_ was raised during IESG review; if so, it would be
> appropriate.
>
> Can you propose text?

Sure, how does this sound?
----
6.1. Source Validation

[snipped]

For example, a stub router [I-D.ietf-snac-simple] for a constrained network might only accept UDP updates from source addresses known to be on-link on that stub network or determined as such using GTSM [RFC5082], and might further validate that the UDP update was actually received on the stub network interface and not the interface connected to the adjacent infrastructure link.
----

To be of any actual use, we would need to also update:
----
3.1.2. Constrained Hosts

[snipped]

As a spoofing countermeasure, as discussed in Section 6.1, all UDP updates MUST be treated as a GTSM-enabled protocol and implemented as described in RFC 5082 Section 3.
----

Some may see this as a substantial change, though for a constrained device the result may be no more than a tweak to some existing hard coded header.

There is also the theoretical bonus of incurring the wrath of the local administrator now seeing a handful of TTL 255 packets flying by, more so if they happen to create a routing loop. I am not really sure this is in practice an actual problem as constrained nodes are not expected to generate much traffic and the TTL is only a 4x increase.

The alternative would be to create a GTSM negotiation as suggested in RFC 5082 section 2.1, but that does nothing but to move the spoofing problem around.

This then means we need to tweak the behaviour of the registrar:
----
3.1.2. Constrained Hosts

[snipped]

As a spoofing countermeasure, as discussed in Section 6.1, all UDP updates (and their replies) MUST be treated as a GTSM-enabled protocol and implemented as described in RFC 5082 Section 3.

For registrars serving a stub network interface, UDP updates MUST be treated as GTSM-enabled. An administrative control MAY be provided to selectively disable this behaviour for the reception of UDP updates based on an access list of source MAC or link-local IP addresses (RFC3927, and RFC4291 section 2.5.6). Source IP addresses that are not link-local MUST be rejected so to not undermine this spoofing countermeasure.
----

Everything is now a MUST as the constrained node is also going to expect to see TTL=255. The question now is how does a constrained node know it is on a constrained network being serviced by registrar with a stub network interface on that network?

I am thinking

[registrar] -- [router] -- [constrained node]

The constrained node is going to see TTL=254.

...starting to see a lot of warts on something I hoped would be straight forward.

As a passing nit, the URL reference to RFC2827 is HTTP-super-secure (http*s*s://..., double-s).

Cheers