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

Ted Lemon <mellon@fugue.com> Tue, 03 October 2023 15:58 UTC

Return-Path: <mellon@fugue.com>
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 0AB31C13AE22 for <dnssd@ietfa.amsl.com>; Tue, 3 Oct 2023 08:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20230601.gappssmtp.com
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 0jbUDy4w4lCN for <dnssd@ietfa.amsl.com>; Tue, 3 Oct 2023 08:58:44 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B22BC159495 for <dnssd@ietf.org>; Tue, 3 Oct 2023 08:58:44 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-d867d4cf835so1134062276.1 for <dnssd@ietf.org>; Tue, 03 Oct 2023 08:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1696348723; x=1696953523; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DWuiMJS2jYLvJizRJs6EBSGGZ7jAmgv1Xi3D64czF6o=; b=FcNuljzgVi+1m7FVCL5VAt6+dxSEn1FY28Ol5tY3Z7TL01LSBaz2SMPoKDQLMVG9oz HfnLQkUu2GXkIfrPhPrqg8ciTwUEWkjbSknFPkBkfrMFiCk9CVPNOguFoPXVxZLLuKIP XRK/vV2B+TZOulLjkPBrtfvjv/0HFvzZbjod3uWYnzUI1kJCSxFBySOof/xVSQ4BLf7x WMx7XKoyH5zUyEBvX/1vykYurM4YoKCn0i08jP8NUWwzWjCDmQAOzf/dWM0iPZ4475gH D4HsIxdRj5g4WSDi8G0jdU00lzLt32ofl5Xk0FfEzfRwDAYRQSHd97u7+YmYjvWqvEup vAdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696348723; x=1696953523; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DWuiMJS2jYLvJizRJs6EBSGGZ7jAmgv1Xi3D64czF6o=; b=VwnB4J243sQ3cMXVrUW7eIorrjzdSB/ORqRpdmUzC9bfGnSIrdzo/TanIRAhE9zu8Y uCUvh2/ADTHR0eXNEhdNiTb0Bg9KTKoVR+HaoskamP/xroExYH9zkRcoe789W141e/Y+ TQ3torcnZ5rTo66NYIw9RH+6gC05QFqbg1fdG20Wul1yP1Gn/gvrkpRjuTYeJmrfdJpQ NFGfFEPi+6iQ7ybbvLxV7muhzh+ebrP0CN8LOlIyHWnPhPwnUH0MfuVSmPCr0jwzor8Y Evd96EEtxVaql6PERzJw5tMmPefFIu6y2c620bLiGV6z7Baco049+0+BVIFQ7pNPIpSY 5XeQ==
X-Gm-Message-State: AOJu0Yyrup5HUdYb8H0SNU0CUYrqP3ijb8yvJ+EidcDNRX89RBpjzTgw 8XO7ZRYcY4ay3DkbAE3k7aOkytixukbeQ8uBjOd7QA==
X-Google-Smtp-Source: AGHT+IHP3grpZiR2zBH0Mh7YWn6cxSUsifNnGsPzXybsIDdMsWFBMkCr/oHcQMyC7vE1of+9LMjuzqqJ3A3VMuvvRxQ=
X-Received: by 2002:a5b:dca:0:b0:d3d:74b6:e079 with SMTP id t10-20020a5b0dca000000b00d3d74b6e079mr13807539ybr.53.1696348723175; Tue, 03 Oct 2023 08:58:43 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <65676093-1ec8-4693-af49-79141507b6c3@app.fastmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 03 Oct 2023 11:58:07 -0400
Message-ID: <CAPt1N1ndBC-yqd9T+08xoenT1stm5c0mP=2b2hWBFtF4VExJxQ@mail.gmail.com>
To: Alexander Clouter <alex+ietf@coremem.com>
Cc: dnssd@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000f789e0606d1f71d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/qk_vAfuG5nedU1c-uU31XyPxaBQ>
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, 03 Oct 2023 15:58:46 -0000

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