|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org Date: Tue, 27 Sep 2016 15:51:30 -0500 (CDT) From: Mike Hammett <nanog@ics-il.net> Cc: nanog@nanog.org In-Reply-To: <cb692134c0ad48a1aac490728027b4b4@SC58MEXGP032.CORP.CHARTERCOM.com> Errors-To: nanog-bounces@nanog.org 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 ----- 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 |