Request for comment -- BCP38

Tue Sep 27 11:36:39 UTC 2016

* Jason Iannone:

> I have a question regarding language. We've seen bcp38 described as a
> forwarding filter, preventing unallocated sources from leaving the AS.  I
> understand that unicast reverse path forwarding checks support bcp38, but
> urpf is an input check with significant technical differences from output
> filters.
>
> Are urpf and bcp38 interchangeable terms in this discussion?  It seems
> impractical and operationally risky to implement two unique ways to dos
> customers.  What are the lessons learned by operators doing static output
> filters, strict urpf, or loose/feasible urpf?

Historically (in 1998, when RFC 2267 was released), BCP 38 was an
egress filter applied at the AS boundary.  A complainant would be able
to identify the AS by looking at the IP address and contact the
relevant ISP.  Within the AS, that ISP could identify the actual
packet source by other means.

Reverse-path forwarding checks were explicitly ruled out as likely
infeasible even in RFC 2267, except for links which are essentially
dialups.

Current terminology is more complicated.  Personally, I think that
mandating specific approaches such as BCP 38 or uRPF does not work.
The goal should be to cut down spoofed traffic.  Whether this is done
by contracts (which are adhered to, obviously), monitoring or
immediate technical enforcement in the routers, does not matter at all.

> For a new implementation, I assume the safe bet is to start with loose
> urpf.  Even if it stops only some traffic it at least gives the network to
> dip its toes and expose some customer brokenness.

If loose uRPF is effective at all depends a lot on network architecture.