Subject: [SAVA] roadmap of anti-spoofing solutions

From: pekkas at netcore.fi (Pekka Savola)
Date: Tue Mar 20 05:23:13 2007

Hi,

Based on the meeting, it seemed that it wasn't really clear to 
everyone how the existing solutions fit together and where potential 
new work would be.   Below is my attempt at a 'roadmap' of the 
solutions I've seen:

1) host level ('inside subnet spoofing'): tools such as DHCP snooping
    and filtering, IP/MAC/port locking etc. already exist and are
    deployed to some degree.  Fred Baker's 'simpler SAVA' proposals fits
    here as well.  IMHO, no IETF work is urgently needed here.

2) subnet level ('last hop ingress filtering'): the routers of a link
    check that the packets were sourced from a prefix assigned to that
    link.  Strict uRPF and manual access lists work here in almost all
    cases.

   - Potential work item: multihomed host with multiple PA addresses.
     IMHO, multihoming hosts must just learn to pick the right
     addresses, period.  Trying to support multihoming hosts at this
     level is a recipe for disaster because every ingress filtering
     level higher up (provider-customer, intra, inter-AS, etc.) would
     need to know of these special cases as well.

3) provider-customer level (between an end-user network and ISP).
    Strict uRPF, Feasible Paths strict uRPF and manual ACLs work here.
    Feasible paths (whether done manually by adjusting incoming route
    preferences or automatically by the implementation) also works when
    the customer network is multihomed or the traffic is asymmetric.

   - Potential work item: those multihomed edge networks which don't
     use prefixes of their own, but rather parts of PA aggregates from
     each provider.  Typically no routing protocol is involved.
     (Personally I believe these may exist mostly in SOHO or small
     enterprise market, probably in coming years also with home
     networks.)

     IMHO, I don't believe this should be solved in the ingress
     filtering, but rather the network and the hosts need to pick the
     right source addresses for the same reasons as for multihomed
     hosts (above).  This is a trickier problem to solve, though.

4) intra-AS level: while some forms of ingress filtering could be
    applied within the network fully controlled by yourself, this is
    likely not something the ISPs are interested in doing as there is
    little benefit and lots of danger e.g., due to routing topology
    changes etc..  At most, if a PE router that aggregates customers
    has single uplink, filtering might be applied there as well (e.g.,
    if the PE device can't filter as effectively as a router upstream).
    No solutions needed here.

5) inter-ISP level.  Now we get into bigger difficultties:

  a) customers which are ISPs (applies to transit ISPs
     only).  Depending on the size and topological complexity of the
     customer-ISPs, it may be difficult to apply filtering.  Static
     filters are possible in many cases (e.g., IRR-generated), and if
     the customer's ISP is "well-behaved" (BGP advertisements are
     'consistent' -- advertise the same prefixes as from other Internet
     connection points even if with different preferences), feasible
     paths strict uRPF can be applied here as well.

   - Potential work item: I'm not quite sure what could be done here..

  b) ISP-ISP single-hop peering.  Typically applying ingress filtering
     has proved difficult in this space.  [However, as one data point,
     we have enabled feasible paths strict uRPF on one such peering and
     only experienced less than 0.5% of traffic getting dropped out of
     ~500 Mbit/s].  However, you could make the 'trust agreement'
     directly with your peer that both will filter; no protocol is
     necessary in cases a dedicated peering infrastructure is used.

   - Potential work item: if the peering is done over an ethernet IX
     where everyone shares the same fabric, other parties in the fabric
     could still spoof addresses.  If you can get every member in the
     fabric in the trust alliance (should be doable if there is a
     regulatory requirement), no solutions are necessary.

  c) ISP-ISP trust federation across the Internet.  You want to assign
     preferences etc. also to traffic received from trust alliance
     members across the non-conforming internet, i.e., there are
     networks in the middle who are not in agreement with you, or those
     middle-parties are providing transit from networks they can't
     ingress-filter.

   - Potential work item: an inter-ISP non-adjacent networks
     marking/verification mechanism that was discussed at the BOF.
     (Personally I doubt if this is worth it, given that doing so would
     likely require that everyone who participates must upgrade all
     their Inter-ISP facing border routers to support new hardware..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings