BCP38 -- disabusing misinformation in this discussion

Tue Sep 27 13:14:29 UTC 2016

"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.