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

"Smith, Donald" <Donald.Smith@CenturyLink.com> Wed, 29 March 2017 20:37 UTC

Return-Path: <Donald.Smith@CenturyLink.com>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A27F1298CC; Wed, 29 Mar 2017 13:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 EhpkyF12aua3; Wed, 29 Mar 2017 13:37:11 -0700 (PDT)
Received: from lxomp52w.centurylink.com (lxomp52w.centurylink.com [155.70.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C977212957C; Wed, 29 Mar 2017 13:37:10 -0700 (PDT)
Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by lxomp52w.centurylink.com (8.14.8/8.14.8) with ESMTP id v2TKb74J055715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Mar 2017 15:37:08 -0500
Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B7EAB1E0065; Wed, 29 Mar 2017 14:37:02 -0600 (MDT)
Received: from lxdnp32k.corp.intranet (unknown [151.119.92.134]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 957FC1E0049; Wed, 29 Mar 2017 14:37:02 -0600 (MDT)
Received: from lxdnp32k.corp.intranet (localhost [127.0.0.1]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2TKb2bk047101; Wed, 29 Mar 2017 14:37:02 -0600
Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by lxdnp32k.corp.intranet (8.14.8/8.14.8) with ESMTP id v2TKb2XV047097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Mar 2017 14:37:02 -0600
Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([151.119.128.29]) with mapi id 14.03.0339.000; Wed, 29 Mar 2017 14:37:01 -0600
From: "Smith, Donald" <Donald.Smith@CenturyLink.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "hugocanalli@gmail.com" <hugocanalli@gmail.com>, "dave@juniper.net" <dave@juniper.net>, "cpignata@cisco.com" <cpignata@cisco.com>, "rodunn@cisco.com" <rodunn@cisco.com>
CC: "opsec@ietf.org" <opsec@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: [OPSEC] [Errata Verified] RFC6192 (4851)
Thread-Index: AQHSqLlu3ULAhDNPBkO7ZD5wwL9Os6GsRiKp
Date: Wed, 29 Mar 2017 20:37:01 +0000
Message-ID: <68EFACB32CF4464298EA2779B058889D53BB78AD@PDDCWMBXEX503.ctl.intranet>
References: <20170329182147.BF8F8B80D6F@rfc-editor.org>
In-Reply-To: <20170329182147.BF8F8B80D6F@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [151.119.128.7]
Content-Type: multipart/alternative; boundary="_000_68EFACB32CF4464298EA2779B058889D53BB78ADPDDCWMBXEX503ct_"
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/daHFFjGMRrbUBDWEma-q3HuCl5M>
Subject: Re: [OPSEC] [Errata Verified] RFC6192 (4851)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2017 20:37:13 -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)
Donald.Smith@centurylink.com<mailto:Donald.Smith@centurylink.com>
________________________________
From: OPSEC [opsec-bounces@ietf.org] on behalf of RFC Errata System [rfc-editor@rfc-editor.org]
Sent: Wednesday, March 29, 2017 12:21 PM
To: hugocanalli@gmail.com; dave@juniper.net; cpignata@cisco.com; rodunn@cisco.com
Cc: opsec@ietf.org; iesg@ietf.org; rfc-editor@rfc-editor.org
Subject: [OPSEC] [Errata Verified] RFC6192 (4851)

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 <hugocanalli@gmail.com>
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

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
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.