|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org Date: Wed, 28 Sep 2016 14:05:55 -0500 (CDT) From: Mike Hammett <nanog@ics-il.net> Cc: nanog@nanog.org In-Reply-To: <E2ABCC91-AB11-48FD-9A84-6EED369C726B@puck.nether.net> Errors-To: nanog-bounces@nanog.org IPv6?=20 Is that common in CMTSes or just in certain ones?=20 -----=20 Mike Hammett=20 Intelligent Computing Solutions=20 http://www.ics-il.com=20 Midwest-IX=20 http://www.midwest-ix.com=20 ----- Original Message ----- From: "Wesley George" <wesgeorge@puck.nether.net>=20 To: "Mike Hammett" <nanog@ics-il.net>=20 Cc: nanog@nanog.org=20 Sent: Wednesday, September 28, 2016 10:08:00 AM=20 Subject: Re: BCP38 adoption "incentives"?=20 At least as far as cable is concerned, there is already configuration on th= e CMTS (e.g. https://www.cisco.com/c/en/us/support/docs/broadband-cable/cab= le-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 r= easons than attack prevention.=20 However... most residential IPv4 traffic lives behind a NATing CPE. The CPE= will either:=20 a) drop anything sourced from addresses not part of the configured LAN pref= ix=20 b) NAT everything regardless of its source=20 c) NAT things from its configured LAN, but bridge/forward anything else=20 A and C result in spoofed traffic being dropped, either at the CPE or the C= MTS. Same is true if the CPE itself has been compromised and is sending spo= ofed traffic.=20 B results in it no longer being spoofed traffic, meaning that it defuses re= flection attacks (the source address is no longer your attack target's addr= ess) but if it's raw packet floods, the attack still works but is now trace= able back to its source.=20 The behavior of a specific CPE is largely dependent on its raw source mater= ials. Many CPE cheap plastic routers are built from a few common reference = architectures from the chipset makers (Broadcom, Intel, etc) and then modif= ied and adapted to brand their UI with the name silk-screened on the plasti= c, 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 compariso= n, 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 C= able, DSL providers) could have specific guidance about which behavior is t= he correct one, but that may or may not affect what happens to the ones tha= t show up at your favorite big box retailer.=20 --Wes George, who has learned a thing or two about cable, but is speaking o= nly for himself.=20 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 Mike Hammett=20 Intelligent Computing Solutions=20 http://www.ics-il.com=20 Midwest-IX=20 http://www.midwest-ix.com=20 ----- Original Message -----=20 From: "Andrew White" < Andrew.White2@charter.com >=20 To: "Mike Hammett" < nanog@ics-il.net >=20 Cc: nanog@nanog.org=20 Sent: Tuesday, September 27, 2016 3:44:35 PM=20 Subject: RE: BCP38 adoption "incentives"?=20 Hi Mike,=20 This assumes the ISP manages the customer's CPE or home router, which is of= ten 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 (tra= nsit and peering points) to filter out packets that should not originate fr= om 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 Andrew White=20 Desk: 314.394-9594 | Cell: 314-452-4386 | Jabber=20 andrew.white2@charter.com=20 Systems Engineer III, DAS DNS group=20 Charter Communications=20 12405 Powerscourt Drive, St. Louis, MO 63131=20 -----Original Message-----=20 From: NANOG [ mailto:nanog-bounces@nanog.org ] On Behalf Of Mike Hammett=20 Sent: Tuesday, September 27, 2016 3:33 PM=20 Cc: nanog@nanog.org=20 Subject: Re: BCP38 adoption "incentives"?=20 It would be incredibly low impact to have the residential CPE block any sou= rce address not assigned by the ISP. Done.=20 -----=20 Mike Hammett=20 Intelligent Computing Solutions=20 http://www.ics-il.com=20 Midwest-IX=20 http://www.midwest-ix.com=20 ----- Original Message -----=20 From: "Stephen Satchell" < list@satchell.net >=20 To: nanog@nanog.org=20 Sent: Tuesday, September 27, 2016 7:31:24 AM=20 Subject: BCP38 adoption "incentives"?=20 Does anyone know if any upstream and tiered internet providers include in t= heir connection contracts a mandatory requirement that all directly-connect= ed routers be in compliance with BCP38?=20 Does anyone know if large ISPs like Comcast, Charter, or AT&T have put in p= lace internal policies requiring retail/business-customer-aggregating route= rs to be in compliance with BCP38?=20 Does any ISP, providing business Internet connectivity along with a block o= f IP addresses, include language in their contracts that any directly conne= cted router must be in compliance with BCP38?=20 I've seen a lot of moaning and groaning about how BCP38 is pretty much bein= g 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* abou= t BCP38; most business people are too busy with things that make them money= to be concerned with "Internet esoterica"=20 that doesn't add to the bottom line. You have to make their ignorance SUBTR= ACT from the bottom line.=20 Contracts, properly enforced, can make a huge dent in the problem of=20 BCP38 adoption. At a number of levels.=20 Equipment manufacturers not usually involved in this sort of thing (home an= d SOHO market) would then have market incentive to provide equipment at the= low end that would provide BCP38 support. Especially equipment manufacture= rs 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 a= t any point -- every point? -- where you have a significant-sized collectio= n 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, compromi= sed wireless routers, compromised you-name-it.=20 (That is one nice thing about NAT -- the bad guys can't build spoofed packe= ts. They *can* build, um, "other" packets...which is a different subject en= tirely.)=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=20 summaries".)=20
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |