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

Alexander Clouter <> Tue, 03 October 2023 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36AF4C1522A4 for <>; Tue, 3 Oct 2023 08:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 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, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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: (amavisd-new); dkim=pass (2048-bit key) header.b="pDTpoh+z"; dkim=pass (2048-bit key) header.b="b1VRb09g"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UjeHRLxNGHMI for <>; Tue, 3 Oct 2023 08:43:27 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 83A80C151090 for <>; Tue, 3 Oct 2023 08:43:27 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id C9E8B3200BD7; Tue, 3 Oct 2023 11:43:26 -0400 (EDT)
Received: from imap46 ([]) by compute3.internal (MEProxy); Tue, 03 Oct 2023 11:43:27 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1696347806; x=1696434206; bh=JI iWSsQLsjTrtNMiDypKuuwGj+8temI/dlMpu3LM/t0=; b=pDTpoh+z8B3nn7r+AG X4UV9b+ZiifdGD7yzFCZXqUbHnZCTxQuvTKmFipXZBwkzex8s98StedJ+6Fo2cbO efC+x87vcHuuVKgJ5bKb7ha1lxUF+y8oj818+NXA2VPhhrzJtZvPJaOl+7KDsYi1 A2PpzlsbGOGKrENwhRfSxYBIPMpy01SQ/nGr3HOxphsFbAFtuF0i+Ig2bcKhOtWI rm/NFthWDTS4JnRBgWFLMblnpyf5zIrbio2xJ37LC7YMHSBAoVVxr+iDXRNi6JsN cUkUbbSyrtrdPchBW3mYe9kxRHVVYS/7iMmoW2rYulOgrtd748Yvlv7bPyoz0Ym7 Bs5g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1696347806; x=1696434206; bh=JIiWSsQLsjTrt NMiDypKuuwGj+8temI/dlMpu3LM/t0=; b=b1VRb09gRgs5rDdgW4ncqIorAQOiK kB/34mqmQdIAv2KXthREBVh69ifxFgVqvf/IFu30sjItUJtCfQquoWPWYDuNRKgF zgPC4dLaHlbGTsoiAqgumHBKiVxYaC8BbI0GKndbzcV7MYlJgRDNFuChLQ2bALFw tXu5Ryomrvex3FXkd7aoB0XAxyjT3HsCeWIZSGhyyZ454uPztZK+sHGb8OjRrjCp nmY/suTDuaVyRs1+uCoT6IorlawXCq2zI2USmnnxwwZw8nis39qNkNuNs18nkix2 YpqZY2SWm7MQXJ6SlIwOs2oZDelOBZHxoES9uO+MiC2/BA0A2Cnqp0bAA==
X-ME-Sender: <xms:njYcZUcyGmgrKriML582cb96OGFLqyyTru5ZTAz6EMq7J3jkn6U-dA> <xme:njYcZWNOvQ-1UdaXIz1tLLwofcMR_ZIiylrUPtf7s0UqSS4-o3ndeHYFx1agqZfF4 YxJs9wCTnt3oslPuA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrfeejgddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvfevufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceorghl vgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepveeghe ejueevkeevvdfhheeuudefheegudeutdelleeiteehgeffieettddugfdunecuvehluhhs thgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvgigodhivghtfh estghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:njYcZViqq9y3FFOEJ-Pv80Tnn3QgyS2mcKuXPI7mNmSD04piJItJ7g> <xmx:njYcZZ8DJs7_y4rnO3x5dKsI_KIsm0GzMnxp2fkXk088m-vbHHHcOQ> <xmx:njYcZQspSGJuSCnmuT_zi3e1Xqe5LqpWssSb9F3sVKbTydUbhZt90Q> <xmx:njYcZZ7KKdwShseja0tDvF74dZy5Ff0vmCdJtioeXhqL-2DnhPVrpQ>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 011F92A20085; Tue, 3 Oct 2023 11:43:25 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-958-g1b1b911df8-fm-20230927.002-g1b1b911d
MIME-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Tue, 03 Oct 2023 16:43:05 +0100
From: Alexander Clouter <>
To: Ted Lemon <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-srp-23.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Oct 2023 15:43:32 -0000

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 


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 


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


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).