Tier 2 ingress filtering

Jimmy Hess mysidia at gmail.com
Fri Mar 29 00:04:16 UTC 2013


On 3/28/13, Jay Ashworth <jra at baylink.com> wrote:

> My understanding has always been different from that, based on the idea
> that the carrier to which a customer connects is the only one with which
> that end-site has a business relationship, and therefore (frex), the only
> one whom that end-site could advise that they believe they have a valid
> reason to originate traffic from address space not otherwise known to
[snip]

Do you have a LOA on file for that peer/customer to route traffic to
(or from) the prefix?
If yes,  then it's legitimate that they source traffic from it,  or request
that the prefix be included in their filters for BGP and ingress controls.

If no, then consult the routing policy that applies to them.

Ingress source addresses should optimally ideally be filtered at
turnup  to the list of authorized prefixes,  if uRPF cannot be
implemented  (uRPF is convenient, but not necessarily necessary to
implement ingress filtering),  then access list based on source
address,  even the nearly oldest of the most ghetto equipment should
be offering basic ACL functions.

 If the downstream need extra prefixes that you couldn't have known
about, then it's the downstream network's  job to contact you to have
the prefix added to filters,  before they start sourcing traffic from
those addresses.

By definition if they wouldn't be allowed to route traffic _to_ that
address over your link, your network's routing policy documents could
and probably ought to say,  that it's not allowed to source traffic
from such unauthorized addresses.




If the peer is your transit provider  that is authorized to give you
default and route any prefix, then sure, allow any source,  because
they are authorized    (except source addresses that belong to your
network or your customers   that have not secured your network's
permission to be multihoming with their link and specified address
space, of course)..


> -- jra
--
-JH




More information about the NANOG mailing list