Internet2 Network Security SIG

[David Farmer <>]

While I support this work, I want to say the following;

At least at this time, I don't see this as an effort to enforce any particular traffic policy, it is only an effort to seek understanding about how and why traffic flows the way it does within the Internet2 network ecosystem.

By that, I mean if traffic a flow exists, and it is made to go way without a completely understating of why it existed in the first place, and why it was taking the path it did, this effort will be a failure. Further, if we succeed, or fail, in applying a traffic policy, but do not understand why we succeeded, or failed, this effort will also be a failure.

Note: I said "the Internet2 network ecosystem", this isn't just about the Internet2 (US) national R&E backbone, it is just as much about the campuses, the regional networks, the international partner networks, and our community wide commodity peering efforts, as it is about our national R&E backbone.

So a question, how do we communicate this going forward as we interact with more and more people? I'm worried some will just see this as an effort to apply a traffic security policy on the Internet2 backbone. 

Thanks.

On Mon, Nov 6, 2017 at 8:32 AM, gcbrowni <> wrote:

Good Morning folks! 

There was some discussion about Anti-Spoofing/uRPF in the Security Working Group meeting at the most recent Technology Exchange. Karl and I have tried to summarize the discussion, below. 

It sounded like a coordinated approach along with some steps in logging was thought to be a good path forward to explore the problem space. 

Let me know if you think anything is missing; I’m interesting in making sure we capture the thinking of the working groups.




====================
Past:
Internet2 has, traditionally, not implemented filters of any type on its edges. At several points in the past discussions have taken place with the membership on the value of implementing border anti-spoofing on the Internet2 routers. These discussions were largely centered on uRPF.

Two use cases have consistently arisen that have made anti-spoofing difficult. Both can be summarized as “Asymmetry is not unusual.” First, some members back up other members traffic, providing Internet2 resiliency through their neighbors infrastructure. Second, it is not uncommon for traffic to be transited for sources for which no route exists, such as an organization that’s not a member of Internet2 but their upstream is, along with its best routes. Internet2’s flexibility in these scenarios has been seen as valuable.

 
Present:
Both BCP38 & MANRS touch on anti-spoofing, however Internet2 does not block traffic on any edge interface. Filters are applied to all interfaces, however they exist to count traffic of various types and then ‘accept’ all packets. Internet2 does filter traffic destined to the routers (IE: loopback filters) in order to protect the infrastructure, proper.

Internet2 does apply route filters to BGP advertisements. Members must notify the Internet2 business office in advance of any prefixes they wish to advertise. Once approved, the appropriate BGP filters are modified to only accept those BGP prefixes from that member. These pre-approval filters are only applied to members and netplus connectors, not to peer network BGP sessions.  

Recently a trial filter was implemented on the Internet2 Ashburn router. The edge filter implements an anti-spoofing filter for internal Internet2 addresses. The goal is to reject inbound traffic using Internet2 source-IP’s that are sourced outside of Internet2.


Future:
Several new technology options are available. Joining Strict and Loose mode is now Feasible mode, allowing more flexibility in which routes can match incoming packets. Further, the Juniper “fail filter” feature allows for exceptions to the uRPF check.

A blended approach may meet with some success while still retaining the flexibility and responsiveness that the membership values in Internet2. Strict, Loose, Feasible, fail filters, and opt-out options combined with robust reporting to the connectors and a self-service portal could all be utilized based on the type of connector and their needs. Coordination with the regional connectors could leverage the impact.

A first step to explore the problem space could be implementation of uRPF on all Internet2 edge interfaces with a fail filter that simply Syslogs and Accepts all traffic. Even without packet blocking this could be, with robust reporting, both a valuable internal security tool as well as providing useful information to the membership on Internet’s view of their traffic.


Unicast RPF Overview:
https://en.wikipedia.org/wiki/Reverse_path_forwarding#Unicast_RPF_.28uRPF.29

--

===============================================
David Farmer              
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota  
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================