[191838] in North American Network Operators' Group
Re: BCP38 adoption "incentives"?
daemon@ATHENA.MIT.EDU (Wesley George)
Wed Sep 28 11:11:45 2016
X-Original-To: nanog@nanog.org
From: Wesley George <wesgeorge@puck.nether.net>
In-Reply-To: <2142792719.496.1475009488675.JavaMail.mhammett@ThunderFuck>
Date: Wed, 28 Sep 2016 11:08:00 -0400
To: Mike Hammett <nanog@ics-il.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_E1C00671-6264-4173-99E4-005C4F607644
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
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@ics-il.net> wrote:
>=20
> 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.
>=20
> FWIW, I believe most American ISPs *DO* manage their end-user routers.
>=20
>=20
>=20
>=20
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>=20
> Midwest-IX
> http://www.midwest-ix.com
>=20
> ----- Original Message -----
>=20
> 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"?
>=20
> Hi Mike,
>=20
> 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.
>=20
> 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.
>=20
> Andrew
>=20
> NB: My personal opinion and not official communiqu=C3=A9 of Charter.
>=20
>=20
> 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
>=20
>=20
>=20
> -----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"?
>=20
> It would be incredibly low impact to have the residential CPE block =
any source address not assigned by the ISP. Done.
>=20
>=20
>=20
>=20
> -----
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>=20
> Midwest-IX
> http://www.midwest-ix.com
>=20
> ----- Original Message -----
>=20
> From: "Stephen Satchell" <list@satchell.net>
> To: nanog@nanog.org
> Sent: Tuesday, September 27, 2016 7:31:24 AM
> Subject: BCP38 adoption "incentives"?
>=20
> 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?
>=20
> 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?
>=20
> 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?
>=20
> 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.
>=20
> Contracts, properly enforced, can make a huge dent in the problem of
> BCP38 adoption. At a number of levels.
>=20
> 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.
>=20
> 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.
>=20
> (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.)
>=20
> (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".)
>=20
--Apple-Mail=_E1C00671-6264-4173-99E4-005C4F607644
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCAAGBQJX69zQAAoJEBdIPc22E6UhRuoP/1KXyVfacJeZ7pAtlLGystYl
DRdrzlRw9NVbYHTDd9tSdYKUAOWH9WS7HBYfytI23WNWfiHej7RKh/c2Nna+Kg8h
LlRc5bL6f5P0Sos8sft/OfyW+5HzcpG9gFZGxdxymE/9HZnr/jxEQOdz3mUv2cl2
00Op6NAbIIuMYavTh2IbDA+cQjmKAIHxFdVcUQZScVDslGwNl2qoXenHfgLkPJeV
c2htdzoL7lBH2ckfnwDu8pEh+/trbqxWWxYMpFm7Dw/JjPMJD3e24FkRRuI5tDis
FIIe8obO3WyCdnZX+NQUdUyFOgxPbX1DOjba6fHe3YfPVB8bqelKmxooIyB+6cV1
WJuidzn2AprdEMKq9UwHdGpDaC9CDpHDLo1b0BaCAlnR+Z72ZVai2PX4DGGeTxHf
3DbGfS5SIiTHhqi9CuT/R0kuNm38ZlTvtZLlIakeSuGgkDPLcKZZ0eO3Q1NOoF9I
0SExtYOevAJM9Iq+XW7UFwsgFf3hE6lktVpp+7KTwOakKowH93veWCLvYjXkT7Xa
dzFjpQrvs47GQzg5VbE7oHnNRmR5yr/dDKQYt2HUb9C0e9bS3gTNPtUqgCuTuv3p
GRVt4hwfFzj1WCDkFLeNXue2YvishShjq/IVbOGsxOuPdxyfq5T1xi1Sl3eNyudt
pb9AAyNuePM8ipqvPm7B
=lYyM
-----END PGP SIGNATURE-----
--Apple-Mail=_E1C00671-6264-4173-99E4-005C4F607644--
