Re: BCP38 adoption "incentives"?

[Mike Hammett <nanog () ics-il net>]

They don't need to manage the router. The raw DSL modem, cable modem, etc. can watch the packets and see what's 
assigned. This would need new hardware, but it's not like this is happening quickly any other way. Yes, there are some 
consumer purchased DSL routers and cable routers, but doing what you can with what you can. 

FWIW, I believe most American ISPs *DO* manage their end-user routers. 




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

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message -----

From: "Andrew White" <Andrew.White2 () charter com> 
To: "Mike Hammett" <nanog () ics-il net> 
Cc: nanog () nanog org 
Sent: Tuesday, September 27, 2016 3:44:35 PM 
Subject: RE: BCP38 adoption "incentives"? 

Hi Mike, 

This assumes the ISP manages the customer's CPE or home router, which is often not the case. Adding such ACLs to the 
upstream device, operated by the ISP, is not always easy or feasible. 

It would make sense for most ISPs to have egress filtering at the edge (transit and peering points) to filter out 
packets that should not originate from the ISP's ASN, although this does not prevent spoofing between points in the 
ISP's network. 

Andrew 

NB: My personal opinion and not official communiqué of Charter. 


Andrew White 
Desk: 314.394-9594 | Cell: 314-452-4386 | Jabber 
andrew.white2 () charter com 
Systems Engineer III, DAS DNS group 
Charter Communications 
12405 Powerscourt Drive, St. Louis, MO 63131 



-----Original Message----- 
From: NANOG [mailto:nanog-bounces () nanog org] On Behalf Of Mike Hammett 
Sent: Tuesday, September 27, 2016 3:33 PM 
Cc: nanog () nanog org 
Subject: Re: BCP38 adoption "incentives"? 

It would be incredibly low impact to have the residential CPE block any source address not assigned by the ISP. Done. 




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

Midwest-IX 
http://www.midwest-ix.com 

----- Original Message ----- 

From: "Stephen Satchell" <list () satchell net> 
To: nanog () nanog org 
Sent: Tuesday, September 27, 2016 7:31:24 AM 
Subject: BCP38 adoption "incentives"? 

Does anyone know if any upstream and tiered internet providers include in their connection contracts a mandatory 
requirement that all directly-connected routers be in compliance with BCP38? 

Does anyone know if large ISPs like Comcast, Charter, or AT&T have put in place internal policies requiring 
retail/business-customer-aggregating routers to be in compliance with BCP38? 

Does any ISP, providing business Internet connectivity along with a block of IP addresses, include language in their 
contracts that any directly connected router must be in compliance with BCP38? 

I've seen a lot of moaning and groaning about how BCP38 is pretty much being ignored. Education is one way to help, but 
that doesn't hit anyone in the wallet. You have to motivate people to go out of their way to *learn* about BCP38; most 
business people are too busy with things that make them money to be concerned with "Internet esoterica" 
that doesn't add to the bottom line. You have to make their ignorance SUBTRACT from the bottom line. 

Contracts, properly enforced, can make a huge dent in the problem of 
BCP38 adoption. At a number of levels. 

Equipment manufacturers not usually involved in this sort of thing (home and SOHO market) would then have market 
incentive to provide equipment at the low end that would provide BCP38 support. Especially equipment manufacturers that 
incorporate embedded Linux in their products. They can be creative in how they implement their product; let creativity 
blossom. 

I know, I know, BCP38 was originally directed at Internet Service Providers at their edge to upstreams. I'm thinking 
that BCP38 needs to be in place at any point -- every point? -- where you have a significant-sized collection of 
systems/devices aggregated to single upstream connections. Particular systems/devices where any source address can be 
generated and propagated -- including compromised desktop computers, compromised light bulbs, compromised wireless 
routers, compromised you-name-it. 

(That is one nice thing about NAT -- the bad guys can't build spoofed packets. They *can* build, um, "other" 
packets...which is a different subject entirely.) 

(N.B.: Now you know why I'm trying to get the simplest possible definition of BCP38 into words. The RFCs don't contain 
"executive 
summaries".)