IETF Logo Mail Archive

[dhcwg] configuring SOCKS(v5) via DHCP

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 26 March 2022 17:03 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD813A1047 for <dhcwg@ietfa.amsl.com>; Sat, 26 Mar 2022 10:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4793qdE3LyE for <dhcwg@ietfa.amsl.com>; Sat, 26 Mar 2022 10:03:19 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20003A1051 for <dhcwg@ietf.org>; Sat, 26 Mar 2022 10:03:18 -0700 (PDT)
Received: from dooku.sandelman.ca (ipv6.dooku.sandelman.ca [IPv6:2607:f0b0:f:6::1]) by relay.sandelman.ca (Postfix) with ESMTPS id 689921F458 for <dhcwg@ietf.org>; Sat, 26 Mar 2022 17:03:16 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id C648C1A01DE; Sat, 26 Mar 2022 18:03:12 +0100 (CET)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dhcwg@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 26 Mar 2022 18:03:12 +0100
Message-ID: <75372.1648314192@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/L_CUJed4zI2H3agQSt8tXc0HjXQ>
Subject: [dhcwg] configuring SOCKS(v5) via DHCP
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Dynamic Host Configuration <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Mar 2022 17:03:25 -0000

As far as I can tell from
  https://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml#options

we never allocated a DHCPv4 option for configuring the location of a SOCKSv5
proxy.  But a few names allocated are sufficiently unclear to me that maybe
they were doing something else.

Or maybe some options point to some other configuration mechanism that can
include a SOCKSv5 server address.

Or maybe it's buried in a vendor option?  If so, which one?

SOCKS is surprisingly still out there in many forms, including that many SSH
implementations provide for forwarding arbitrary connections via a SOCKS
server on a local port.
I'm aware of at least two gc.ca departments whose entire firewall mechanism
is (STILL) based upon it.

RFC1928 did not include a discovery mechanism.

SOCKSv5 is being proposed as a solution to certain IoT challenges, where we'd
like to declare the ACL in terms of DNS names, but the policy enforcement
point, of course, only sees IP addresses, not names.

If there was a way to learn if SOCKS was in use on a particular network, such
as via a DHCPv4 option, then devices could use it on networks where it
existed.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email