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

Ted Lemon <mellon@fugue.com> Tue, 10 October 2023 13:27 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 2B959C1CFCE7 for <dnssd@ietfa.amsl.com>; Tue, 10 Oct 2023 06:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 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, 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 (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 q4Owzc84Jy4m for <dnssd@ietfa.amsl.com>; Tue, 10 Oct 2023 06:27:56 -0700 (PDT)
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) (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 BAFB3C1CFCE6 for <dnssd@ietf.org>; Tue, 10 Oct 2023 06:27:56 -0700 (PDT)
Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-1e562706d29so3305831fac.2 for <dnssd@ietf.org>; Tue, 10 Oct 2023 06:27:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1696944475; x=1697549275; 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=M7oQcmII7J6zu2K26VFMTuqFdEWkVa3Cg8becT/t1xY=; b=d4vwZsB5G4366ZUqzdiuvrDWrdeD2mQ1KUqPuhM+XY1VUH9K0/qFXMZ0KWDhLDXhVX hI8dNE0DWfkWVjnIgmS9ZQsaVlrOIzo8kocyZuQHds47noS7CML8wSCQznRJWglIr1yS npAV+/utGEjvWJ6G9nWPtTn7zEfLMCEvdmy57bmvm19/86NwZz13iO+Xs9C9YkYMODQh rxOpU1xL1w2KwlyYeKpOk1DMY7jaeXpRNy3sujXTvsWa5vRd9oVma3HkEJdVQuh8/rnc eMvXAytJ0mvvjLyEV4sgsNiDMAWcjSjOjsozchJqwp1z8PJHPwMyzuugjRKDy8oNCEny Fx6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696944475; x=1697549275; 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=M7oQcmII7J6zu2K26VFMTuqFdEWkVa3Cg8becT/t1xY=; b=g4QauPJNZTotzd9tVrKioQcI7VLCwrcLxDueGpPH6MNWWsgiuj/TV8UNg3YsvV+ODw mz2eHTXcz1rwGYxG7u5CAzfwVeCHQSB+wYlK3LqIhNHVgXWBStdkIwol+EvMql9BhsKJ TCm91SHN/MNxl1eenBFsvo+ly5y2dF77x0qG8IbixM0Ldhk3tKKtXnK+YZL9cfkAQ90y 2AqOj/13KO0wPltPt890mUuIhUwAd1GUNHoa+yWEiAcuhH8rNwpqCN+QnWa2575KnTJE 1l65UR9x82tQg/PuBwE7KP+5UpiXQMD0gEy1pbXI+YlrDpAqNLctDQNaY6EujDPcBNSh Msxg==
X-Gm-Message-State: AOJu0Yx2Ue2R5RI4+WDi4OXMw2XOOLeslMx/cp081KIE9t+Fb6hubR6b sKRabZs8BE3vNG7lFFBUbmI63aAoU7nejbUCioGUggpfyFZol0wh0tM=
X-Google-Smtp-Source: AGHT+IFqFeQy7t2pFdsK1DZLPsnFstO08Xy/ytz95arUOMPMPP6exB8wjuuvdjynKi8gqZe5C5LXnRMYEuJ09PEJIVc=
X-Received: by 2002:a05:6870:7195:b0:1d5:f814:567b with SMTP id d21-20020a056870719500b001d5f814567bmr20793868oah.5.1696944474805; Tue, 10 Oct 2023 06:27:54 -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> <CAPt1N1ndBC-yqd9T+08xoenT1stm5c0mP=2b2hWBFtF4VExJxQ@mail.gmail.com> <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
In-Reply-To: <DU0P190MB197824A5BFCF64175FBF48ECFDCDA@DU0P190MB1978.EURP190.PROD.OUTLOOK.COM>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 10 Oct 2023 06:27:18 -0700
Message-ID: <CAPt1N1nrGnRbkQ6Tt6ztdsKM5YHfSxz2s7deBxfsnh0EKVkDvA@mail.gmail.com>
To: Esko Dijk <esko.dijk@iotconsultancy.nl>
Cc: Alexander Clouter <alex+ietf@coremem.com>, "dnssd@ietf.org" <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009ff48a06075cac05"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Z2_NKX9LzYiwzxZ1wu2Hvjj6fuw>
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 13:27:58 -0000

A stub network can't have any subsidiary networks, so hop count can never
be decremented. However, having reflected on this for a week (?) at this
point I have to agree that this is too big a change to make this late in
the process. It's true that an off-network spoofed packet with an on-link
source address could be used as a DoS attack to the SRP server in theory,
but in practice I think that checking the interface on which the packet
arrived eliminates most of this risk, certainly for the constrained stub
network use case.

If we'd had this idea early on, I'd say it was a good idea and worth doing,
but at this point maybe what we have is good enough and we should not mess
with it.

On Tue, Oct 10, 2023 at 5:57 AM Esko Dijk <esko.dijk@iotconsultancy.nl>
wrote:

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