[Masque] Comments on draft-age-masque-connect-ip-01

Eric Rescorla <ekr@rtfm.com> Sun, 07 November 2021 23:12 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF7D3A1136 for <masque@ietfa.amsl.com>; Sun, 7 Nov 2021 15:12:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.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 UDF7YPQexAtX for <masque@ietfa.amsl.com>; Sun, 7 Nov 2021 15:12:46 -0800 (PST)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 C09983A1139 for <masque@ietf.org>; Sun, 7 Nov 2021 15:12:46 -0800 (PST)
Received: by mail-il1-x133.google.com with SMTP id f10so15178979ilu.5 for <masque@ietf.org>; Sun, 07 Nov 2021 15:12:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=nCwNIHPRu/Yd0i2FcrxvVZXJ5lQAfYpcAaor/nKHt+A=; b=CHaXU9cz6wAdOG/38zTQ/DKJx65IxNWiSEcnN/Vo7stFRaA5bgms8Fp1SIQvehVELc 8iUZ+sZKqlKaURGeZtz8YhVyAe2wsdSLH8VNj9W3DJRUb46J0oAxwrc2Km4DsiKsl6El A2w5kGYNPrfxd+eBdrOyfiwrTLx/JUMVUWqmb28P+cHQmbw2685jVPVlx+Z6B0r1ClwM AZPJz5k5PbY62dFAE1FcoSW5nKau3qrDf10/ADE1gL/p0gVJGb6QM99pvDFjRBrEkO83 oe5DubCQ9AvR6Xv19mflgZPB/9lMKITYh5GdKLzLeUu17VwW6OEnPvZ0WVXaCQw2zZ72 88FQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nCwNIHPRu/Yd0i2FcrxvVZXJ5lQAfYpcAaor/nKHt+A=; b=jS9iPldgwdx2UqIsGRMypfZLnN7kHrpavGqRNc5Mqf/Gva+KZas7fbPVG/EqvZ800u XHCYgzUXUAtTzuUgSly0V3HXQBN903OBUhM95bBCLdI7QeBAgkd+DPEwmQzS7HQisXDD HEnsbQtyg0Gq6siB+XZtegupIn3BWG3qEwYngD8cofqjvPa8aeFsJuGf0ibdWW+CewUQ 0nzTyMzkwaM0XSQC6pYFFvJEC/lUmBFO76/W7vQUDiM7wqwGy7miMLw/EtPS3/zVpwFv S1RLiRCi0fOqw3nMLmZFoT457qxXCq/AOYRoIsofKWMLo6xEPGjeKYX8RE7rDYxO8MXK /u3Q==
X-Gm-Message-State: AOAM533uiTaZ+m+f366fqXhFa2siiaCLhQFXk5r/Po4JZrO8YsbsJ0Ks eur5qVGIBBJ85g1TkB358aM4l8XFqlOIbAvvW+bIGcKtRa9bNQ==
X-Google-Smtp-Source: ABdhPJzzCl9Zh5vNxVfH+xlyUrszMduEjIMWfKITwZ9V32Z4Li63FdRSO36O+pUlEAYanQDP8EpCGrTG5q9wvkKbZPk=
X-Received: by 2002:a92:c569:: with SMTP id b9mr36050959ilj.39.1636326764068; Sun, 07 Nov 2021 15:12:44 -0800 (PST)
MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 07 Nov 2021 15:12:08 -0800
Message-ID: <CABcZeBMSe7JJ41EC+f1pyAFrm_+9TU2h=SY-_Xy5vX5wu8TgOQ@mail.gmail.com>
To: MASQUE <masque@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008257ba05d03b03d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/_LM36Pakcq-tbEDrnxZeKGRjlig>
Subject: [Masque] Comments on draft-age-masque-connect-ip-01
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2021 23:12:48 -0000

This document seems like a reasonable starting point. Good to see
the authors converging. Some technical comments below.

Overall, I wonder if we should actually forbid the client from
using IP addresses in packets when the target is specified.
That would avoid goofy situations in which the client does

   CONNECT 192.0.2.1

And then sends to 192.0.2.2.


S 4.1.

   target:  The variable "target" contains a hostname or IP address of a
      specific host to which the client wants to proxy packets.  If the
      "target" variable is not specified, the client is requesting to
      communicate with any allowable host.  If the target is an IP
      address, the request will only support a single IP version.  If
      the target is a hostname, the server is expected to perform DNS
      resolution to determine which route(s) to advertise to the client.
      The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes
      routes for all usable resolved addresses for the requested
      hostname.

This treatment of DNS names seems like it's going to create a lot of
additional complexity: for instance, how does the client know which IP
to put in the dst field. You don't specify that the
ROUTE_ADVERTISEMENT MUST *only* include valid addresses. For instance,
suppose that the DNS name resolves to

  192.0.2.1
  192.0.2.2
  192.0.2.4 <-- No 192.0.2.3!
  192.0.2.5
  192.0.2.6
  192.0.2.7

and the server advertises 192.0.2.1-192.0.2.7.

Given that this is an IP layer mechanism, I would simply remove the
DNS option; clients can always do DNS over the tunnel.



S 4.2.
Is the server required to send ADDRESS_ASSIGN? If not, what is the
client supposed to use as it's source address? Also, what happens
if you only get a v6 address but need to talk to a v4 endpoint,
or vice versa.


S 4.2.3.
You should probably say something here about how in many cases
you shouldn't trust a ROUTE_ADVERTISEMENT. For instance, it's
incoherent for an ordinary consumer VPN client to start
advertising routes.