Re: Request for comment -- BCP38

[Jason Iannone <jason.iannone () gmail com>]

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?

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.

Bcp38
> From my allocation accept, else deny

Urpf loose
> From route table exist accept, else deny

Urpf strict
> From next hop interface true accept, else deny

On Sep 27, 2016 4:52 AM, "Florian Weimer" <fw () deneb enyo de> wrote:

> * Baldur Norddahl:
>
> > This means we can receive some packet on transit port A and then route
> out
> > > > a ICMP response on port B using the interface address from port A. But
> > > > transit B filters this ICMP packet because it has a source address
> > > > belonging to transit A.
> > > Interesting.  But this looks like a feature request for the router
> > > vendor, and not like an issue with BCP 38 filtering as such.
> >
> > Can you quote an RFC for anything that the router is doing wrong? Is
> > there a requirement that a router must support source routing?
>
> It's not an RFC conformance issue (several implementations of source
> address selection are possible).  But it appears to make it rather
> difficult to configure it in such a way it does what you need, and it
> looks like a reasonable enhancement request.
>
> > In our case we actually did contact the vendor. Turns out that it will
> > do source routing but not for packets from the control plane. There is
> > no way to resolve the issue with the current software available to
> > us. The vendor is not priotizing fixing this as I am also unable to
> > point to any RFC that is being violated.
>
> Source routing is not required to fix this.  Other options are using a
> globally routed IP address for the source address (this can also be
> used to conserve address space because the interface addresses will
> not matter anymore), or chosing the interface address based on the
> outgoing interface.