IETF Logo Mail Archive

Re: [Idr] New BGP capability to advertise running daemon version

Robert Raszuk <robert@raszuk.net> Fri, 02 August 2019 15:19 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B97120422 for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 ymEHviiTqQ0L for <idr@ietfa.amsl.com>; Fri, 2 Aug 2019 08:19:46 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 3CBD912041E for <idr@ietf.org>; Fri, 2 Aug 2019 08:19:46 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id z4so74303311qtc.3 for <idr@ietf.org>; Fri, 02 Aug 2019 08:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eWns55Vd8S5wsefRf30QNmJ6KC6kjVbbny1nKebG/Ac=; b=X5w4xiDDyvb7G5N/90EbQ9lDvsCpTye9lATLoUO6jp1FwQ67qqJiQmtda0gE/2oyZR PDGDviEL9QImQaTzvM/Tf1jjGsUHQbLsY3xqpAmWhKWSs8Z2qm/vwnrgdkz2jdtrgcgH XPp02byLeW7H6O83Q6HK4HL4zJyVWhp7R/Vr9/Y8LJZoh2ariq4jBaAwiE90J8+mJJHe 8HQRxqCzHhFZOcJ0BN2fwDKUhn+SEA8BRnisKih/8fZRSbyN/e1k9NPPb/9Yu8I3DiPV FohLSsSsTvAzG3NUAdcGOcZlJjdWufagOhcRegA8MYoInVMaPCSiIdFR3Fyl0q8OD8Ly zWLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eWns55Vd8S5wsefRf30QNmJ6KC6kjVbbny1nKebG/Ac=; b=Hc8RDQIrXvqp/Ho+5wfHFVq8K3k8vXlb8U+EVsWjIz0zp1hz2sgApDJIu4CcaXNa2N CkxhaJZ9BraQ/u3Zj8tYrKPWP9XiaBwaFLiB7RVmFYumoyv4e4FRCQwGksSVFXXr2RL2 gTjvdtx+lqcriY+LN4tY6ORxXt1H7/lzepMotUoSRk8uYE9or17NizCG2OxVkEgM4Qfj ZFIcVL2NxdQ9SmtZln71ZIsUYHLlJhNmcUwVohxTyoc19VlWfsccaiO4cFcyW3Diy+/s HrVOmljlRgcsc+d8xSHd5nLLBDaoqdswBMYC3rmYmA5gSbumtnlwnTCAkM2aUJ2fF13W 879Q==
X-Gm-Message-State: APjAAAWq6kY+1eToKiwNtzc+5JJBRnOdj5PFuYWDIUfzqqEKBmPMk6Bw HeuXwf1ewI/FwxxElJXjTnDBMJ6shS8y0TgyPcNZvQ==
X-Google-Smtp-Source: APXvYqxD7c2cMjCWMrB+sTcMf7Ta1qxkzBQwBDc39tOdWMkLv5QSSDwiarjtszPgHy+OmSrRl+W27wwGqQvQFSBZfyc=
X-Received: by 2002:a0c:afbd:: with SMTP id s58mr98440642qvc.217.1564759185121; Fri, 02 Aug 2019 08:19:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAPF+HwV3EEUza3FyiXsd_oSkj80OwY-tE2DgFWnynq1FL2tLHg@mail.gmail.com> <015d56c13d01436890da2b8a7179fac9@turkcell.com.tr> <CAPF+HwV2Df6qcRD+GrE_JFv8W5Yh3OACKZrdv1Bw4PXQbjtDyQ@mail.gmail.com> <20190802150251.GA11217@pfrc.org> <CACWOCC_J6-wMWx7KL2dza5A77KFnoabMt7oAY-xhsGb8Vf3O5w@mail.gmail.com>
In-Reply-To: <CACWOCC_J6-wMWx7KL2dza5A77KFnoabMt7oAY-xhsGb8Vf3O5w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 02 Aug 2019 11:19:35 -0400
Message-ID: <CAOj+MMFL7FVciSx1NyCp9zCPXZeRtNn4J-O1vS8btg96ZbDRuA@mail.gmail.com>
To: Job Snijders <job@ntt.net>, Donatas Abraitis <donatas.abraitis@gmail.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006375d2058f23e3d5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/AJbD1qEf4YWA4KdR20iLKwaHvp4>
Subject: Re: [Idr] New BGP capability to advertise running daemon version
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2019 15:19:49 -0000

Hi,

Just to refresh memory there is an active WG document precisely describing
how to carry such information between BGP peers. It is called BGP
Operational Message

https://tools.ietf.org/html/draft-ietf-idr-operational-message-00

The ADVISE TLV there section 3.4.1 and 4 are proposed with the very same
intention as this discussion is targeting.

Due to no customer push vendors have not implemented it yet. So the draft
is just hanging waiting for implementations.

I think if there is some new interest please consider to review the linked
WG doc and possibly augment it with missing elements.

Use of BGP capabilities in current state of implementation of bgp dynamic
capabilities is really not the right messaging vehicle here.

Thx,
R.

On Fri, Aug 2, 2019 at 11:09 AM Job Snijders <job@ntt.net> wrote:

> Right now operators use the peer’s MAC address and certain TCP behaviorism
> (nmap -O) to attempt to conclude what the remote side might be in case of
> issues.
>
> I see value in having this on by default. Security through obscurity isn’t
> the best defense anyway. I’m assuming a degree of trust exists anyway, why
> else set up a BGP session in the first place?
>
> I think there are valid use cases, i think it is worthwhile exploring how
> to implement this concept.
>
> Kind regards,
>
> Job
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>

v2.23.0 | Report a Bug | By Email