[Idr] Re: [Sidrops] Re: BGP over TLS/TCP - draft-wirtgen-bgp-tls-05 - draft update

Thomas Wirtgen <thomas.wirtgen@gmail.com> Tue, 21 July 2026 08:23 UTC

Return-Path: <thomas.wirtgen@gmail.com>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 3E16211B238BA for <idr@mail2.ietf.org>; Tue, 21 Jul 2026 01:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784622223; bh=EYdMeRwIz50ffqlvREzFn2NG6kdYZyZC3OulehG7fGI=; h=Date:To:Subject:From; b=ZSMaVlX1e6IShJ5O07Zc+oeTPgzoZmB8PIkodxghVNEt9EjHV2T35zaqfEvypLR8u 9fiHekHdNeFl5vnVgGHpr7STJ1VSwfzqshOgQzWjBnC65S/fyJ+k6a+6j8ni6ifzdl KmC74ly6HJrjecIzjwSqW1IY55fIiBUxdJRXe1h0=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pCre5Pvnr_t for <idr@mail2.ietf.org>; Tue, 21 Jul 2026 01:23:42 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D69BE11B238AE for <idr@ietf.org>; Tue, 21 Jul 2026 01:23:42 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-4955de8797cso11030245e9.3 for <idr@ietf.org>; Tue, 21 Jul 2026 01:23:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784622215; x=1785227015; darn=ietf.org; h=content-transfer-encoding:content-type:from:content-language :subject:to:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to:content-type; bh=KWh0t0dY1eWOldVx5JwSnte000cwjypDCx7ykfvMG6g=; b=g18mn1o9an115QWkw7j2ZRQwA+aeyrEl/3Z6v6V3FO7Ijk0uuLjWynHHUchEQofgAD AptcuGwwBcqMN6aMXawEHMFTqMzkpm5LRPxMxM1wr+HiDUQctiGyGGYQhe6HYmWxfFMm +V2pef2ycDCM3PwP7lW7Gq7Ic+6+Q6lNKOHBfMwiRlTmnk+9AzP8u3CycyAKAgj/aXgq cpjpkj47ch/8BX17isMKCoeJeVu4YwTJxz9Gpo5mewc3EELEGfl9/xlXviJVO01QMB4y YByPN4YMS0tywRiSs63XPZNVFhUslRdN+wAJUfUKaOW6kRrfqbT46Nl6mpiwRpUhwBYE ITAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784622215; x=1785227015; h=content-transfer-encoding:content-type:from:content-language :subject:to:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=KWh0t0dY1eWOldVx5JwSnte000cwjypDCx7ykfvMG6g=; b=jdI3VyLcLVCUfF5JY0+zXm6RXA7H3ISGZf7PgfkfOFu6CuHOdIngU+7U2TMtMyF5FY utsW9Ni4hV9LL27X93zTJ/ai+w08NfAw1FHbfhLl+GZcrnUNIsIK/Hu5XW7e+bC4rQKu J10t3/kh3TZFl6djeZeEgzNs9W4nQWTytoslRBIpGfNbHipDtrBR17gQXS8qV2HG4llC mxW1w1lsXWmdXkF0nZQAf4j8pzB8rBAZ25dyEwfyILS5Hw2G3kqulvOBNZ1LF5AdNkj5 7zMxvYrPJsTQ84qrxyuxKnkc7ACXPYtqZtxcepZkBSaEim41Qt+WUkmUBfnpJ2qyBZqg 7EGA==
X-Gm-Message-State: AOJu0Yz5Okij4nz7chwpSI4JhDEfhdYhbSCqF5PFKAlOHG9VhPlWrsnW 1wjp5+c0LAkx9pp9xa8xjx5wAK/jH/XKGTvhp5qCVStVDdxkdoaSaH51MsParQ==
X-Gm-Gg: AfdE7cnGZL29t6LoVaPYsEAcNLcQoY9MBrGEFo5IPFZv7haTTmsHNF3djxzp4rGK0em Qqsb2VDsgRTPTo5Y+OkHLZj2qBAYakXgf0sPNqi49oV8qXp6c8F4OyEK7yahfSR6W7oUiOoMHOf 3LIHBgnwblbAPbF7T3m4+EUszVyanm4QBPq82+piPOndzVJDmL0vNLp7hPAsDijqs3OuVF1rmzw 5jInaW4x5n4By3QhqRNFQ60i5NBksOT52fqcUhOAGS6nDMbzNHTDjilI6UU+X/FFfkrArT2dt50 /EzWVdjWYvFhRw8XyfROyyQNJRoh1iYbVBowXCQGL7T33wv4iTxbafcMh8KVAUpYwKo9ciVqjap bzDp+3RXZZhw8kaQUgza/1E/66RktuRjWyFX+e/vvamcDBZZwDycuA3xs25MUQZcyCJMX3sFmaF y6kxUGys5jFmFKfJOdUuaGLLk9SBdnE91b++lrtJR7CYmudZoWKmGxbQ==
X-Received: by 2002:a05:600c:4694:b0:495:6713:9aa3 with SMTP id 5b1f17b1804b1-4956713a11bmr17786485e9.30.1784622215365; Tue, 21 Jul 2026 01:23:35 -0700 (PDT)
Received: from ?IPV6:2a02:2788:478:123:e7ce:95f3:5076:f16d? ([2a02:2788:478:123:e7ce:95f3:5076:f16d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f63ed244bsm896946f8f.20.2026.07.21.01.23.34 for <idr@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jul 2026 01:23:34 -0700 (PDT)
Message-ID: <039b0cb1-ceb8-4466-bfcb-8d93b601b67e@gmail.com>
Date: Tue, 21 Jul 2026 10:23:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: idr@ietf.org
Content-Language: en-US-large
From: Thomas Wirtgen <thomas.wirtgen@gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: WVZ52ZSLRRUJYTNBUFIWX2OBML3RXVTD
X-Message-ID-Hash: WVZ52ZSLRRUJYTNBUFIWX2OBML3RXVTD
X-MailFrom: thomas.wirtgen@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: [Sidrops] Re: BGP over TLS/TCP - draft-wirtgen-bgp-tls-05 - draft update
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Eu5dMCUeNIedmyYTbMWAy4nCfaU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi Nick,

Regarding the status change, this was not unintentional error. The draft 
began as "Experimental" because we had not finalized the design in the 
first revisions (e.g., implicit vs. explicit TLS, reuse of port 179, 
interaction with TCP-AO).

The experimental track allowed us to iterate, especially since the draft 
originated from academic research rather than a working group effort 
from the beginning. Now that the mechanism has stabilized over several 
iterations, moving to the Standards Track shows that it is intended for 
real operational deployment rather than experimentation.

It was a deliberate choice, partly to determine if there was community 
interest continuing this draft further before committing to the 
Standards Track.

We agree that the sentence regarding TCP-AO should come back. It is 
important to write explicitly that managing TCP-AO keys is operationally 
difficult. However, securing long-lived BGP sessions remains important, 
especially in multihop scenarios where the risk of injection/spoofing is 
higher. In the next revision, we will restore that sentence (or 
something similar) to make this trade-off explicit rather than leaving 
it implicit.

Thanks for the feedback.

Thomas (speaking for the co-authors)