"BCP38 applies only to egress filtering"
The title of the update to BCP38/RFC2827, BCP84/RFC2074, exposes the balderdash on its face. That title? "Ingress Filtering for Multihomed Networks." Oops. This is a short snipping from the Introduction:
RFC 2827 recommends that ISPs police their customers' traffic by
dropping traffic entering their networks that is coming from a source
address not legitimately in use by the customer network.
ENTERING, not LEAVING. QED
(Although I can understand some of the confusion. Some people might IMPLEMENT BCP38 using egress filtering, relying on the infamous "as-if" rule. Indeed, in my implementation of BCP38, I implement it on both INPUT and OUTPUT, so that it traps nasty traffic generated within the four corners of the system on which the firewall runs. This works for servers, particularly servers with multiple virtual guests.)
Looking at RFC 2827 (I couldn't sleep, so here I am in the middle of the dark reading RFCs) Section 3, this paragraph appears:
In the example above, the attacker resides within 22.214.171.124/24,
which is provided Internet connectivity by ISP D. An input traffic
filter on the ingress (input) link of "router 2", which provides
connectivity to the attacker's network, restricts traffic to allow
only traffic originating from source addresses within the
126.96.36.199/24 prefix, and prohibits an attacker from using
"invalid" source addresses which reside outside of this prefix range.
In other words, the ingress filter on "router 2" above would check:
IF packet's source address from within 188.8.131.52/24
THEN forward as appropriate
IF packet's source address is anything else
THEN deny packet
Network administrators should log information on packets which are
dropped. This then provides a basis for monitoring any suspicious
(Note that "router 2" in the diagram is the router to which the attacker is talking, not a router on upstream ISPs A, B, C, and D. Although I guess router 2 could be owned by the ISP...)
So, if I'm reading the RFC correctly, my original assertion that BCP mandates routers block "the bad stuff" on output, but ALSO on input. In fact, I don't see any discussion of output filtering in the RFC -- show me where it does, please.
Now getting back to the discussion of uRPF (Unicast Reverse Path Forwarding), the RFC also talks about this:
... The method
suggested is to look up source addresses to see that the return path
to that address would flow out the same interface as the packet
arrived upon. With the number of asymmetric routes in the Internet,
this would clearly be problematic.
That description roughly corresponds with Cisco's definition of "strict". My question is whether my simplified example in a prior rock would correspond with Cisco's definition of "loose" -- you allow any source address in any downstream or local subnet the router knows about.
Just to show that I do read entire RFCs, here is this little nugget, from RFC 2827, Section 5:
If ingress filtering is used in an environment where DHCP or BOOTP is
used, the network administrator would be well advised to ensure that
packets with a source address of 0.0.0.0 and a destination of
255.255.255.255 are allowed to reach the relay agent in routers when
appropriate. The scope of directed broadcast replication should be
controlled, however, and not arbitrarily forwarded.
In the SOHO environment, the problem is moot because the DHCP is usually provided on the first router. (That's true in my home, and in businesses where I have installed networking.) In larger networks, or with ISPs that insist on doing DHCP upstream from a router, this is an issue.