Skip to Content.
Sympa Menu

ntacpeering - I2 - Anti-Spoofing/uRPF discussion summary from Technology Exchange

Subject: NTAC Peering Working Group

List archive

I2 - Anti-Spoofing/uRPF discussion summary from Technology Exchange


Chronological Thread 
  • From: gcbrowni <>
  • To: ,
  • Subject: I2 - Anti-Spoofing/uRPF discussion summary from Technology Exchange
  • Date: Mon, 6 Nov 2017 09:32:44 -0500
  • Ironport-phdr: 9a23:lW+d/RWUdNCcuvfiBYlkTZ5BmDnV8LGtZVwlr6E/grcLSJyIuqrYbRSAt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXMTRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KptVRTmijoINyQh/W/XlsN/g79VrhGvqRJh2IPUb52ZNP9kc6/BYd8XR2xMVdtRWSxbBYO8apMCD+UdMulDtYn9oFUPrR2/BQKxA+7vxSNHiWTs3a093eUhFwDG0RcvH9IKt3Tbt8/6NKMUUeCy0KbE1zTDb+5M1Tjj9YfIbwksrPeRVrx+dsrRzFMgFwLDjliIp43lPjCV1uUVs2eF8uVgVPigh3QgqwFrrTiiwNonhIrRho8N1FzI6Tl1zJswKNGlS0N0f92pHZ5etyGUK4d6XsYvT39mtSs/z7ALuYO3cS4Xw5o93RHfceaIc42Q7xLjSumRJTB4iWpgeL2lhhay9VKsxfHgVsaoylpKoTBFkt/Ltn8RzRDT69WHRuFj8Ui8xDaDzwHT6udaLkAojafXNYItzqItmpcWrEjOHTH5lUbzga+YeEUo5vSk5uH5brjoo5KRMo95hhzmPqQrgMO/AOA4MgYUX2ic/OSxzLLj8lHiT7VQif03nK/ZsJHBKMQUoq65BBRa3Zwn6xa5CDepzM4UnXgaLF5fZh2IkpXpN0nUIP/kFfe/n0iskDBzyvDAIr3uGInCLmDdn7j/Z7Z96khcyAUowNBb5pJUEa0BIOntVkPrtdzYCAM5PBKuw+bhFtp9yp0SVXiRDaCELaPYqUWI6f43I+mQeI8Vvy7wK+M76PHykH85g14dfbWp3JcOZnG4Ee9rI0GYYXr3ntcBCnkGshA/TOzslF2NTyRTZ3CsUKIg+D03EpypApreRtPlvLvU2juyFYVba3pHDF+kEHH0ep+CVutWLi+eP4spiTEPSKKgV55kyh6GtQnmxqBhI/aOvCAUqMHNzt9wsuLYnws16jp1R5CS2GuXSH5yn0sHQzg81aR5pkc7y0rF3KRl1a8LXedP7u9EB19pfaXXyPZ3Xoj/

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.19.

Top of Page