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

Ted Lemon <mellon@fugue.com> Tue, 03 October 2023 15:59 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 0A383C1516E2 for <dnssd@ietfa.amsl.com>; Tue, 3 Oct 2023 08:59:27 -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 2UHedxgqCSAM for <dnssd@ietfa.amsl.com>; Tue, 3 Oct 2023 08:59:26 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 F2684C14CF13 for <dnssd@ietf.org>; Tue, 3 Oct 2023 08:59:25 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id 6a1803df08f44-65afba4cfadso7459086d6.1 for <dnssd@ietf.org>; Tue, 03 Oct 2023 08:59:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20230601.gappssmtp.com; s=20230601; t=1696348765; x=1696953565; 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=bBo473CU1hKSCUjN26rfTFj1Ei90g3CuMQ9KcF4L5Zs=; b=ifiYGLIUoPkcRTwQQQOJ95J0REKXtPPaBFSmeR3PULf98mQc5ahLzwJkXfGAxTdDO0 ko1zCiuoFm7i0XOSjqn6O6gK/iDNKObDVdhXx30eIKLJhh0xfCHeawSqOzq4TNbdYYLZ YSc61fkBt9JrfkkicG+c9BeA6G5B37G7j+kNMzImG+akL/PC2SLo/493S0P9JPY/ktYr 2NDa3jDe4kNRuVFbMf5JX7H7MOSpe+bC4whsUMXbhol88KsR15uuvCczbdcfyrGKow64 VBpZCuIAsI/Qn+sAFk4UBolpQkARjv2tbHBmfyhQ4/yVNAoSGlk9baHwcAVaqrg+PGUo m4TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696348765; x=1696953565; 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=bBo473CU1hKSCUjN26rfTFj1Ei90g3CuMQ9KcF4L5Zs=; b=k2mfYGB+hqUJEsJpOXFRECLaM7N1ntg7uEqItHgQiTK0ucgAKKI4EGV2qQzdZtFr62 j5f8k38v2O4KqWm/bnBvOTMawe3udsJM3lpU/7xeATsOkmfYetkGvF12/D0qf3ilaFvP iN0SqIsn1xqKPEUFavugVUf5GVM5fHB2NWbuP60w94oa9IRHlKsdfJINEBND3bI5Gzgm Dg7oSl9NKzeHADnA/ZWUAFFuj/U9nKkocH0LafL3VCQrZ/H8tYanvN8Q4t9pDNsyR3Nh AuxmdOvzD88TWv1xRPWAg5KEF/SrNEfBGNVDFSUtWU6thWyP3i2rIuePiBHwogJ7a9jb 1M9w==
X-Gm-Message-State: AOJu0YzZ5Y6MqSUr9dIGyHEAS1CiDkNft8NPyseSL+pwaWEKdoYNZg1k 6uVJoqvCpz1Q5xLwbzzKD9t1srVgR40OK10verLIwg==
X-Google-Smtp-Source: AGHT+IE7/cxy4YjlZ97T2XzDZ3KlNW1St/P1XeUhqNhi4Mi02reCQ1SbLoFeknK/Co0TnZqeeXQn6y13kDKu2hGwGd4=
X-Received: by 2002:a05:6214:dc7:b0:65a:e5ab:b044 with SMTP id 7-20020a0562140dc700b0065ae5abb044mr25572796qvt.2.1696348764857; Tue, 03 Oct 2023 08:59:24 -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>
In-Reply-To: <CAPt1N1ndBC-yqd9T+08xoenT1stm5c0mP=2b2hWBFtF4VExJxQ@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 03 Oct 2023 11:58:49 -0400
Message-ID: <CAPt1N1nLLp-JSvUQRokehapQmVHzHtbZUB6a8wZBsSS-5293JQ@mail.gmail.com>
To: Alexander Clouter <alex+ietf@coremem.com>
Cc: dnssd@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008b7a9f0606d1f969"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/mIVq458Py4mxZVcEeyEkV0DAv8Y>
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:59:27 -0000

(your proposed text looks fine)

On Tue, Oct 3, 2023 at 11:58 AM Ted Lemon <mellon@fugue.com> wrote:

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