[Idr] Question about the magic bits resulting in 179

John Kristoff <jtk@depaul.edu> Mon, 06 April 2020 20:18 UTC

Return-Path: <jtk@depaul.edu>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 390993A0F0D for <idr@ietfa.amsl.com>; Mon, 6 Apr 2020 13:18:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id djaeH7nZWYFC for <idr@ietfa.amsl.com>; Mon, 6 Apr 2020 13:18:04 -0700 (PDT)
Received: from aharp.iorc.depaul.edu (aharp.iorc.depaul.edu []) by ietfa.amsl.com (Postfix) with ESMTP id 0EC6D3A0F0A for <idr@ietf.org>; Mon, 6 Apr 2020 13:18:03 -0700 (PDT)
Received: from p50.localdomain (localhost []) by aharp.iorc.depaul.edu (Postfix) with ESMTP id 755E8261B for <idr@ietf.org>; Mon, 6 Apr 2020 20:18:02 +0000 (UTC)
Date: Mon, 6 Apr 2020 15:18:01 -0500
From: John Kristoff <jtk@depaul.edu>
To: idr@ietf.org
Message-ID: <20200406151801.55d2550c@p50.localdomain>
X-Trump: Sucks
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0f4AtPOx7VlJyfVkzDcIgFG2pQ8>
Subject: [Idr] Question about the magic bits resulting in 179
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: Mon, 06 Apr 2020 20:18:09 -0000


In many software BGP implementations (e.g. BIRD, FRR, GoBGP) the BGP
listening process and remote peer may be specified with a port other
than 179. However, in hardware-based routers such as Cisco and Juniper,
when I went to use a non-standard port on one of them, I noticed no
such knob to change the default port.  It had never really occurred to
me this was a big deal before, but now it seems sort of unusual given
that practically all Internet services these days permit non-default
port usage.  Note, it really is not important why I or anyone would
want to do this, it really is beside the point.

When I asked some other operators about this I got a lot of push back
such as questioning the motive, suggesting this is nonsensical, and
that is would not be BGP.

The last idea I'd like to pose as a question to this group and use the
resulting consensus as something that might be reference material for my
operator friends that I think are essentially wrong.  :-)

From my reading of IETF RFC 4271 - A Border Gateway Protocol 4 (BGP-4),
179 support is clearly required for an implementation following the
specification. From section 8.2.1:

  A BGP implementation MUST connect to and listen on TCP port 179 for
  incoming connections in addition to trying to connect to peers. 

However, the requirement that an operator must use port 179 seems less
strict and as far as I can tell is ultimately a local decision if an
implementation support changing it. In the Administrative Events
sections there is this (sorry for extensive quoting, but context is

      Event 14: TcpConnection_Valid

         Definition: Event indicating the local system reception of a
                     TCP connection request with a valid source IP
                     address, TCP port, destination IP address, and TCP
                     Port.  The definition of invalid source and invalid
                     destination IP address is determined by the

                     BGP's destination port SHOULD be port 179, as
                     defined by IANA.

                     TCP connection request is denoted by the local
                     system receiving a TCP SYN.

Furthermore, from an unfinished draft-ietf-idr-bgp-issues-06
summarizing discussion when the RFC was being finished I found this
that drew consensus:

   Sue replied that this is local policy and is implementation
   dependent.  Siva agreed regarding the source port & IP address, but
   disagreed about the destination port.  He argued that we need to know
   the destination port for interoperability.

   Sue asked Siva to provide some text.

   After a long lull, Sue replied with:

   I would like to keep the current text of "Should" in the following
   text "BGP's destination port SHOULD be port 179 as defined by IANA."

   Should indicates that it normally should be 179.  If an
   implementation allows for an alternative TCP port, it is still valid
   as the "MUST" is not indicated.

That seems to clearly allow for an implementation or operator to use
a port other than 179 if they choose to, and there is nothing that would
constitute this as somehow invalid BGP or particularly wrong, if not
uncommon or unusual. Fair assessment?

Thank you for any feedback,