BCP38 adoption "incentives"?

Wed Sep 28 15:08:00 UTC 2016

At least as far as cable is concerned, there is already configuration on the CMTS (e.g. https://www.cisco.com/c/en/us/support/docs/broadband-cable/cable-security/20691-source-verify.html <https://www.cisco.com/c/en/us/support/docs/broadband-cable/cable-security/20691-source-verify.html>) that rejects things not coming from the assigned address, and AFAIK, it's best practice to enable it for more reasons than attack prevention.
However... most residential IPv4 traffic lives behind a NATing CPE. The CPE will either:
a) drop anything sourced from addresses not part of the configured LAN prefix
b) NAT everything regardless of its source
c) NAT things from its configured LAN, but bridge/forward anything else

A and C result in spoofed traffic being dropped, either at the CPE or the CMTS. Same is true if the CPE itself has been compromised and is sending spoofed traffic.
B results in it no longer being spoofed traffic, meaning that it defuses reflection attacks (the source address is no longer your attack target's address) but if it's raw packet floods, the attack still works but is now traceable back to its source.
The behavior of a specific CPE is largely dependent on its raw source materials. Many CPE cheap plastic routers are built from a few common reference architectures from the chipset makers (Broadcom, Intel, etc) and then modified and adapted to brand their UI with the name silk-screened on the plastic, add features to distinguish one cheap plastic router from another, etc. Reasonably recent linux-based kernels do some of A by themselves, may even do things like RPF check, TCP sequence number window check, state comparison, so unless the CPE vendor defeats it when they adapt it for their use, it mostly works. Devices built to captive standards (i.e. purpose-built for Cable, DSL providers) could have specific guidance about which behavior is the correct one, but that may or may not affect what happens to the ones that show up at your favorite big box retailer.

--Wes George, who has learned a thing or two about cable, but is speaking only for himself.

> On Sep 27, 2016, at 4:51 PM, Mike Hammett <nanog at ics-il.net> wrote:
> 
> 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 at charter.com>
> To: "Mike Hammett" <nanog at ics-il.net>
> Cc: nanog at 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 at charter.com
> Systems Engineer III, DAS DNS group
> Charter Communications
> 12405 Powerscourt Drive, St. Louis, MO 63131
> 
> 
> 
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Mike Hammett
> Sent: Tuesday, September 27, 2016 3:33 PM
> Cc: nanog at 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 at satchell.net>
> To: nanog at 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".)
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20160928/b08b804b/attachment.sig>