NTAC Peering Working Group

["Garrett, Seth B" <>]

The loose-mode-discard feature is nice from the campus perspective for certain security scenarios, but I agree other than that there isn’t much value in using it.  We are using the RPF loose-mode-discard to be able to automatically source block offender IPs while still being able to support asymmetric routing.

 

Thanks,

 

Seth Garrett
Principal Network Engineer
Indiana University

 

From: [mailto:] On Behalf Of Michael Hare
Sent: Tuesday, November 7, 2017 9:42 AM
To: ; David Farmer <>
Cc: Karl Newell <>; Michael H Lambert <>;
Subject: RE: [Security-WG] I2 - Anti-Spoofing/uRPF discussion summary from Technology Exchange

 

AS3128, a Juniper shop, briefly (ok, for a year or more) used loose-rpf on ingress internet facing interfaces.  I did this so I could configure rpf-loose-mode-discard.  In reality we never enacted a good reason to have rpf-loose-mode-discard enabled (other than UTRS, we never got our own injector off the ground).  loose-rpf definitely causes packet loss during unplanned cold convergence and presumably (honestly, I didn't RTFM) feasible-paths has the same problem.  For some that may be a reasonable tradeoff, for us it wasn't.

 

When I was helping manage AS2381 we used to do outbound antispoof.  When AS2381 started the WRIPs project suddenly we were in a position that we were two steps removed from network connectors.  For example, a single homed direct AS2381 customer (most of AS2381's connectors at the time) needed to contact us to get network access for a new subnet.  We could build a process to update the outbound antispoof list.  Once there was a second state network between us and the customer (for example, a school inside of another state network).  Things fell apart because network access was broken.  Instead of making this procedure a burden on WRIPs customers we ended up removing the outbound antispoof ACL.  I would argue by extension that this is why I2 should tread very carefully with this exercise.  If the exercise proves a certain connector or peer is often breaking the rule, will there be enforcement?  As custodian of a 1M+ rrd archive, I understand stats for stats sake, but uRPF is a performance hit in PPS throughput and given this is probably best not used on backbone interfaces.

 

-Michael

 

From: [] On Behalf Of John Hernandez
Sent: Monday, November 06, 2017 4:22 PM
To: David Farmer <>
Cc: Karl Newell <>; Michael H Lambert <>; ;
Subject: Re: [Security-WG] I2 - Anti-Spoofing/uRPF discussion summary from Technology Exchange

 

Hi folks.  FRGP recently implemented BCP38 for participant interfaces by leveraging the Juniper "feasible-paths" uRPF mode.  We began by doing exactly what has been proposed by Grover et al; we configured the uRPF fail filter to accept traffic and syslog.  Pete Siemsen <> wrote some perl code to crunch the RPF logs and generate an HTML tree, indexed by router and interface.

 

When we eventually whittled down the logs to traffic our participants agreed we should drop, we flipped their interfaces from logging mode to enforcement mode.  As you might expect this was more difficult for some participants than others, and in fact, we're still a few interfaces short of our goal.  We're happy to share Pete's code and lessons learned / pitfalls with anyone who might be interested.  Just drop me and Pete an email.

 

 

 

 

On Mon, Nov 6, 2017 at 10:25 AM, David Farmer <> wrote:

I agree BCP38/uRPF is probably best focused on connectors. However, I'm not sure the goal is to get all connecters to do BCP38/uRPF, at least yet. I believe the current goal is to better understand the need, the efficacy, and issues of deploying BCP38/uRPF in our community.  Blindly deploying BCP38/uRPF doesn't answer those questions. 

 

As for RPKI;

 

In our community RPKI is just as much a campus issue, as most campuses are the BGP route origin. Exclusively focusing on connectors for RPKI won't work. Connectors could be the focus for RPKI route validation, but without ROAs from campuses, RPKI route validation won't have much effect as there won't me much to validate.  This is a classic chicken or the egg problem.  we need to incrementally make progress on both sides.  Without regionals validating there isn't a good reason for campuses to create ROA. And, without ROAs from campuses there isn't a good reason for regionals to validate.  

 

Thanks.

 

On Mon, Nov 6, 2017 at 10:41 AM, Karl Newell <> wrote:

Good points David and Michael.  They remind me of part of the discussion we had during the WG meeting at TechEx.  While most agreed with efforts on this front, they also felt that the connectors are the best place for implementation.  So how do we foster that?  What can Internet2 do to help?  Getting back to Grover’s suggestion to turn on uRPF and log, we can use that data to inform the community.  There was also discussion of something like the I2 Innovation Platform but for security; connectors that commit agree to BCP38/uRPF, RPKI, and there was mention of a third item but I don’t recall what it was.  Would people support this effort and sign on?

Karl

--
Karl Newell
Cyberinfrastructure Security Engineer
Internet2
520-344-0459

On 11/6/17, 9:17 AM, " on behalf of Michael H Lambert" < on behalf of > wrote:

    > On 6 Nov 2017, at 10:54, David Farmer <> wrote:
    >
    > 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.

    I think the primary targets/victims/beneficiaries of this process should be the connectors.  To me, it makes much more sense for them to be filtering their members on ingress, especially since BCP38 does tend to crop up in various NSF solicitations.  If Internet2 does the filtering, it can hide these downstream issues.  It is appropriate for Internet2 to identify "offending" traffic, but once it has been identified, the connector should be encouraged/cajoled/shamed to fix the problem.

    International peers are another matter.  One would hope that they would have similar policies.

    Michael

 

--

===============================================
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
===============================================

 

--

John Hernandez, Network Engineer
1850 Table Mesa Drive, Boulder, CO 80305
Tel. 303-497-1280  Fax. 303-497-1818