Re: [v6ops] Are we competitive?

Ted Lemon <mellon@fugue.com> Mon, 15 August 2022 15:03 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68169C14F728 for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2022 08:03:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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.20210112.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 siGZx-hXT5Dv for <v6ops@ietfa.amsl.com>; Mon, 15 Aug 2022 08:03:41 -0700 (PDT)
Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D66B0C1524CB for <v6ops@ietf.org>; Mon, 15 Aug 2022 08:03:28 -0700 (PDT)
Received: by mail-qk1-x72f.google.com with SMTP id i24so5671252qkg.13 for <v6ops@ietf.org>; Mon, 15 Aug 2022 08:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc; bh=R4E/BEStiP+aXY2GTfZuIkE2M9dh8oacvh/CrL+FYkw=; b=cWocCrR9iIaUSQdS4Y0tBXHkCoRSBcYmdGIjQxYl+O7bpaEn7jQ+S7LWShdmR8+O+k Wqy8MH4S1+e3HCRsY2YhNCGJoDJPHW+CnHVid+oRVW5j+inAMKdc2aa7PzHk3Z/qx32c QijT6GxeOMGPirKcuzO0Pik09FHn1nnbM13fmj1fiOtNyYXa2Nk/KFOGTem3SiTuovhg 5daAvmBAblwzjp80iP13EjKhHORAbu8RJCjInnccdK3vB1IyVZBU5ZDE+4UDrsjN7AfJ OFxj11lZedZXERYvRXlaLB9B2dIdcVvQqk3sZpHf4noCbuyLM5OQw/uMOEwG89yQ/Pe3 oAKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc; bh=R4E/BEStiP+aXY2GTfZuIkE2M9dh8oacvh/CrL+FYkw=; b=XicfP94rhh2xkRnpv8vQqySL4cX2xcJ02mFkNmBgunEEUQ6kPxevpycUR6CCYXxYd9 P9WvwaQf7MPe95EcQkftcoqMVLNUt7XhNRqHGv93DU++CyH+6znD5qkfU2Rfu5ZkEsAB Y/zVfjxo8P9lemN+Zk7TBry4uw4HneqnQYxEP+Bt2HV2UmEcrO3L4zEO7kA8uAGb23zX zaS+qKHuNXlGla71v3i90SnPVFOqe9jHQoj/EUlVSPkA/J7PtdjR8pv+u8oIfS3LPHxq Q+S71lgmDMZBWx8L6p/ST4nU+uRhD32lvhlNyoy0j9zz5xo0ahHfpMpJkRNoJDz0xZOy SwPA==
X-Gm-Message-State: ACgBeo2Lz5kchmvvf8y4fv4/AobwP8iWOCCDr3dLjUlZ0dteinQZmRhu qdtnnFedguMLk8yeXEIkcGRh0w==
X-Google-Smtp-Source: AA6agR6LqYi05psPIo9kkgpJk9g7F/UZpDcSJ7pVp1ZPIEkOhkHc6D5o9eecHeM9m9q17XkC8PO73A==
X-Received: by 2002:a37:b13:0:b0:6bb:743:9496 with SMTP id 19-20020a370b13000000b006bb07439496mr6147374qkl.620.1660575807606; Mon, 15 Aug 2022 08:03:27 -0700 (PDT)
Received: from smtpclient.apple ([2601:18b:300:3380:7463:c3e9:af1f:efff]) by smtp.gmail.com with ESMTPSA id n5-20020a05620a294500b006b93fcc9604sm9736179qkp.108.2022.08.15.08.03.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Aug 2022 08:03:26 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Aug 2022 11:03:26 -0400
Message-Id: <101D1787-3A08-42A2-A6BB-E71154D515C1@fugue.com>
References: <c43e3ce9-86d3-307c-270b-ed3a8cf33ecc@si6networks.com>
Cc: "Soni They/Them L." <fakedme+ipv6@gmail.com>, v6ops@ietf.org
In-Reply-To: <c43e3ce9-86d3-307c-270b-ed3a8cf33ecc@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: iPad Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ZLfgACaZwXxX9NSOltxkj8xduMY>
Subject: Re: [v6ops] Are we competitive?
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2022 15:03:42 -0000

I think the thread model for which you’d want to conceal IIDs is that you want to prevent callbacks: if a host on the protected network makes a connection to a host on the Internet, you don’t want that host (or some other host) to be able to attempt to connect back to that IP address on a different port looking for a vulnerability.

If that’s the case, then you can accomplish this with a firewall. All you have to do is default-block incoming SYN packets and incoming UDP packets, and you’re done. This is a lot cheaper than maintaining per-connection state. The only problem is that it breaks QUIC. I think it might be possible to do the same thing with QUIC, but I don’t actually know how the initial handshake works for QUIC, so that’s an open question in my mind. 

If any random QUIC packet can’t be distinguished from a QUIC session-initiation packet, then you do need a stateful firewall, at which point NAT66 is no more expensive.

But assuming that’s not the case, a stateless firewall is definitely cheaper than a network address and port translator.