Subject: [OPSEC] [Errata Verified] RFC6192 (4851)

From: RFC Errata System <[email-masked]>
Date: Wed, 29 Mar 2017 11:21:47 -0700 (PDT)

The following errata report has been verified for RFC6192,
"Protecting the Router Control Plane". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6192&eid=4851

--------------------------------------
Status: Verified
Type: Technical

Reported by: Hugo Leonardo Canalli <[email-masked]>
Date Reported: 2016-11-01
Verified by: joel jaeggli (IESG)

Section: A.2

Original Text
-------------
   term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       port bgp;
                   }
                   then accept;
               }

Corrected Text
--------------
   term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       tcp-established;
                       source-port bgp;
                   }
                   then accept;
               }

Notes
-----
There is a security question in that firewall relating to bgp reply.
Any neighbor that fakes a tcp source port to 179 can access any router port, for example, ssh.
Need to add the line tcp-established. Would also be better to add source-port bgp since bgp protocol uses the 179 port to destination. Add the fix to all bgps, including ipv6.

--------------------------------------
RFC6192 (draft-ietf-opsec-protect-control-plane-06)
--------------------------------------
Title               : Protecting the Router Control Plane
Publication Date    : March 2011
Author(s)           : D. Dugal, C. Pignataro, R. Dunn
Category            : INFORMATIONAL
Source              : Operational Security Capabilities for IP Network Infrastructure
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG

---

From: "Smith, Donald" <[email-masked]>
Date: Wed, 29 Mar 2017 20:37:01 +0000

I think the established will block fins, and resets unless they happen to have the ACK bit set too.

It will block syn only packets too but since this is for ebgp-reply that should be ok.

if (initial_ttl!=255) then (rfc5082_compliant==0)
[email-masked]<mailto:[email-masked]>
________________________________
From: OPSEC [[email-masked]] on behalf of RFC Errata System [[email-masked]]
Sent: Wednesday, March 29, 2017 12:21 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [OPSEC] [Errata Verified] RFC6192 (4851)

Section: A.2

Original Text
-------------
   term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       port bgp;
                   }
                   then accept;
               }

Corrected Text
--------------
   term ebgp-reply {
                   from {
                       source-prefix-list {
                           EBGP-NEIGHBORS;
                       }
                       protocol tcp;
                       tcp-established;
                       source-port bgp;
                   }
                   then accept;
               }

Notes
-----

_______________________________________________
OPSEC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsec

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Dave Dugal <[email-masked]>
Date: Fri, 31 Mar 2017 12:58:53 -0400

I agree with Don's concern.  The original intent was to keep all TCP
segments away from port 179 unless the source address is that of a known
BGP peer (3.1. Legitimate Traffic).  The examples listed in the
appendices were meant to provide generalized "do no harm" starting
points.  Additional customization and finer granularity is completely
acceptable as an exercise left to the implementer, as long as the Design
Trade-Offs (3.3) are well understood.

I'm also unsure how s/port/source-port/ in this 'accept' clause on an
input filter helps to defend against a source port 179 SSH intrusion.
The intent of using 'port' was to accept EBGP replies whether the local
router initiated the session (src:179, dst:ephemeral) or the peer
initiated the session (src:ephemeral, dst:179).

---
Dave Dugal
Juniper Networks
PGP Key: 0x879F65CDAB6E02A5

On 3/29/2017 4:37 PM, Smith, Donald wrote:
> [email-masked] <mailto:[email-masked]>
>
> ------------------------------------------------------------------------
>
> *From:* OPSEC [[email-masked]] on behalf of RFC Errata System
> [[email-masked]]
> *Sent:* Wednesday, March 29, 2017 12:21 PM
> *To:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked]
> *Subject:* [OPSEC] [Errata Verified] RFC6192 (4851)
> 
> Need to add the line tcp-established. Would also be better to add
> source-port bgp since bgp protocol uses the 179 port to destination. Add
> the fix to all bgps, including ipv6.
> 
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the
> sender by reply e-mail and destroy all copies of the communication and
> any attachments.
>