Very little, why it should be blocked. 

 

Dennis Burgess, CTO, Link Technologies, Inc.

den...@linktechs.net <mailto:den...@linktechs.net>  – 314-735-0270 – 
www.linktechs.net <http://www.linktechs.net> 

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of That One Guy
Sent: Monday, January 12, 2015 1:06 PM
To: af@afmug.com
Subject: Re: [AFMUG] BCP38

 

Im just curious what the few circumstances would be where you would allow this 
type of traffic, I could see if you had a security company doing malicious 
testing or something to that effect, but what other purpose could there be?

 

On Mon, Jan 12, 2015 at 12:33 PM, Eric Markow <e...@belairinternet.com> wrote:

I believe the phrase is “all your internets are belong to us”

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Chuck McCown


Sent: Monday, January 12, 2015 10:25 AM
To: af@afmug.com
Subject: Re: [AFMUG] BCP38

 

Remember when back in the early days, folks could announce “all your internets 
are mine” and take down everything.

 

From: Ken Hohhof <mailto:af...@kwisp.com>  

Sent: Monday, January 12, 2015 11:07 AM

To: af@afmug.com 

Subject: Re: [AFMUG] BCP38

 

Depends on what you mean by “any prefixes learned by the bgp peers”.

 

I think most upstreams would manually configure route filters to control what 
BGP advertisements to accept, and maybe also an ACL based on source IP.  
Otherwise there’s too much risk a customer would advertise routes for non owned 
blocks or bogons to you, either maliciously or by mistake, and you would 
automatically install these routes and pass them on.  Boom, you’re trying to 
advertise 8.0.0.0/0 or 10.0.0.0/0 and also allowing source address spoofing 
from those IPs, because your customer did something stupid.

 

Without an LOA and manual configuration, just advertising a route via BGP to 
another ASN should not cause those routes to be accepted.  Of course your 
upstream probably has these same rules, so your customer would have to give you 
an LOA that also goes to your upstream authorizing them to advertise those 
blocks.

 

 

From: Dennis Burgess <mailto:dmburg...@linktechs.net>  

Sent: Monday, January 12, 2015 11:46 AM

To: af@afmug.com 

Subject: Re: [AFMUG] BCP38

 

Basically ,any IPs that SHOULD be sourced from your network.  But yes, the idea 
behind BCP38 is to block src address packets originating from your network that 
SHOULD NOT.  So yes, you should already have those rules to not all traffic 
from your network if it’s coming from a IP that should not come from your 
network, and yes that would include any customer originated traffic.  

 

An example, customer has 4 /19s and two /22s, plus has about 30 BGP peers for 
customer traffic.

 

The 5 prefixes would be allowed out, plus any prefixes learned by the bgp 
peers.  If there were two upstream on the same router, both would have a line, 
if the SRC address is ! (not) customer prefixes, including the 5 prefixes they 
use, then it would be dropped on egress of the upstream ports.   An example of 
this is

 

add action=drop chain=forward out-interface=ether17-internet 
src-address-list=!Inside-IPs

 

The inside_ips list include the local prefixes and the customer prefixes.  

 

Dennis Burgess, CTO, Link Technologies, Inc.

den...@linktechs.net – 314-735-0270 – www.linktechs.net

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Ken Hohhof
Sent: Monday, January 12, 2015 10:55 AM
To: af@afmug.com
Subject: Re: [AFMUG] BCP38

 

Yeah, I’m missing what the big deal is here.  If you’re talking about your 
border router to your upstream, why would you allow outbound traffic with 
source IPs outside your IP blocks?  Allow your IPs, block the rest.

 

If you’re talking about other routers within your network and are wanting to 
stop the traffic at the source, it could get more complicated since I assume we 
all use some private IP space within our networks for various purposes mostly 
management addresses on network equipment.

 

Dennis mentions customer IPs, if you route customer blocks those would also be 
allowed, based on an LOA.

 

 

From: Dennis Burgess <mailto:dmburg...@linktechs.net>  

Sent: Monday, January 12, 2015 10:43 AM

To: af@afmug.com 

Subject: Re: [AFMUG] BCP38

 

Very simple.  In MT we do an address list of all valid subnets behind the core 
routers, this would include any prefixes that you own or use, plus any BGP 
prefixes learned from your customers.  Then a simple, out interface (internet) 
drop if its not SRCed from that list.  Not exactly IP tables, but there ya go..

 

 

 

Dennis Burgess, CTO, Link Technologies, Inc.

den...@linktechs.net – 314-735-0270 – www.linktechs.net

 

From: Af [mailto:af-boun...@afmug.com] On Behalf Of Sean Heskett
Sent: Monday, January 12, 2015 10:25 AM
To: af@afmug.com
Subject: Re: [AFMUG] BCP38

 

Hey Mike,

 

Would you be willing to post an iptables statement that would drop this traffic?

 

Thanks,

Sean



On Monday, January 12, 2015, Mike Hammett <af...@ics-il.net> wrote:

http://www.bcp38.info/index.php/Main_Page

Make sure you implement this in your networks. Drop all outbound traffic to 
your upstream that is not from valid public IP space.



-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

 

________________________________

This e-mail and any attachments may contain confidential and privileged 
information. If you are not the intended recipient,please notify the sender 
immediately by return e-mail, delete this e-mail and destroy any copies. Any 
dissemination or use of this information by a person other than the intended 
recipient is unauthorized and may be illegal.

 

________________________________

This e-mail and any attachments may contain confidential and privileged 
information. If you are not the intended recipient,please notify the sender 
immediately by return e-mail, delete this e-mail and destroy any copies. Any 
dissemination or use of this information by a person other than the intended 
recipient is unauthorized and may be illegal.





 

-- 

All parts should go together without forcing. You must remember that the parts 
you are reassembling were disassembled by you. Therefore, if you can't get them 
together again, there must be a reason. By all means, do not use a hammer. -- 
IBM maintenance manual, 1925

Reply via email to