IETF Logo Mail Archive

Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)

Leonard Crestez <cdleonard@gmail.com> Sun, 25 September 2022 13:19 UTC

Return-Path: <cdleonard@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67569C14F72D for <tcpm@ietfa.amsl.com>; Sun, 25 Sep 2022 06:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KpLenBO1omKS for <tcpm@ietfa.amsl.com>; Sun, 25 Sep 2022 06:18:59 -0700 (PDT)
Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 29C68C14CF06 for <tcpm@ietf.org>; Sun, 25 Sep 2022 06:18:59 -0700 (PDT)
Received: by mail-ej1-x634.google.com with SMTP id hy2so9106544ejc.8 for <tcpm@ietf.org>; Sun, 25 Sep 2022 06:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date; bh=l2gy/Yw0MIhMxxpW5jaT+ku09eNdQr6+qFTyURxKsXc=; b=QlvqHGeMeY2Xlh9qOywtzKxYx5Z37b83QgtS/bqCEHcF8ZkpH3x1N1a4hUOVhGUltG gNsMgk8LGexJg6weLkDSMvbUMFPzodr6CdTRzZq1+HBjIbXbXHX66mty5f6yL3jWDBv+ BeVjS8cPNWU028sGkTSdkkph7Ulw/9elhx5cWm36VHeXMi7KOzQXFExGoPvjizD9t8KN ePrfuUTjVlBdNpxaaCZJwUvQxHSOCMa3R9NOKbWwOj+qmaivE6iRL7H5cYwCZn0azAgm U5C+gfgY+//BiBWt0Q0NxhuhFfPy2TYJRY6CWYw79h6pap9584vma0zzrUUjXjVsRzEA VXQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date; bh=l2gy/Yw0MIhMxxpW5jaT+ku09eNdQr6+qFTyURxKsXc=; b=fnPUFx7JOtUFwqQE8qqC2Z7an1hPI+GdVtcvS7Y6s6vIFNAK0qsxaPF7qcLrWPELTE Xzae5okq0psvnJhnOU1oNHEJz1gihwxaZOqZbw2r7nDNLoffBi557XwAvuV339sVuaRl BsiIAxszle3Oz+nZJB4a1OgmPrdxhEBHx43sqhDNHHl0GyJJPpAzPQiq22Xx+7kmSV7D 5zCVGY+ohVYjEPFL1+NHDLBLsn/RDK4vDazJS08dOswiNGI0WkS5n6g+75oNZaq+zW/u a5w6vJQ9vSs/bjrBjR5xlrsCrBxq8HDXNW/TxGcdTi/U+3Rz7u1/2/mrk/LGsDaWnceb kI1A==
X-Gm-Message-State: ACrzQf05jVGNirbgDtEuSk5pNJOfqWZdVfReFzSiZnkPU9psDGZu1QBl V1sg57g0ll/x3zE0wD8J3OU=
X-Google-Smtp-Source: AMsMyM7IeEH4yry+VldC6Yj7a1ZYDawdHR1ojvWc9rcDlzkv9/0TMUevaoNto6gEpm17W1jEkIwB0Q==
X-Received: by 2002:a17:907:7284:b0:780:2cba:3079 with SMTP id dt4-20020a170907728400b007802cba3079mr14584506ejc.51.1664111936555; Sun, 25 Sep 2022 06:18:56 -0700 (PDT)
Received: from ?IPV6:2a04:241e:502:a09c:3b78:d22a:2bc5:1db8? ([2a04:241e:502:a09c:3b78:d22a:2bc5:1db8]) by smtp.gmail.com with ESMTPSA id o10-20020a50c90a000000b00455262f83aasm6795480edh.32.2022.09.25.06.18.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Sep 2022 06:18:55 -0700 (PDT)
Message-ID: <ebf96672-d456-9c71-7b51-cf032bde82b2@gmail.com>
Date: Sun, 25 Sep 2022 16:18:53 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: "touch@strayalpha.com" <touch@strayalpha.com>, "Natarajan, Venkatesh (HP-Networking)" <venkatesh.natarajan@hpe.com>
Cc: Dmitry Safonov <dima@arista.com>, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com>, Francesco Ruggeri <fruggeri@arista.com>, Allison Mankin <mankin@psg.com>, Ron Bonica <rbonica@juniper.net>, Michael Tuexen <tuexen@fh-muenster.de>, tcpm@ietf.org, Salam Noureddine <noureddine@arista.com>, RFC Errata System <rfc-editor@rfc-editor.org>
References: <DS7PR84MB3061E20930DCEF5E5C867483F74C9@DS7PR84MB3061.NAMPRD84.PROD.OUTLOOK.COM> <7C3A53C8-7D86-410A-BBC5-737546127E14@strayalpha.com> <5c4b3a52-259d-08bd-8db8-59a49c6d9504@gmail.com> <1099B2E2-B8C8-44DD-9F9F-63393CFF659B@strayalpha.com>
From: Leonard Crestez <cdleonard@gmail.com>
In-Reply-To: <1099B2E2-B8C8-44DD-9F9F-63393CFF659B@strayalpha.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/qYtbt6aYOr-MzI5KsTNhv7YifsI>
X-Mailman-Approved-At: Sun, 25 Sep 2022 08:02:57 -0700
Subject: Re: [tcpm] [Technical Errata Reported] RFC5925 (7135)
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2022 13:19:03 -0000

On 9/24/22 19:40, touch@strayalpha.com wrote:
> HI, Leonard,
> 
>> On Sep 24, 2022, at 6:37 AM, Leonard Crestez <cdleonard@gmail.com 
>> <mailto:cdleonard@gmail.com>> wrote:
>>
>> This behavior is not described by RFC and seems to completely defeat 
>> the security provided by TCP-AO by accepting all unsigned packets. 
>> There does not appear to be any usefulness outside of debugging
> 
> It is explicitly designed to allow either side to decide whether TCP-AO 
> is required or optional on incoming connections. The current default is 
> that both sides allow the connection to support legacy mode either when 
> the option isn’t present or when the key fails.
> 
> If that’s not desired, either side can set an override (as already 
> mentioned in the paragraph noted in the errata request. If you want the 
> override to be a default on your system, that’s your choice.

Accepting signed segments which don't match an MKT is not sufficient for 
establishing an unsigned connection. The other side must also be 
configured to *accept unsigned replies* to its signed packets and no 
such flag seems to be required by the RFC.

It might also make sense to only accept mismatch on SYN segments because 
otherwise it would be possible for a TCP-AO connection to be interrupted 
by an unsigned RST.

Do we agree that the cisco "accept-ao-mismatch-connections" is outside 
the RFC?

--
Regards,
Leonard

v2.23.0 | Report a Bug | By Email