BCP38 -- disabusing misinformation in this discussion
list at satchell.net
Tue Sep 27 13:14:29 UTC 2016
"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 184.108.40.206/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
> 220.127.116.11/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 18.104.22.168/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
More information about the NANOG