Subject: [Idr] [Technical Errata Reported] RFC4724 (6217)

From: RFC Errata System <[email-masked]>
Date: Mon, 29 Jun 2020 12:30:05 -0700 (PDT)

The following errata report has been submitted for RFC4724,
"Graceful Restart Mechanism for BGP".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6217

--------------------------------------
Type: Technical
Reported by: Nir Chako <[email-masked]>

Section: 7

Original Text
-------------
Since with this proposal a new connection can cause an old one to be
terminated, it might seem to open the door to denial of service
attacks.  However, it is noted that unauthenticated BGP is already
known to be vulnerable to denials of service through attacks on the
TCP transport.  The TCP transport is commonly protected through use
of [BGP-AUTH].  Such authentication will equally protect against
denials of service through spurious new connections.

If an attacker is able to successfully open a TCP connection
impersonating a legitimate peer, the attacker's connection will
replace the legitimate one, potentially enabling the attacker to
advertise bogus routes.  We note, however, that the window for such a
route insertion attack is small since through normal operation of the
protocol the legitimate peer would open a new connection, in turn
causing the attacker's connection to be terminated.  Thus, this
attack devolves to a form of denial of service.

It is thus concluded that this proposal does not change the
underlying security model (and issues) of BGP-4.

We also note that implementations may allow use of graceful restart
to be controlled by configuration.  If graceful restart is not
enabled, naturally the underlying security model of BGP-4 is
unchanged.

Corrected Text
--------------
Since with this proposal a new connection can cause an old one to be
terminated, it might seem to open the door to denial of service
attacks.  However, it is noted that unauthenticated BGP is already
known to be vulnerable to denials of service through attacks on the
TCP transport.  The TCP transport is commonly protected through use
of [BGP-AUTH].  Such authentication will equally protect against
denials of service through spurious new connections.

If an attacker is able to successfully open a TCP connection
impersonating a legitimate peer, the attacker's connection will
replace the legitimate one, potentially enabling the attacker to
advertise bogus routes.  We note, however, that the window for such a
route insertion attack is small since through normal operation of the
protocol the legitimate peer would open a new connection, in turn
causing the attacker's connection to be terminated.  Thus, this
attack devolves to a form of denial of service.

However, it is possible to downgrade the session so it will be
devoided of capabilities via the NOTIFICATION message for OPEN
messages with an Unsupported Optional Parameter subcode.
RFC5492 specifies that if a peer receives this type of NOTIFICATION
message, it SHOULD try to re-establish the BGP connection without
capabilities and, among other things, reduce the use of Graceful
Restart Capability.
Therefore, in this situation, if the attacker is the first to
establish a BGP connection with the peer, he might secure his route
advertising position.
This time, the legitimate peer won't be able to open a new
connection and terminate the attacker's connection.
Thus, this attack devolves into a form of a man-in-the-middle attack.

It is thus concluded that this proposal does not change the
underlying security model (and issues) of BGP-4.

We also note that implementations may allow use of graceful restart
to be controlled by configuration.  If graceful restart is not
enabled, naturally the underlying security model of BGP-4 is
unchanged.

Notes
-----
The change in this section is the addition of a paragraph between paragraph 2 and paragraph 3 in the original section which describes an attack process where the attacker can gain a permanent grip on the connection

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4724 (draft-ietf-idr-restart-13)
--------------------------------------
Title               : Graceful Restart Mechanism for BGP
Publication Date    : January 2007
Author(s)           : S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter
Category            : PROPOSED STANDARD
Source              : Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: John Scudder <[email-masked]>
Date: Mon, 29 Jun 2020 19:52:11 +0000

Hi All,

I think the observation in the erratum is correct and is a valid use for the errata process — the specification has a “bug” in the quoted paragraph two, and it “could cause… deployment problems” (https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/) if someone relied on it.

I might prefer different wording; I can propose some changes if we agree to move the erratum forward.

Thanks, Nir, for reporting this.

—John

> On Jun 29, 2020, at 3:30 PM, RFC Errata System <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid6217__;!!NEt6yMaO-gk!QWGs4keJE8yBWL46Lt6HGxG6HLy9HzuG6duYUZDFu-wW70C2FYyqQZU2d0M6zg$
>

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 29 Jun 2020 13:22:32 -0700

On June 29, 2020 at 3:52:19 PM, John Scudder wrote:

[Taking the rfc-editor off while we talk about this.]

Hi!

> I think the observation in the erratum is correct and is a valid use for
> the errata process — the specification has a “bug” in the quoted paragraph
> two, and it “could cause… deployment problems”
> (https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/)
> if someone relied on it.

While I also think the information is correct/valuable, I don't think
that adding text is what was intended as a "bug".  In general, I think
of a bug as an error -- this report points at a possible omission,
something that could have been added...not something that was wrong.

The 3rd paragraph already covers general BGP security issues, which I
think include the issues introduced by rfc5492/rfc3392.

   It is thus concluded that this proposal does not change the underlying
   security model (and issues) of BGP-4.

Note that rfc5492/rfc3392 doesn't include this type of downgrade
attack in the Security Considerations.  :-(

Back to this report.  We can argue whether an omission is an error or
not...  Instead, I can mark this report as "Hold for Document Update"
so it is available when/if the RFC is updated.

Would that work for everyone?

Thanks!

Alvaro.

---

From: John Scudder <[email-masked]>
Date: Mon, 29 Jun 2020 20:25:41 +0000

Hi Alvaro,

Here’s the line I think is a straight-up error: "Thus, this attack devolves to a form of denial of service.” Nir has demonstrated that by adding a downgrade to the attack (which is trivial) it can be turned into a MiTM.

—John

> On Jun 29, 2020, at 4:22 PM, Alvaro Retana <[email-masked]> wrote:
> 
>> (https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/__;!!NEt6yMaO-gk!QsgA3iZjD5ll42V7sb2_P5jc65m8XO6AKfzQLnKEp8MVgDjLoLGbYYlHlOGvMA$ )
>> if someone relied on it.
>