Internet2 Network Security SIG

[Andrew Gallo <>]

To answer your questions succinctly:
1. This is valuable;
2. I can't suggest doing something differently;
3. What TCP traffic are you catching that is inappropriately sourced using I2 
prefixes?

I've struggled with the a similar issue in our small regional.  I looked at 
the traffic that was being asymetrically routed back through CAAREN.  I found 
a lot of ICMP traffic as you mentioned.  I did a little digging and it 
appears that at least some of this traffic is used for geolocation.  Here's a 
specific example:

-Network X is a customer of ours and has an ISP link addressed out of 
providers Y's space.

-Some organization is attempting to geolocate (or possibly some other 
monitoring activity) Network X and sends ICMP messages to the link addresses 
out of Provider Y's space.

-This organization might be using AWS, with some of those routes in the R&E 
table.

-Network X prefers R&E above commodity, so the response is sent to me (and I 
send it to I2), all addressed out of a network which isn't reachable through 
Internet2 or CAAREN.

If I instituted uRFP or even static filtering, this traffic would get 
dropped.  Would it break something?


We could ask our customers to provide us with ALL of their assigned 
addresses, both summary prefixes and provider assigned link addresses, but I 
have no hope that this list will be maintained.
We could put new customers into a log/monitor mode as you do, to try to 
generate a list of prefixes assigned to a customer, and then add those to the 
customers allowed prefix list


I'd like to hear ideas as well.

Thanks for bringing up the topic.



On 8/16/2017 2:54 PM, Karl Newell wrote:
> I’m looking for your thoughts and feedback on the following.  tl;dr – we’re 
> looking into border anti-spoofing of packets sourced from Internet2 IP 
> address space to further protect the Internet2 network.
>
> One project we’ve been working on at Internet2 is vulnerability management of 
> the network infrastructure, initially focusing on the Juniper MX960s.  While 
> running code that addresses known vulnerabilities is the first line of 
> defense, it’s not always feasible or, at least, not feasible to roll out 
> fixes immediately.  So, we’re working on methods to mitigate the associated 
> risks and one we’re experimenting with we call border anti-spoofing. The idea 
> is to discard packets using spoofed Internet2 IP address space as the source 
> IP.  “uRPF you say?”…a limited form; we’ll save the uRPF discussion for a 
> later date.  The relevant Juniper configs are below and the firewall filter 
> is applied to the interfaces we use to peer with connectors.  We first accept 
> traffic sourced from any point-to-point link and then log packets sourced 
> from Internet2 IP address space.  To actually enforce this border 
> anti-spoofing we would change the “next term” to “discard”.  Ideally, any 
> packets that get logged are spoofing the source IP with an Internet2 IP 
> address.  In reality, we saw lots of traffic, predominantly related to ICMP.  
> Most of this is a result of asymmetric routing and the peer having a better 
> path through another I2 interface when sending ICMP Time Exceeding packets 
> from a peering interface.  I’ve attached a Splunk report graphing what we see 
> in a 24-hour period.  We plan to allow the ICMP traffic and are wondering 
> what to do with the TCP traffic.  Based on port numbers and related IPs the 
> TCP traffic is related to scanning for vulnerable services.
>
> Questions I have for this group:
> -Is this a valid and useful method to protect the network?
> -Is there anything you would suggest we do differently?
> -What do we do with the TCP traffic?  We can continue to log and monitor or 
> we could start to discard the traffic.
> -Any other thoughts…
>
> Thanks in advance for any feedback,
> Karl
>
>
>
> filter connector-in {
>      term border-exceptions {
>          from {
>              source-prefix-list {
>                  border-localv4-subnets;
>              }
>          }
>          then {
>              count border-exceptions;
>              accept;
>          }
>      }
>      term border-discard {
>          from {
>              source-prefix-list {
>                  INTERNAL;
>              }
>          }
>          then {
>              count border-i2-discard;
>              log;
>              syslog;
>              next term;
>          }
>      }
>
>
> prefix-list border-localv4-subnets {
>      apply-path "interfaces <*> unit <*> family inet address <*>";
> }
>
>
>
>
>
> --
> Karl Newell
> Cyberinfrastructure Security Engineer
> Internet2
> 520-344-0459

--
________________________________
Andrew Gallo
The George Washington University

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature