Subject: RFC 4274 (BGP Protocol Analysis) errata

From: Alfred Hönes <[email-masked]>
Date: Sat, 8 Jul 2006 16:10:01 +0200 (MESZ)

Hello,
in January, the new BGP-4 RFCs have been published.
Unfortunately, I did not find the time to report the
textual issues I found in these documents until now.

This message addresses RFC 4274 (BGP-4 Protocol Analysis)
authored by you, pointing out some issues I found with the
RFC text, and supplying material for an appropriate
RFC Errata Note.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  typo (missing word)

The second paragraph of Section 2.2, on page 4 of RFC 4274, says:

   BGP uses an incremental update strategy to conserve bandwidth and
|  processing power.  That is, after initial exchange of complete
   routing information, a pair of BGP routers exchanges only the changes
   to that information.  [...]

It should say:

   BGP uses an incremental update strategy to conserve bandwidth and
|  processing power.  That is, after the initial exchange of complete
   routing information, a pair of BGP routers exchanges only the changes
   to that information.  [...]

(2)  typo

Section 2.3 contains (on page 5) the state description:

   ACTIVE:         State in which BGP peer is trying to acquire a peer
|                  by listening and accepting TCP connection.

It should say:

   ACTIVE:         State in which BGP peer is trying to acquire a peer
|                  by listening and accepting a TCP connection.
                                             ^^^

(An alternative correction, replacing 'connection' by 'connections',
 does not precisely reflect the desired behaviour.)

(3)  typos (multiple missing articles)

Section 4 of RFC 4274, on page 6, says:

   Whenever a BGP speaker detects an error in a peer connection, it
   shuts down the peer and changes its FSM state to IDLE.  BGP speaker
   requires a Start event to re-initiate an idle peer connection.  If
   the error remains persistent and BGP speaker generates a Start event
   automatically, then it may result in persistent peer flapping.
   Although peer oscillation is found to be wide-spread in BGP
   implementations, methods for preventing persistent peer oscillations
   are outside the scope of base BGP specification.

It should say:

   Whenever a BGP speaker detects an error in a peer connection, it
|  shuts down the peer and changes its FSM state to IDLE.  A BGP speaker
   requires a Start event to re-initiate an idle peer connection.  If
|  the error remains persistent and the BGP speaker generates a Start
   event automatically, then it may result in persistent peer flapping.
   Although peer oscillation is found to be wide-spread in BGP
   implementations, methods for preventing persistent peer oscillations
|  are outside the scope of the base BGP specification.

(4)  inconsistency in updated text

The text of section 6.1 has been revised substantially from its
predecessor, RFC 1774.  Unfortunately, the modifications have
not been performed incompletely, leading to near-nonsense text.
Section 6.1, on page 7, says:

   Immediately after the initial BGP connection setup, BGP peers
   exchange complete sets of routing information.  If we denote the
   total number of routes in the Internet as N, the total path
   attributes (for all N routes) received from a peer as A, and assume
   that the networks are uniformly distributed among the autonomous
   systems, then the worst-case amount of bandwidth consumed during the
|  initial exchange between a pair of BGP speakers (P) is

|          BW = O((N + A) * P)
                         ^^^^                     ^^^^^

This makes no sense -- obviously you can't multiply by a non-numeric
quantity P, "a pair of BGP speakers".

I strongly suspect that it was the intention to say:

   Immediately after the initial BGP connection setup, BGP peers
   exchange complete sets of routing information.  If we denote the
   total number of routes in the Internet as N, the total path
   attributes (for all N routes) received from a peer as A, and assume
   that the networks are uniformly distributed among the autonomous
   systems, then the worst-case amount of bandwidth consumed during the
|  initial exchange between a pair of BGP speakers is

|          BW = O((N + A))

Please verify.

(5)  like (4)

Section 6.1.2, on page 8, exhibits similar symptoms as noted above.
The RFC says:

   To quantify the worst-case memory requirements for BGP, we denote the
   total number of networks in the Internet as N, the mean AS distance
   of the Internet as M (distance at the level of an autonomous system,
   expressed in terms of the number of autonomous systems), the total
   number of unique AS paths as A.  Then the worst-case memory
   requirements (MR) can be expressed as

           MR = O(N + (M * A))

   Because a mean AS distance M is a slow moving function of the
   interconnectivity ("meshiness") of the Internet, for all practical
   purposes the worst-case router memory requirements are on the order
|  of the total number of networks in the Internet multiplied by the
|  number of peers that the local system is peering with.  [...]

Apparently, the first part of that text has been revised eliminating
the role of the peering count.  Thus the last sentence should have
been updated accordingly, to make it match the new formula.

The second paragraph thus perhaps should say:

   Because a mean AS distance M is a slow moving function of the
   interconnectivity ("meshiness") of the Internet, for all practical
   purposes the worst-case router memory requirements are on the order
