"BCP38 applies only to egress filtering"
INCORRECT.
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 204.69.207.0/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
204.69.207.0/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 204.69.207.0/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
activity.
(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.
