Internet2 Network Security SIG

["Garrett, Seth B" <>]

Indiana University is a MANRS participant.  Below is how we are aligned to the MANRS principles from a campus perspective.  I'd be happy to share our experience in these areas with others who are interested.  RPF is something we've been able to utilize to enhance our security responses (RTBH) as well.

 

Filtering:

• BGP import & export policies clearly defined. 
  
• Export policies are scoped to only subnets managed by IU Campus Networks (AS87 & AS27198).
  
• New peering requests will involve a check to verify routes being announced to us are legitimately held by the ASN.  This is also a point we can help encourage others to update their information and join the MANRS initiative.
  

 

Anti-Spoofing:

• RPF strict mode as a standard on all server and user interfaces.
  
• RPF loose mode on external paths.  We're utilizing the full routing table and compliment our RTBH solution with RPF loose mode.
  
• External eBGP interfaces have inbound/outbound filters on them that drop spoofed traffic in both directions.
  
• MANRS representatives will check the CAIDA spoofer project statistics for data on your ASN.  
  

 

Coordination:

• Updated contact information listed for AS87 & AS27198 (ARIN, PeeringDB, & RADb)
  
• 24x7 NOC
  

 

Global Validation:

• IU participates in RPKI route signing for AS87 & AS27198 for both IPv4 and IPv6.
  
• We're using the RIPE RPKI validator cache service connected to our Juniper routers.
  
• AS87 & AS27198 routes are kept updated in ARIN with the proper origin information.
  

 

Challenges:

• Deploying RPF can be challenging in a large, dual-homed environment.
  
  • ​DHCP considerations need to be made (both request and server responses).
    
  • Be prepared to troubleshoot unexpected traffic patterns or legitimate spoofing.
    
  • Try to use RPF strict mode when possible.
    
• You need to account for your DDoS scrubbing service when planning for RPKI.
  
  • ​Its strongly encouraged to not use the maxlength option for a prefix.  However, you need to account for smaller prefixes and/or different ASNs the routes could be coming from when using a scrubbing service.  This can lead to rather large ROAs.  Andrew Gallo I know has been doing some testing in this area.
    
  • RPKI is done at the org level within ARIN.  For reassigned space, you'll need the parent org to create the ROA.
    

Seth Garrett
Principal Network Engineer
Indiana University

---

From: <> on behalf of Brock, Anthony W <>
Sent: Tuesday, August 14, 2018 11:23 AM
To: ''
Subject: [Security-WG] Internet2, MANRS and embedded security

 

Colleagues,

As most of your are aware, Internet2 has been working with several of their partners (GÉANT, Jisc, etc) to identify how to best integrate security into their present and future efforts. One of the deliverables from this group (the REN Routing Security group) is the implementation of MANRS https://www.manrs.org/ in their respective environments. Internet2 plans to have MANRS implemented by the end of 2018 and several others (Geant, ESnet, KANREN, etc.) have either already implemented or are in the process of implementing it.

Has your organization implemented MANRS or are you planning to? If not, what are your obstacles to implementation (money, time, priorities, etc)? If yes, what helped to move this forward within your organization?

Also, Internet2 is including “embedded security” as part of the plan for the next generation of their network. It turns out that “embedded security” has not yet been defined within the context of their environment! So…

How would your define “embedded security” for Internet2? What would it look like? Would it be increased security intelligence, analysis, operational activities, etc? How could this be defined to help you and your organization in both your day-to-day activities as well as in your long-term security interests? Finally, would this be a topic of interest for calls with the Security WG, within the overall NTAC, or maybe even at the coming TechX conference?

Tony