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

[Dave Dugal <[e-mail]>]

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:
> 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)
> [e-mail] <mailto:[e-mail]>
>
> ------------------------------------------------------------------------
>
> *From:* OPSEC [[e-mail]] on behalf of RFC Errata System
> [[e-mail]]
> *Sent:* Wednesday, March 29, 2017 12:21 PM
> *To:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *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 <[e-mail]>
> 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
> [e-mail]
> 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.
>