Internet2 Network Security SIG

[Karl Newell <>]

Thanks Andrew.  To address your question about TCP traffic, I don’t think 
anything is being spoofed, I think it’s the same asymmetric routing as the 
ICMP traffic.  e.g., a host in China is scanning the internet on port 22, 
that scan hits the peer side of our point-to-point link, the peer has a 
filter to reject the packet (which sends a reset) and the best path to the 
scanning host is via another peering interface.  For spoofed traffic, we’re 
expecting to see source and destination IPs within the Internet2 address 
space; i.e., people trying to disrupt control plane traffic by bypassing our 
RE filters with a spoofed source that is permitted through the filter.

Your example is one of the reasons we don’t implement uRPF.  We also transit 
traffic for sources that we don’t have a route for (e.g., an organization is 
not a member of I2 but their upstream is a connector and the best route to 
AWS is through us).  But is that the right thing to do?

Karl

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

On 8/16/17, 12:16 PM, "Andrew Gallo" 
<
 on behalf of 
>
 wrote:

    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