NTAC Peering Working Group

[John Hernandez <>]

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