|  of the total number of networks in the Internet.  [...]

The final paragraph on page 8,

   The following table illustrates typical memory requirements of a
   router running BGP.  We denote the average number of routes
   advertised by each peer as N, the total number of unique AS paths as
   A, the mean AS distance of the Internet as M (distance at the level
   of an autonomous system, expressed in terms of the number of
   autonomous systems), the number of octets required to store a network
   as R, and the number of bytes required to store one AS in an AS path
|  as P.  It is assumed that each network is encoded as four bytes, each
   AS is encoded as two bytes, and each networks is reachable via some
|  fraction of all the peers (# BGP peers/per net).  For purposes of the
|  estimates here, we will calculate MR = (((N * R) + (M * A) * P) * S).
                                                             ^^^^ ^^^^

and the table on page 9,
                                       vvvvvvvvvvvvvvvvvvv
|  # Networks  Mean AS Distance # ASes # BGP peers/per net   Memory Req
|      (N)             (M)        (A)          (P)              (MR)
   ----------  ---------------- ------ ------------------- -------------
     100,000           20         3,000         20           10,400,000
     100,000           20        15,000         20           20,000,000
     120,000           10        15,000        100           78,000,000
     140,000           15        20,000        100          116,000,000

exhibit additional issues:

- The text defines 'P' as
    "the number of bytes required to store one AS in an AS path"
  while apparently in the table (P) means
    "# BGP peers/per net".

- 'S' in the formula in the last line of page 9 is not defined
  anywhere in the text.

- "# BGP peers/per net" IMHO does not even make sense in the
  context of BGP, since BGP speakers represent ASes, not networks
  (prefixes).

I do not have a proposal for an easy way to get rid of these
inconsistencies.
Please check.

(6)  typos / grammar

In Section 10, the second paragraph on page 13 says:

|  BGP uses TCP MD5 option for validating data and protecting against
   spoofing of TCP segments exchanged between its sessions.  The usage
   of TCP MD5 option for BGP is described at length in [RFC2385].  The
   TCP MD5 Key management is discussed in [RFC3562].  BGP data
|  encryption is provided using the IPsec mechanism, which encrypts the
|  IP payload data (including TCP and BGP data).  The IPsec mechanism
|  can be used in both the transport mode and the tunnel mode.  The
|  IPsec mechanism is described in [RFC2406].  Both the TCP MD5 option
|  and the IPsec mechanism are not widely deployed security mechanisms
   for BGP in today's Internet.  Hence, it is difficult to gauge their
|  real performance impact when using with BGP.  However, because both
|  the mechanisms are TCP- and IP-based security mechanisms, the Link
   Bandwidth, CPU utilization and router memory consumed by BGP would be
|  the same as any other TCP- and IP-based protocols.

It should say, correcting grammar and unclear semantics:

|  BGP uses the TCP MD5 option for validating data and protecting
   against spoofing of TCP segments exchanged between its sessions.  The
   usage of TCP MD5 option for BGP is described at length in [RFC2385].
   The TCP MD5 Key management is discussed in [RFC3562].  BGP data
|  encryption is provided using the IPsec ESP mechanism, which encrypts
|  the IP payload data (including TCP and BGP data).  The IPsec ESP
|  mechanism can be used in both transport mode and tunnel mode.  The
|  IPsec ESP mechanism is described in [RFC2406].  Both the TCP MD5
|  option and IPsec ESP are not widely deployed security mechanisms
   for BGP in today's Internet.  Hence, it is difficult to gauge their
|  real performance impact when used with BGP.  However, because both
|  mechanisms are TCP- and IP-based security mechanisms, the Link
   Bandwidth, CPU utilization and router memory consumed by BGP would be
   the same as any for other TCP- and IP-based protocols.

(I am in doubt whether the last sentence is appropriate;
 at least, "the same as" should better be replaced by "similar as".
 Preferrably, I would delete that sentence.)

Finally, the 4th paragraph on page 13,
                                                      v
|  Such flexible TCP- and IP-based security mechanisms, allow BGP to
   prevent insertion/deletion/modification of BGP data, any snooping of
   the data, session stealing, etc.  [...]

should say:

|  Such flexible TCP- and IP-based security mechanisms allow BGP to
   prevent insertion/deletion/modification of BGP data, any snooping of
   the data, session stealing, etc.  [...]

(7)  some Ref's inappropriately named Normative

The References "[BGP-VULN]" and "[SBGP]" do not fulfill the
criteria for being used as Normative References.
Their inclusion in Section 11.1, on page 14, might formally be
seen as inhibiting the progress of BGP-4 on the Standards Track.

Please comment.

Most items seem to be appropriate for an Errata Note, but some
need your active cooperation to provide proper replacement text.

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent, and with
additional text supplied by you -- or just for the 'easy' issues.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+