IETF Logo Mail Archive

Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues

Klaus Frank <klaus.frank@posteo.de> Mon, 07 February 2022 19:47 UTC

Return-Path: <klaus.frank@posteo.de>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62C63A083D for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 11:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level:
X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=posteo.de
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 bEqa-F0RDjC0 for <behave@ietfa.amsl.com>; Mon, 7 Feb 2022 11:47:41 -0800 (PST)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6912A3A0653 for <behave@ietf.org>; Mon, 7 Feb 2022 11:47:09 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3C37724002A for <behave@ietf.org>; Mon, 7 Feb 2022 20:47:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1644263226; bh=Vwhq7fMSgHynqkcTSWRJmM8Kq3muTHATKIvc+DEP2EQ=; h=Date:Subject:To:From:From; b=njWQh7XAmRsYKBHgHjXx+6BHk1y0vPHX7dZkqysZabLtS6mcNytfcQhm0sliJQN+K uqQdTfWCjHCExwfbPRLTSQYhOawaGWOoKr40+3448k9IfvFJiJE8DuWvhuytIV/5tG M9f9hH+VFjgPxnwNag9nePMGSeEp3GABSCFIG+Kc9VrE2MCd2TwILnO8udTLShF0BZ qAePMEfkI1GG7R3D8TdN5N1GnR3Iw/Ru5kxxXGQa/5ux+SmIOFK8FXJJsLddmAiGgg 8JPh6BIUB3v0fJSzG5hVX5f09MoSiLTuDgh23aM6pvlPY+yAASxfwCnJUg/wUOmwZT 24Dyee3EJ6wgQ==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4JsxVd1HG7z6tmV for <behave@ietf.org>; Mon, 7 Feb 2022 20:47:04 +0100 (CET)
Message-ID: <05e6cff9-3d9f-fac6-82b7-492b21726a0f@posteo.de>
Date: Mon, 07 Feb 2022 19:47:02 +0000
MIME-Version: 1.0
Content-Language: en-US
To: behave@ietf.org
References: <077D662F-5E6D-44F5-8DD3-B58D8B535C5D@network-heretics.com> <B6D6B4CC-AC1F-459C-952A-E9493E00FDB3@huitema.net> <7e53925e-46b0-29e4-6deb-47bcf389ff97@posteo.de> <DC6F8DB5-4D01-466F-A042-1769E5FBB677@gmail.com>
From: Klaus Frank <klaus.frank@posteo.de>
In-Reply-To: <DC6F8DB5-4D01-466F-A042-1769E5FBB677@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms070305030709080707050909"
Archived-At: <https://mailarchive.ietf.org/arch/msg/behave/HU2jfXg_PGlRpTIebRF1nYJJ_kY>
Subject: Re: [BEHAVE] RFC6147 and RFC7208 interoperability issues
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/behave/>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 19:47:55 -0000

Google and O365 have a lot of IPs in their records. Currently the 
standard is to specify the subnets instead of dns names (for whatever 
reason). If you now further perform TXT-RR lookups of these includes 
you'll get new SPF records that contain lists of subnets e.g.:

google.com ("v=spf1 include:_spf.google.com ~all") => _spf.google.com 
("v=spf1 include:_netblocks.google.com include:_netblocks2.google.com 
include:_netblocks3.google.com ~all") => _netblocks.google.com ("v=spf1 
ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 
ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 
ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 
ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"), _netblocks2.google.com 
("v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 
ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 
ip6:2c0f:fb50:4000::/36 ~all") and _netblocks3.google.com ("v=spf1 
ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 
ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 
ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 
ip4:130.211.0.0/22 ~all")


On 2022-02-07 20:37, Dan Wing wrote:
> Klaus, David,
>
> I just grabbed an email in this thread to propose a different idea:
>
> Could the SPF problem dissipate if SPF records only contained DNS names and deprecate IP addresses?  Consider we had (and still have) the same issue with IPv4 addresses in URLs (https://datatracker.ietf.org/doc/html/rfc6586#section-6.1, e.g., http://1.2.3.4) which break with DNS64/NAT64 because 1.2.3.4 is not a valid IPv6 address.  The solution there was (and still is) push those deployments to use DNS names rather than IP addresses.  Of course nobody wants to spend their career chasing down websites using IPv4 address literals, which is what begat 464XLAT.
>
> I don't have a list of top NNN mail servers, but I see both address literals (e.g., comcast.com, microsoft.com) and domain names (e.g., gmail.com which does SPF redirect to _spf.google.com which has only domain names).
>
> -d
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave

v2.23.0 | Report a Bug | By Email