[Int-area] SOCKS6 and UDP

Ben Schwartz <bemasc@google.com> Tue, 10 December 2019 17:12 UTC

Return-Path: <bemasc@google.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5B01200E5 for <int-area@ietfa.amsl.com>; Tue, 10 Dec 2019 09:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 y3YNSCSXFXc3 for <int-area@ietfa.amsl.com>; Tue, 10 Dec 2019 09:12:38 -0800 (PST)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E587E120089 for <int-area@ietf.org>; Tue, 10 Dec 2019 09:12:37 -0800 (PST)
Received: by mail-io1-xd31.google.com with SMTP id c16so19586883ioh.6 for <int-area@ietf.org>; Tue, 10 Dec 2019 09:12:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=u+Bn+X/SoHveJkErfU80UIDc+SkhYMMTBz6Rx+9tQbE=; b=gCun6IxHBNqATNpmFojA5sCN677tMACaiI5Q3lIKH8Wgf0GvOzj9BwsNG3JqwzXPET Yjv8qNo7u2HiILp0xj1HWDDo1ZYXtygqrdavnu1kVo60kaAeAkQV5ChkUSpEGhuT29VB Wo+NJvqilfpRM0BIuyer0Qvu3gQ74Cp2POBjBikjW5bLniFD69VtmgKz/7kLZULnpVlV rNxDYmG+PrgMLJ87xNV05GgW46vjf4UVX9baJKqlJ3Kx0hF5aDI8eGGlThlWKrc7qP5j EAOO8PNmbgatiKGofU4rnGT+ty5jsiOraM9oqIryphlEwmXt2AZk3XDkAvhQVY/xROH8 nq4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u+Bn+X/SoHveJkErfU80UIDc+SkhYMMTBz6Rx+9tQbE=; b=fi6rQxTWKB+M/CXKAjxp6wzOvZyu1KkLmISnboJNrF84cHWbLxsBjB0aYalggm0r5w JI/p2CwC1+JG+KOij2vg/2OAc+Fc+Td+60qZso221vBn9eitinoNETIrxzh4Xg8z85fy 2fSJTehOAE+NskceUSjuWPFwFzRznkauO+3ifqpDhRuKruKHWTFBpLYMqBuKAmjz01BU DItqShXaxEuWb0hUMr6OwzFeIUhGqHsmFHKyCnfrteK92QmyoCl5nuUlnrFWwLxlnYum K9abg6f7l5uTOUgZncfu2A+ciSGCFu2UiL6m7IBOTgXDZbLVWhsg2OOOlMAxLiQCXPQT hHXw==
X-Gm-Message-State: APjAAAUepT2LSb15w3G7OCVP/HKvFFpvVo5CJASHeKqXb1M2+zno63L1 +guwA+P5dnFpFA+GhXOwq92myfS6BTOOkhQ3n5Acb9ZJ6Gs=
X-Google-Smtp-Source: APXvYqx2anDKJoatDCqMrYGJ4H7H05khRPFvrhGYp9w19H0LMyR3LrJRNY8yaZGCl4vU62TxR1R5jdQTgnltoFWhkDk=
X-Received: by 2002:a6b:7117:: with SMTP id q23mr19459650iog.153.1575997956524; Tue, 10 Dec 2019 09:12:36 -0800 (PST)
MIME-Version: 1.0
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 10 Dec 2019 12:12:25 -0500
Message-ID: <CAHbrMsDgP0zvjhgsqvv2rvxBo69c-W0agnv9+pe5MeF2j+fOuw@mail.gmail.com>
To: int-area@ietf.org, Vladimir Olteanu <vladimir.olteanu@cs.pub.ro>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="00000000000067312305995c9e4b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/cvXJK16vUlakmdPg494QwIn_4Ag>
Subject: [Int-area] SOCKS6 and UDP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2019 17:12:40 -0000

I have a few notes on the SOCKS 6 draft, related to UDP.

1. I would like to require servers to share resumption between TLS and
DTLS.  This would allow clients to keep a single resumption cache,
instead of two.

2. I think the protocol should support sending UDP datagrams over the
TCP socket being used for UDP ASSOCIATE.  If the client sends a
datagram on this channel, it would become the mapped channel for the
association.  (Alternatively, it could serve as a "fallback channel"
when there is no UDP-based channel available.)  This would be faster
for short-lived UDP transactions, because the client could include the
first upstream packet in the first flight, without needing to wait for
a reply containing the Association ID.  It would also help in cases
where the client-proxy path is UDP-intolerant.

3. The 64-bit Association ID seems like a potential security
vulnerability when using DTLS.  Suppose an attacker observes a DTLS
connection attempt from a client.  If the attacker can block the true
client's DTLS, they can start enumerating Association IDs until they
find the one that works.  Enumerating a 64-bit space is not easy, but
it is too small to be considered cryptographically strong.

Putting a very large Association ID at the beginning of every packet
is not appealing, but with DTLS there may be a more secure and more
efficient solution.  For example, the client could include a longer
Association ID only until it gets an acknowledgement from the server,
at which point both sides know that the UDP association is mapped to
this DTLS connection.  Alternatively, the client could send some
information about its DTLS ClientHello in the TLS channel that sent
the UDP ASSOCIATE, creating a secure binding.

4. SOCKS6-UDP is not compatible with PLPMTUD
(https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud),
because the client cannot control fragmentation at the proxy.  I think
we should add a "Don't Fragment" bit to the SOCKS 6 datagram header to
support PLPMTUD.

(I would love it if SOCKS 6 could pass ICMP messages for classical
PMTUD (and ping! and traceroute!) but I don't expect that to happen.)

--Ben