Ok, let's haul this up out of the other thread. It seems consensus that the anti-source-address-spoofing provisions (at least) of BCP38 have long since become critical to mitigating (and eventually preventing) UDP attacks like DNS reflection and such, and that such attacks are uniformly considered Bad Things. It also seems that, with 13 years to get it done, even if equipment makers have put usable working knobs into their edge routers and concentrators, sufficient numbers of IAPs have not started turning them on. The problem here is, of course, one of externalities and the Common Good, hard sales to make in a business environment. But have we reached the point where it's time to start trying? Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)? Put this in contracts and renewals, with the same penalty? Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs? Cheers, -- jr 'will rouse rabble for food' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Mar 26, 2013, at 9:51 PM, Jay Ashworth wrote:
Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs?
Unfortunately, no - else it would've come to pass quite some time ago. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mar 26, 2013, at 11:04 AM, "Dobbins, Roland" <rdobbins@arbor.net> wrote:
On Mar 26, 2013, at 9:51 PM, Jay Ashworth wrote:
Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs?
Unfortunately, no - else it would've come to pass quite some time ago.
My observation is that a lot of people sometimes struggle to just hold their routing together at times, let alone to do something that is a second tier feature/capability. - Jared
On 3/26/13, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Mar 26, 2013, at 9:51 PM, Jay Ashworth wrote:
Perhaps you should reframe your strategy as "security problem", and show how providers have implemented BCP38, how it is such a common practice, that not implementing BCP38 may fall short of the minimum standard of due care required to avoid liability, in case your network is abused to launch an attack.. Incurs possible legal risks that should be reviewd by lawyers, due to possible liability in facilitating a DoS attack. That may be better at persuading your CEOs of large SPs than "It's just good engineering"; it's not that following BCP38 is just excellent practice. It's also that ignoring BCP38 in some circumstances might be extremely poor, even negligent practice. Possibly Develop an industry certification/accreditation based on network engineering practices, and make it potentially so that service providers want to carry it. Then their marketing people can display their "See our network is more secure and reliable" logo on the website, and pressure other networks to seek 3rd party qualification; include BCP38 as one of several criteria, "designed to help reduce the degree of malicious activity, unmitigated DoS incidents, instability, or poor/inconsistent user experience". If enough networks carry some sort of mark of quality, then maybe it becomes meaningful as a tool persuasion: there may be a smaller quantity of demand for the purchase of services from networks that don't carry it, unless they compensate by lowering their price. While you're at it, include as recommended practices, and provide multiple levels of "Verified good network neighbor" status: o 3rd party audited practices with regards to responsiveness and cooperation by contacts to address abuse and connectivity issues. o Requirement the network have a policy of assisting with the mitigation of attack traversing any peers or customers, through required extensive network information sharing. o Truthful representation of service in all marketing materials. o No "banned" internet protocols or ports, (e.g. "Our network doesn't allow SSH protocol"); no NAT'ing by the SP. o A no-spamming policy, a no-repeated-failed-login policy, a no port scanning policy, a no DoS policy that includes requirement the SP investigate spam or other complaints and take sufficient actions to disable offending hosts or networks, or ensure further spam is blocked.. o Appropriate filtering of incoming bgp announcements. o Accurate WHOIS information, listing the actual contact, no 3rd party or intermediary for number resources, domains, etc. o Easily accessible and responsive technical and abuse contacts for all services. o Not subverting or altering DNS query responses, or other packets, as they cross the network; for example, not offering name lookup servers that claim to provide DNS service, but covertly rewrite or capture NXDOMAIN or other responses, sending an altered response instead.
Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs?
Unfortunately, no - else it would've come to pass quite some time ago. -- -JH
On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said:
Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)?
How would one prove this? (In particular, consider the test "have them download the spoofer code from SAIL and run it" - I'm positive there will be sites that will put in a /32 block for the test machine so it "fails" to spoof but leave it open for the rest of the net).
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said:
Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)?
How would one prove this? (In particular, consider the test "have them download the spoofer code from SAIL and run it" - I'm positive there will be sites that will put in a /32 block for the test machine so it "fails" to spoof but leave it open for the rest of the net).
An excellent question. I suspect the largest collection of problem networks are cable/DSL eyeball networks; certainly a cabal of network ops types could be formed, anonymously to the carriers, who could run test software from home... I'm sure there are a bunch of ways that could reasonably give you a heads up that it's time to investigate. Due process is certainly called for, but clearly, lesser threats (if any have been made) aren't solving the problem. Are you conceding that BCP38 *will* solve the problem? Cause that's Question One. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
(Mobile device) On Mar 26, 2013, at 11:06 AM,Valdis.Kletnieks@vt.edu wrote:
On Tue, 26 Mar 2013 10:51:45 -0400, Jay Ashworth said:
Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)?
How would one prove this? (In particular, consider the test "have them download the spoofer code from SAIL and run it" - I'm positive there will be sites that will put in a /32 block for the test machine so it "fails" to spoof but leave it open for the rest of the net).
Well, I'm not sure this is what's being suggested by Jay, but many peering agreements/policies have something in them that say "prevent spoofing to best effort". Such statements could be strengthened in a global effort, and then spoofed source addresses could lead to depeering much faster/harder than what happens today. It would be reactionary rather than proactive, but still better than what we have now where spoofing is kind of like "it can't be helped". -- Darius Jahandarie
On Mar 26, 2013, at 11:19 AM, Darius Jahandarie <djahandarie@gmail.com> wrote:
Well, I'm not sure this is what's being suggested by Jay, but many peering agreements/policies have something in them that say "prevent spoofing to best effort". Such statements could be strengthened in a global effort, and then spoofed source addresses could lead to depeering much faster/harder than what happens today. It would be reactionary rather than proactive, but still better than what we have now where spoofing is kind of like "it can't be helped".
I'll certainly say that I've worked for many an imperfect network when it comes to this. I've always tried to drop bogons (non routed space) including spoofed packets. While many a network is imperfect, there are places where we can improve. The high-speed servers in data centers or part of your VM infrastructure is one example of a place where: a) They aren't running BGP for multihoming with 10k prefixes b) have a fixed IP subnet for that edge host or management LAN c) could quickly have unicast-rpf enabled with no impact. If you have folks bringing in/out either known or unknown VMs, you must treat these as a possible risk. Same goes for any colocation environment. Those T1 customers you still have? DS3 with one prefix and BGP on? Turn on unicast-rpf there too. You won't break anyone. I recall going around and turning it on dozens of T1's at a time since they all had static routes. Just because the link size is now gig-e (or 10G or 100G) doesn't mean it's not worth doing. Consider this my plea to the community. Ask the question: Can we spoof? What happens when law enforcement comes to the door to confiscate a machine because it was involved in a 10's of gigs of attack? what if it's 100's of gigs? At what size of attack for what duration will make things change? Are there simple places where unicast-rpf makes sense? In front of the firewall is a simple place to drop spoofed packets. You'd be surprised how many of them are broken and emit an internal IP anyways, so don't leak that. I certainly see many places where simple steps like this will improve the overall ecosystem and make us safer. Machines get compromised, but limit the scope of the possible abuse. If nothing is done, will udp/53 become blackholed just like tcp/25 is for many folks? Is that the type of network you want to debug and troubleshoot? - Jared
On Tue, 26 Mar 2013, Darius Jahandarie wrote:
Well, I'm not sure this is what's being suggested by Jay, but many peering agreements/policies have something in them that say "prevent spoofing to best effort". Such statements could be strengthened in a global effort, and then spoofed source addresses could lead to depeering much faster/harder than what happens today. It would be reactionary rather than proactive, but still better than what we have now where spoofing is kind of like "it can't be helped".
I wish the Internet census people would try spoofing from their "botnet" and tell us which ISPs allow spoofing. I don't think this will fixed until there is a hall of shame or some kind of law requiring this and offenders would be fined. Can't we get homeland security into this? Threat to US national security if people can spoof? :P -- Mikael Abrahamsson email: swmike@swm.pp.se
but they are paying attention.... /bill On Tue, Mar 26, 2013 at 09:25:09AM -0700, Jared Mauch wrote:
I'm not sure you want this regulated.
Jared Mauch
On Mar 26, 2013, at 9:20 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
Can't we get homeland security into this? Threat to US national security if people can spoof? :P
On Tue, Mar 26, 2013 at 10:51 AM, Jay Ashworth <jra@baylink.com> wrote:
But have we reached the point where it's time to start trying?
Yes.
Do we need to define a flag day, say one year hence, and start making the sales pitch to our Corporate Overlords that we need to apply the IDP to edge connections which cannot prove they've implemented BCP38 (or at very least, the source address spoofing provisions thereof)? Put this in contracts and renewals, with the same penalty?
Yes, but scope the problem a little differently. 1. The general IDP does not apply to stub networks which do not speak BGP. It is for those stubs' ISPs to determine how they'll handle mis-sourced traffic they receive from those networks. 2. A BGP origin-only network is required to secure its BGP-speaking borders against source address spoofing. It may also secure spoofing from downstream networks (and in fact it SHOULD do so) but it avoids the IDP so long as its BGP-speaking borders are secured. 3. A BGP transit network is required to secure all components of its network against source address spoofing, including all non-BGP stub customers and all origin-only BGP customers. It is not expected to prevent spoofed packets from arriving from neighboring transit BGP networks. It is also expected to promptly assist (24/7/365) with trace requests from any individual presenting legitimate credentials as the assignee of a particular source address and presenting with reasonable evidence that packets with a spoofed address cross a specifically identified system owned by the transit network. Where the packet stream continues, these trace requests must promptly result in identification of the actual source of the packet (if within the transit network's system) or the identification of the neighboring system, the specific entry point and high-level contacts within the neighbor system capable of continuing the trace. Some number of misconfigurations which permit spoofed packets from components of the transit network's components are to be expected and promptly corrected. 4. Applying the IDP _does not_ mean you cut off the network. That'll piss of your customers as much or more than it pisses off theirs. The position is untenable. Instead, the IDP consists of redirecting the offender's public presence web sites to a web site which proclaims the IDP, lists the causes of the IDP and lists the actions required to lift the IDP. 5. IDP can't be a local decision. We should elect or empanel or otherwise select a group of individuals who decide both when a network gets the IDP and when the IDP is lifted. Compliance with the group's decision to impose an IDP can be optional but a riot of RBLs like have developed in the anti-spam community would cause at least as much trouble as it fixes.
Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs?
To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
Yes, but scope the problem a little differently.
1. The general IDP does not apply to stub networks which do not speak BGP. It is for those stubs' ISPs to determine how they'll handle mis-sourced traffic they receive from those networks.
So, here, you mean customers of such as "Road Runner Business", who have an office full of workstations and maybe some servers. The goal, unless I badly misunderstood it, was to *drop forged traffic coming from this sort of source (assuming you generalize "my PC at home on a cablemodem" as the limiting example of this class, which I do).
2. A BGP origin-only network is required to secure its BGP-speaking borders against source address spoofing. It may also secure spoofing from downstream networks (and in fact it SHOULD do so) but it avoids the IDP so long as its BGP-speaking borders are secured.
This is the next size up of edge network; a buyer of transit. This item does no good; you're expecting *the potential bad actor* *not to act badly*.
3. A BGP transit network is required to secure all components of its network against source address spoofing, including all non-BGP stub customers and all origin-only BGP customers. It is not expected to prevent spoofed packets from arriving from neighboring transit BGP networks.
*This* is Road Runner. Also Comcast, Mindspring, and the other Top 40 eyeball networks. It is also, of course, larger carriers who sell access in addition to more traditional transit and possibly peering. AFAICT, this is the spot where source-address-spoofing needs to be *enforced*; the people selling connections and transit here *know* what addresses should be coming in those pipes, and can therefore -- if their gear permits, and it damned well should by now -- force the dropping of all packets coming in with bogus source addresses.
It is also expected to promptly assist (24/7/365) with trace requests from any individual presenting legitimate credentials as the assignee of a particular source address and presenting with reasonable evidence that packets with a spoofed address cross a specifically identified system owned by the transit network. Where the packet stream continues, these trace requests must promptly result in identification of the actual source of the packet (if within the transit network's system) or the identification of the neighboring system, the specific entry point and high-level contacts within the neighbor system capable of continuing the trace.
Assuming they pass the packets at all, which is what I'm trying to prevent, myself. Surely, special case handling will need to be done for customers who are multihomed, and may originate packets from connection A out connection B, but *this is the layer* where that must be done; you can't do it any closer to the backbone, since the necessary administrative knowledge isn't available there.
4. Applying the IDP _does not_ mean you cut off the network. That'll piss of your customers as much or more than it pisses off theirs. The position is untenable. Instead, the IDP consists of redirecting the offender's public presence web sites to a web site which proclaims the IDP, lists the causes of the IDP and lists the actions required to lift the IDP.
Unless I misunderstand you there, you're suggesting that inbound HTTP to public websites *operated by the spoofing entity* should be redirected to a site that shames them? Yeah, that will piss them off less... :-)
5. IDP can't be a local decision. We should elect or empanel or otherwise select a group of individuals who decide both when a network gets the IDP and when the IDP is lifted. Compliance with the group's decision to impose an IDP can be optional but a riot of RBLs like have developed in the anti-spam community would cause at least as much trouble as it fixes.
Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs?
To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries?
The problem with that sub-approach is that luminaries (of the scale that everyone will automatically listen to them), as Jon Postel has said, do not scale. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Tue, Mar 26, 2013 at 4:09 PM, Jay Ashworth <jra@baylink.com> wrote:
From: "William Herrin" <bill@herrin.us> 1. The general IDP does not apply to stub networks which do not speak BGP. It is for those stubs' ISPs to determine how they'll handle mis-sourced traffic they receive from those networks.
So, here, you mean customers of such as "Road Runner Business", who have an office full of workstations and maybe some servers.
Correct.
The goal, unless I badly misunderstood it, was to *drop forged traffic coming from this sort of source (assuming you generalize "my PC at home on a cablemodem" as the limiting example of this class, which I do).
Indeed. But it isn't achievable. $Random_SOHO will continue to be hacked on a regular basis. He doesn't have someone working for him with the skill to prevent it. Further victimizing him with a game of whack-a-mole helps nobody. Besides, his failings aren't important to us. What's important to us is that his failings don't impact us. We achieve that by insisting that his ISP not leak his forged packets on to the public Internet. It would be nice if his ISP didn't accept the forged packets at all, but that's really not our problem and we don't need to make it our business.
2. A BGP origin-only network is required to secure its BGP-speaking borders against source address spoofing. It may also secure spoofing from downstream networks (and in fact it SHOULD do so) but it avoids the IDP so long as its BGP-speaking borders are secured.
This is the next size up of edge network; a buyer of transit.
This item does no good; you're expecting *the potential bad actor* *not to act badly*.
At last count there are fewer than 45,000 such systems worldwide, not millions upon millions like in group 1. This is a manageable number of potential bad actors to whom the IDP would apply. Also, we're not looking to catch bad actors here. We're looking to catch sloppy actors. We catch bad actors at step 3 by spanking their upstream transit ISPs for failing to prevent source spoofing.
3. A BGP transit network is required to secure all components of its network against source address spoofing, including all non-BGP stub customers and all origin-only BGP customers. It is not expected to prevent spoofed packets from arriving from neighboring transit BGP networks.
*This* is Road Runner. Also Comcast, Mindspring, and the other Top 40 eyeball networks. It is also, of course, larger carriers who sell access in addition to more traditional transit and possibly peering.
Correct.
AFAICT, this is the spot where source-address-spoofing needs to be *enforced*;
Unfortunately, it's also the spot where system complexity reaches a point where as a purely technical matter, source address filtering isn't always possible. You can filter your customers based on the routes they say they plan send you and you can filter your own internal networks based on the addresses you assign but filtering your peers for falsely sourced packets can be as intractable as filtering your upstream for falsely sourced packets. Hence the additional expectations...
It is also expected to promptly assist (24/7/365) with trace requests from any individual presenting legitimate credentials as the assignee of a particular source address and presenting with reasonable evidence that packets with a spoofed address cross a specifically identified system owned by the transit network. Where the packet stream continues, these trace requests must promptly result in identification of the actual source of the packet (if within the transit network's system) or the identification of the neighboring system, the specific entry point and high-level contacts within the neighbor system capable of continuing the trace.
4. Applying the IDP _does not_ mean you cut off the network. That'll piss of your customers as much or more than it pisses off theirs. The position is untenable. Instead, the IDP consists of redirecting the offender's public presence web sites to a web site which proclaims the IDP, lists the causes of the IDP and lists the actions required to lift the IDP.
Unless I misunderstand you there, you're suggesting that inbound HTTP to public websites *operated by the spoofing entity* should be redirected to a site that shames them? Yeah, that will piss them off less... :-)
I don't care about about pissing them off. I care about pissing off my customers. My customers will be pissed off if they can't reach their customers and suppliers. Who will often be hosted by the target of the IDP. But will much more rarely be the target of the IDP.
To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries?
The problem with that sub-approach is that luminaries (of the scale that everyone will automatically listen to them), as Jon Postel has said, do not scale.
Which is A-OK because if we're applying more than 1 or 2 IDPs in a year to folks who weren't intentionally bad actors then we're doing it wrong. It shouldn't ever "scale." -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
----- Original Message -----
From: "William Herrin" <bill@herrin.us>
So, here, you mean customers of such as "Road Runner Business", who have an office full of workstations and maybe some servers.
Correct.
The goal, unless I badly misunderstood it, was to *drop forged traffic coming from this sort of source (assuming you generalize "my PC at home on a cablemodem" as the limiting example of this class, which I do).
Indeed. But it isn't achievable. $Random_SOHO will continue to be hacked on a regular basis. He doesn't have someone working for him with the skill to prevent it. Further victimizing him with a game of whack-a-mole helps nobody.
Besides, his failings aren't important to us. What's important to us is that his failings don't impact us. We achieve that by insisting that his ISP not leak his forged packets on to the public Internet. It would be nice if his ISP didn't accept the forged packets at all, but that's really not our problem and we don't need to make it our business.
It's possible I badly misunderstand how things like unicast-rpf work, Bill. I run much tinier networks than most people here. But what I *do* understand of it is: you have to run it *at the edge concentrator*, cause that's the only device which knows which packets to accept... since *it assigned the address for the link*. When I say "drop forged traffic coming from...", *who I mean is 'his ISP'*, as you suggest in the next graf. I don't see that there's anyway to *know* packets have a forged address anywhere north of the edge of the lowest tier IAP the connection is served from. Did I miss something? Or was I simply unclear?
2. A BGP origin-only network is required to secure its BGP-speaking borders against source address spoofing. It may also secure spoofing from downstream networks (and in fact it SHOULD do so) but it avoids the IDP so long as its BGP-speaking borders are secured.
This is the next size up of edge network; a buyer of transit.
This item does no good; you're expecting *the potential bad actor* *not to act badly*.
At last count there are fewer than 45,000 such systems worldwide, not millions upon millions like in group 1. This is a manageable number of potential bad actors to whom the IDP would apply.
Yes. These are the people to whom edge nodes and private non-BGP nets speak; the tier 3 4 and 5 network providers who run edge concentrators and assign addresses.
Also, we're not looking to catch bad actors here. We're looking to catch sloppy actors. We catch bad actors at step 3 by spanking their upstream transit ISPs for failing to prevent source spoofing.
...which you would detect ... how? *Those* aggregator networks have no contractual reason to know what's a valid address coming to them, unlike the networks to which end sites attach directly.
*This* is Road Runner. Also Comcast, Mindspring, and the other Top 40 eyeball networks. It is also, of course, larger carriers who sell access in addition to more traditional transit and possibly peering.
Correct.
AFAICT, this is the spot where source-address-spoofing needs to be *enforced*;
Unfortunately, it's also the spot where system complexity reaches a point where as a purely technical matter, source address filtering isn't always possible. You can filter your customers based on the routes they say they plan send you and you can filter your own internal networks based on the addresses you assign but filtering your peers for falsely sourced packets can be as intractable as filtering your upstream for falsely sourced packets.
I don't believe that's what I said. Filtering based on routes doesn't help; that's *destination address*, not source, no? Yes, filtering your peers, or even transit customers, is effectively impossible; it has to be done where addresses are handed out.
4. Applying the IDP _does not_ mean you cut off the network. That'll piss of your customers as much or more than it pisses off theirs. The position is untenable. Instead, the IDP consists of redirecting the offender's public presence web sites to a web site which proclaims the IDP, lists the causes of the IDP and lists the actions required to lift the IDP.
Unless I misunderstand you there, you're suggesting that inbound HTTP to public websites *operated by the spoofing entity* should be redirected to a site that shames them? Yeah, that will piss them off less... :-)
I don't care about about pissing them off. I care about pissing off my customers. My customers will be pissed off if they can't reach their customers and suppliers. Who will often be hosted by the target of the IDP. But will much more rarely be the target of the IDP.
Ok; I apologies; I have laid the bike down in the sandy corner at this point. Huh?
To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries?
The problem with that sub-approach is that luminaries (of the scale that everyone will automatically listen to them), as Jon Postel has said, do not scale.
Which is A-OK because if we're applying more than 1 or 2 IDPs in a year to folks who weren't intentionally bad actors then we're doing it wrong. It shouldn't ever "scale."
Yes, but you can't measure such a panel on output, you have to measure it on *input*, no? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Tue, Mar 26, 2013 at 9:18 PM, Jay Ashworth <jra@baylink.com> wrote:
From: "William Herrin" <bill@herrin.us> Indeed. But it isn't achievable. $Random_SOHO will continue to be hacked on a regular basis. He doesn't have someone working for him with the skill to prevent it. Further victimizing him with a game of whack-a-mole helps nobody.
Besides, his failings aren't important to us. What's important to us is that his failings don't impact us. We achieve that by insisting that his ISP not leak his forged packets on to the public Internet. It would be nice if his ISP didn't accept the forged packets at all, but that's really not our problem and we don't need to make it our business.
It's possible I badly misunderstand how things like unicast-rpf work, Bill.
No, you're pretty close. The technology known as unicast-rpf works anywhere there's a choke point where traffic to and from a given set of IP addresses has no other candidate paths.
When I say "drop forged traffic coming from...", *who I mean is 'his ISP'*, as you suggest in the next graf. I don't see that there's anyway to *know* packets have a forged address anywhere north of the edge of the lowest tier IAP the connection is served from.
RPF is but a subset of source address filtering strategies, the one where the source address filtering always mirrors the routing table. As a origin-only BGP AS, I know exactly what sources I expect to leave my system. And my ISPs know what source addresses I've told them to expect. RPF won't work reliably on those links, but they can be configured manually or with a tool to accept only the source addresses I've declared. If I declare 0.0.0.0/0, a reasonable ISP understands that I'm lying. If I declare a particular /24 and two days later the ISP gets a trace request from the apparent registrant (who isn't me) it's not hard to infer that I may be a bad actor.
Did I miss something? Or was I simply unclear?
The problem with RPF is that understanding where you can and can't employ it is part of a senior network engineer's skill set. But the trivial network architectures where it can be applied are often handed off to a junior network engineer. The skill set is available primarily in the places where it can't be used.
...which you would detect ... how? *Those* aggregator networks have no contractual reason to know what's a valid address coming to them, unlike the networks to which end sites attach directly.
They most certainly do have a valid contractual reason to know what routes and source addresses their origin-only AS customer intends to send them and the responsible transit networks already do filter those links.
Filtering based on routes doesn't help; that's *destination address*, not source, no?
Except for the special case where RPF is usable, that's correct.
Yes, filtering your peers, or even transit customers, is effectively impossible; it has to be done where addresses are handed out.
Filtering that subset of your customers which consists of non-BGP speakers and BGP origin-only networks is neither impossible nor particularly hard. Harder than "rpf on", but not hard. Even if they lie about what addresses to expect, they're not left with carte blanche to impersonate any address at all. The more transit BGP systems which do this, the smaller the spoofing problem becomes. And there are few enough _transit_ BGP systems (less than 10,000) that they can be realistically and usefully held accountable for a failure to do so.
I don't care about about pissing them off. I care about pissing off my customers. My customers will be pissed off if they can't reach their customers and suppliers. Who will often be hosted by the target of the IDP. But will much more rarely be the target of the IDP.
Ok; I apologies; I have laid the bike down in the sandy corner at this point. Huh?
My leeway with the CEO ends when I lose customers. So does yours. For an IDP to be acceptable, the Penalty part has to be something painful to the offender without pissing off my customers. Cutting him off the network pisses off my customers who can no longer reach his customers. It's why no one wins a peering battle with Cogent: Cogent is willing to take the heat. Deep sixing the packets to his particular web site is far more tenable, especially when paired with an explanation of the credible threat he poses to my customers' networks.
Which is A-OK because if we're applying more than 1 or 2 IDPs in a year to folks who weren't intentionally bad actors then we're doing it wrong. It shouldn't ever "scale."
Yes, but you can't measure such a panel on output, you have to measure it on *input*, no?
Not particularly. There's nothing wrong with picking the worst current offenders and letting the rest slide with a warning to clean up their act or be next on the list. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Tue, Mar 26, 2013 at 10:01 AM, William Herrin <bill@herrin.us> wrote:
On Tue, Mar 26, 2013 at 10:51 AM, Jay Ashworth <jra@baylink.com> wrote: ...
Do the engineering heads at the top 10 tier-1/2 carriers carry enough water to make that sale to the CEOs?
To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries?
I'm not a lawyer, but I do work out with one at the gym. I would strongly encourage people considering this to discuss the following terms with their legal staff *first*: Sherman Anti-Trust Act Anti-competitive practice Refusal to deal restraint of trade collusion cartel Once you've had a polite and cheerful discussion about the feasibility of some set of companies in the public space banding together to restrict access to a subset of their competitors with your legal staff, we can go back to discussing how best to configure our routers. Thanks! Matt
On Tue, Mar 26, 2013 at 5:16 PM, Matthew Petach <mpetach@netflight.com> wrote:
On Tue, Mar 26, 2013 at 10:01 AM, William Herrin <bill@herrin.us> wrote:
To ask the CEOs to authorize cutting off access to a competitor's web site with the full support and approval of a group of recognized Internet luminaries?
Once you've had a polite and cheerful discussion about the feasibility of some set of companies in the public space banding together to restrict access to a subset of their competitors with your legal staff, we can go back to discussing how best to configure our routers.
This has already been tested vis a vis the anti-spam RBLs. There are no new concepts here to challenge a court. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity. We are all experts in the field and the courts apply higher standards to us than they do to Joe Blogs. We know machines get compromised. We know how to block spoofed traffic from compromised machines. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity. We are all experts in the field and the courts apply higher standards to us than they do to Joe Blogs. We know machines get compromised. We know how to block spoofed traffic from compromised machines.
Careful: source address spoofing, like using a name you don't have on your driver license *is not inherently a crime*. *Fraudulent behaviour which is advanced thereby* makes it an additional crime. SAS is sometimes necessary for testing. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Tue, Mar 26, 2013 at 6:43 PM, Jay Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity. We are all experts in the field and the courts apply higher standards to us than they do to Joe Blogs. We know machines get compromised. We know how to block spoofed traffic from compromised machines.
Careful: source address spoofing, like using a name you don't have on your driver license *is not inherently a crime*. *Fraudulent behaviour which is advanced thereby* makes it an additional crime.
SAS is sometimes necessary for testing.
An argument could be made that "...fraud is fraud, is fraud, is fraud..." and should vigorously discouraged. :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
----- Original Message -----
From: "Paul Ferguson" <fergdawgster@gmail.com>
Careful: source address spoofing, like using a name you don't have on your driver license *is not inherently a crime*. *Fraudulent behaviour which is advanced thereby* makes it an additional crime.
SAS is sometimes necessary for testing.
An argument could be made that "...fraud is fraud, is fraud, is fraud..." and should vigorously discouraged. :-)
Sure, Ferg. But my point was "be careful what you take as a proxy for fraud; some behaviors have valid uses". Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
In message <10071844.11080.1364348618832.JavaMail.root@benjamin.baylink.com>, J ay Ashworth writes:
----- Original Message -----
From: "Mark Andrews" <marka@isc.org>
If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity. We are all experts in the field and the courts apply higher standards to us than they do to Joe Blogs. We know machines get compromised. We know how to block spoofed traffic from compromised machines.
Careful: source address spoofing, like using a name you don't have on your driver license *is not inherently a crime*. *Fraudulent behaviour which is advanced thereby* makes it an additional crime.
Which is why I said "like this" as this bundle of threads started with spoofing of DNS queries.
SAS is sometimes necessary for testing.
Indeed. Those are exceptions not the rule. How many residential connections would be doing SAS for testing, compared to configuration errors or as the result on criminal misappropriation of equipement. When both configuration errors and spoofed traffic as the result of criminal misappropriation of equipement both should be dropped what are the courts likely to find? Even with SAS for testing you can filter based on MAC / port / link so only designated machines can send spoofed traffic. I certainly don't want to be the subject of a test case. Mark
Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.co m Designer The Things I Think RFC 210 0 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DI I St Petersburg FL USA #natog +1 727 647 127 4
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 27 Mar 2013 12:01:25 +1100, Mark Andrews said:
If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity.
So what you're saying is that every single person who ran the spoofing program to help the SAIL guys gather data is a criminal?
In message <8277.1364350487@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu w rites:
On Wed, 27 Mar 2013 12:01:25 +1100, Mark Andrews said:
If you are with a ISP that does not practice BCP 38 are you willing to risk your neck that you won't be subject to a "aiding and abetting" charge? All of us here know that spoofing address like this is a criminal activity.
So what you're saying is that every single person who ran the spoofing program to help the SAIL guys gather data is a criminal?
See my response to Jay. I did not present this as a absolute. Surveying which connections are open to address spoofing may or may not be a criminal activity. It all depends on intent of the person gathering the data. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Mar 26, 2013 at 10:40 PM, Mark Andrews <marka@isc.org> wrote:
Surveying which connections are open to address spoofing may or may not be a criminal activity. It all depends on intent of the person gathering the data.
Such is the nature of law. When a dead body shows up shot, intent (fancily called "mens rea") is the difference between murder, manslaughter and self-defense. Its true of source address spoofing. Its true of collusion and anti-trust as well. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mar 26, 2013, at 10:51 AM, Jay Ashworth <jra@baylink.com> wrote:
The problem here is, of course, one of externalities and the Common Good, hard sales to make in a business environment.
"Common Good" situations are readily dealt with, but generally not on a voluntary basis. You establish how the resource is to be managed, and then you put in place mechanisms to deal with enforcement. The problem is that en-force-ment contains "force", which is something that we really don't want anyone (or set of anyones) using except "governments" (which in our social constructs are the only ones supposed to be telling one party under penalty of force not to do something otherwise in its best interest.) The problem, of course, with asking governments for help is that the output often does not resemble anything related to the original problem statement and can make the situation worse... If you setup an economic system where folks do the right thing because it is in their own interest, that's one option that doesn't involve government, but we know that is hard to do on technical grounds alone... A group of commercial entities that work together to setup a system which strongly encourages others to follow particular practices does indeed need to worry about Matt Petach's list of statutes, and exercise extreme care in its processes less the result be more about some form of market control and less about common good management. Net result is that management of a common good without some form of government involvement quickly gets quite challenging. If we had truly global operational best practices for the Internet (ones that went through a fairly well-defined policy development process which included multiple operator forums from around the globe) then you might have a solid chance of producing output which avoided the various anti- competitive aspects, and yet were a reasonable basis for governments to then step up and indicate should be required for ISPs in their operations. It wouldn't take very many governments asking "How do I reduce SPAM and DDoS attacks?" and hearing back "Please require ISPs to adhere to this Best Common Operating Practice Foo-01" before it became common practice. FYI, /John
----- Original Message -----
From: "John Curran" <jcurran@arin.net>
On Mar 26, 2013, at 10:51 AM, Jay Ashworth <jra@baylink.com> wrote:
The problem here is, of course, one of externalities and the Common Good, hard sales to make in a business environment.
"Common Good" situations are readily dealt with, but generally not on a voluntary basis. You establish how the resource is to be managed, and then you put in place mechanisms to deal with enforcement. The problem is that en-force-ment contains "force", which is something that we really don't want anyone (or set of anyones) using except "governments" (which in our social constructs are the only ones supposed to be telling one party under penalty of force not to do something otherwise in its best interest.)
Basically, though there are lots of other things that are close.
The problem, of course, with asking governments for help is that the output often does not resemble anything related to the original problem statement and can make the situation worse...
Yup, a problem which is indeed perennial, and which we mentioned in an earlier set of exchanges.
If we had truly global operational best practices for the Internet (ones that went through a fairly well-defined policy development process which included multiple operator forums from around the globe) then you might have a solid chance of producing output which avoided the various anti- competitive aspects, and yet were a reasonable basis for governments to then step up and indicate should be required for ISPs in their operations. It wouldn't take very many governments asking "How do I reduce SPAM and DDoS attacks?" and hearing back "Please require ISPs to adhere to this Best Common Operating Practice Foo-01" before it became common practice.
Indeed, but I have an even better example of how that's already done, that is probably pertinent. The National Electric Code is assimilated law now, I think, in every state in the US. It is promulgated by the National Fire Protection Association, which is a standards organization originally started by insurors to reduce their exposure and expenses; by professional consensus, they have become, effectively, a lawmaking body. So they're not the government, they're subject-matter experts, technically competent to have opinions, and their opinions are assimilated into controlling law. Is BCP38 *not* well enough though out even for large and medium sized carriers to adopt as contractual language, much less for FCC or someone to impose upon them? If so, we should work on it further. If not, do carriers need to be threatened with its imposition to get them to adopt it contractually? Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 3/27/2013 9:23 AM, Jay Ashworth wrote:
Is BCP38 *not* well enough though out even for large and medium sized carriers to adopt as contractual language, much less for FCC or someone to impose upon them? If so, we should work on it further.
BCP38 could definitely use some work. It is correct as a general concept. It does not go into depth of the different available technologies and how they might be of use. For example, dhcp is nice, but it usually requires uRPF (sometimes with exceptions) depending on the vendor. If BGP filters are being applied, it is usually not hard to apply packet filtering according to the same route filters. Some NSPs use traditional ingress filtering, while others have uRPF enabled with exception lists. Some require that you send all networks, but set communities for networks you don't want routed yet allowed via uRPF (which usually means anyone connected to the same router as you will still route your way). It's also not a bad idea for an ISP to deploy EGRESS filters if they do not offer BGP Transit services. This way they are not depending on their transit providers to handle spoof protection and they cover their entire network regardless of last mile ingress filtering. This doesn't generally work well when doing transit services of any size due to the number of egress filter updates you'd have to issue, but it is great for the small/medium ISP. Jack
In message <515309EC.4070402@brightok.net>, Jack Bates writes:
On 3/27/2013 9:23 AM, Jay Ashworth wrote:
Is BCP38 *not* well enough though out even for large and medium sized carriers to adopt as contractual language, much less for FCC or someone to impose upon them? If so, we should work on it further.
BCP38 could definitely use some work. It is correct as a general concept. It does not go into depth of the different available technologies and how they might be of use. For example, dhcp is nice, but it usually requires uRPF (sometimes with exceptions) depending on the vendor. If BGP filters are being applied, it is usually not hard to apply packet filtering according to the same route filters. Some NSPs use traditional ingress filtering, while others have uRPF enabled with exception lists. Some require that you send all networks, but set communities for networks you don't want routed yet allowed via uRPF (which usually means anyone connected to the same router as you will still route your way).
Technologies change. Concepts rarely do. BCP38 is technology neutral.
It's also not a bad idea for an ISP to deploy EGRESS filters if they do not offer BGP Transit services. This way they are not depending on their transit providers to handle spoof protection and they cover their entire network regardless of last mile ingress filtering. This doesn't generally work well when doing transit services of any size due to the number of egress filter updates you'd have to issue, but it is great for the small/medium ISP.
EGRESS filters are just INGRESS filters applied a couple of hops later.
Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 3/27/2013 10:25 AM, Mark Andrews wrote:
Technologies change. Concepts rarely do. BCP38 is technology neutral. If we follow that, we should just state "Don't allow spoofed IP Addresses!" and leave it to the individual to figure it out. BCP38 leaves that premise by mentioning ingress filtering as well as mentioning some issues with DHCP. If nothing else, it should have an extensive appendix to point people to the correct documentation for implementation.
EGRESS filters are just INGRESS filters applied a couple of hops later.
They are not, and I can think of quite a few people who would stare blankly at you for making such a statement. Of course, I can think of plenty of people who we'd like to see implementing BCP38 concepts that would need you to define ingress and egress. Fact: Ignorance is abound on the Internet, even in the running of networks. If you want a solid change, we're going to have to educate people; especially those who are not on NANOG, don't know about the IETF, and have never heard of an RFC or BCP. Jack
On Wed, 27 Mar 2013 10:51:35 -0500, Jack Bates said:
They are not, and I can think of quite a few people who would stare blankly at you for making such a statement. Of course, I can think of plenty of people who we'd like to see implementing BCP38 concepts that would need you to define ingress and egress.
Of course, the fact they don't understand ingress and egress are *totally* unrelated to the fact they can't figure out how to deploy BCP38, correct?
----- Original Message -----
From: "Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>
On Wed, 27 Mar 2013 10:51:35 -0500, Jack Bates said:
They are not, and I can think of quite a few people who would stare blankly at you for making such a statement. Of course, I can think of plenty of people who we'd like to see implementing BCP38 concepts that would need you to define ingress and egress.
Of course, the fact they don't understand ingress and egress are *totally* unrelated to the fact they can't figure out how to deploy BCP38, correct?
Oh, Jeezus; do we need to start seeing geek licenses[1] before we'll turn up your BGP session or Transit link now? Have we really sunk that low?[2] Cheers, -- jra [1] Seriously; I think we need these; for escalating to Tier 3 support if nothing else.[3] [2] No, I don't actually want an answer to this; I'm depressed enough. [3] "Hello, Road Runner business support!" "Yes, my Geek License number is G 17135, and I need to speak to your backbone BGP coordinator." "I'll transfer you right now, sir." -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Wed, Mar 27, 2013 at 11:02 AM, Jack Bates <jbates@brightok.net> wrote:
It's also not a bad idea for an ISP to deploy EGRESS filters if they do not offer BGP Transit services.
Nor is it a bad idea for their upstream to inquire as to whether the downstream offers BGP transit services and apply INGRESS filters if they do not.
This way they are not depending on their transit providers to handle spoof protection and they cover their entire network regardless of last mile ingress filtering. This doesn't generally work well when doing transit services of any size due to the number of egress filter updates you'd have to issue, but it is great for the small/medium ISP.
Build a web page where a downstream can set the filters on his interface at his convenience. Apply some basic sanity checks against wide-open. Worry about small lies from a forensic after-the-fact perspective. This problem has a trivial technology-only solution. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 3/27/2013 10:40 AM, William Herrin wrote:
Build a web page where a downstream can set the filters on his interface at his convenience. Apply some basic sanity checks against wide-open. Worry about small lies from a forensic after-the-fact perspective. This problem has a trivial technology-only solution.
Well, that would definitely be easier than the RR updates I have to do. I'm not arguing that the process can't be done. The problem is, there are a number of networks that don't know it needs to be done and why, or they don't know how to do it. There are a number of networks that have no concept of scripting changes into their routers. Implementing BCP38 isn't a technology issue as much as an education issue. The BCP provides a brief methodology to accomplish its goals. It doesn't mention other methods or point to resources that an uneducated person may need. The problem might not be with BCP38. Perhaps it is as detailed as it needs to be from an IETF standpoint. However, it is not enough information to cultivate the changes we need. Jack
On (2013-03-27 11:05 -0500), Jack Bates wrote:
I'm not arguing that the process can't be done. The problem is, there are a number of networks that don't know it needs to be done and why, or they don't know how to do it. There are a number of networks that have no concept of scripting changes into their routers.
Exactly. If we target BCP38 at last-mile we have 0 hope to achieve sufficient coverage to make spoofing attacks less practical than HTTP GET from unspoofed address. I think we should educate tier2 operators who offer transit to tier3. It's most practical place for BCP38. tier1<->tier2 can't do it, strict IRR prefix-filtering is not practical. tier2<->tier3 can do it, it's practical to do strict BGP prefix-filter. If you are doing strict BGP prefix-filter, it's either very easy to generate ACL while at it or 0 work in say JunOS, as you can just use same prefix-list for firewall filter. Open recursors may have been discussion point pre-DNSSEC world, post DNSSEC world it's easy enough to find large RRs from arbitrary authorative server, that is, even if you'd close all open recursors problem would not go away. -- ++ytti
If you are doing strict BGP prefix-filter, it's either very easy to generate ACL while at it Yes and that is exactly what needs to become a habit for all the operators. We all do care what our neighbors advertise to us or what prefixes we accept from them. But only a few really do care whether that's actually what is leaving our neighbor's network.
It's a pity that rpf is not "on" by default for interfaces over which the ebgp session is configured. adam
On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky <adam.vitkovsky@swan.sk> wrote:
It's a pity that rpf is not "on" by default for interfaces over which the ebgp session is configured.
Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, "It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only)" I might have agreed with you. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Yes I see now I have worded it miserably :) What I got on my mind was an eBGP session to stub site /single homed customer. Now that I think about it I believe it could have been "on" by default on all the router interfaces and would have to be turned off manually(or automatically if mpls is enabled on the interface) for core interfaces and interfaces facing dual-homed sites. Anyways disabling urpf would than soon become a part of standard interface-config templates. So I guess no matter what tools we'd have it boils down to (and I don't want to use a word "laziness") maybe comfortability of operators. adam -----Original Message----- From: wherrin@gmail.com [mailto:wherrin@gmail.com] On Behalf Of William Herrin Sent: Thursday, March 28, 2013 2:43 PM To: Adam Vitkovsky Cc: Saku Ytti; nanog@nanog.org Subject: Re: BCP38 - Internet Death Penalty On Thu, Mar 28, 2013 at 8:20 AM, Adam Vitkovsky <adam.vitkovsky@swan.sk> wrote:
It's a pity that rpf is not "on" by default for interfaces over which the ebgp session is configured.
Hi Adam, Considering that's one of the key scenarios for which RPF is known to NOT WORK reliably, I would have to disagree with that statement. Folks running BGP expect to manipulate routes asymmetrically. If you had said, "It's a pity that RPF is not on by default over interfaces for which no routing protocol is configured (connected and static routes only)" I might have agreed with you. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Thu, Mar 28, 2013 at 10:51 AM, Adam Vitkovsky <adam.vitkovsky@swan.sk> wrote:
What I got on my mind was an eBGP session to stub site /single homed customer.
Hi Adam, "Single homed stub site" is not a configuration option in any BGP setup I'm aware of, so how would the router select RPF as the default for a single-homed stub site? On the other hand, a router can usually make a determination about "routing protocol is active on this interface." That's not true of a few BGP-only configurations, but it's true everywhere else in the network interior. Any interface where the routing is 100% static is by definition a single-homed stub. And for the purposes of this discussion, radius, tacacs and dhcp are not routing protocols; a radius-assigned route is static on the interface to which it is assigned. Hence RPF could safely enable itself by default there. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In a message written on Thu, Mar 28, 2013 at 11:39:45AM -0400, William Herrin wrote:
"Single homed stub site" is not a configuration option in any BGP setup I'm aware of, so how would the router select RPF as the default for a single-homed stub site?
I'm not sure if this is what the OP was talking about or not, but it reminded me of a feature I have wanted in the past. If you think about a simple multi-homing situation where a person has their own IP space, their own ASN, and connects to two providers they will announce all of their routes to both providers. They may in fact do prepending, or more specifics such that one provider is preferred, but to get full redundancy all of their blocks need to go to both providers. uRPF _strict_ only allows traffic where the active route is back out the interface. There are a number of cases where this won't be true for my simple scenario above (customer uses a depref community, one ISP is a transit customer of the other being used for multi-homing, customer has more than one link to the same ISP and uses prepending on one, etc). As a result, it can't be applied. uRPF _loose_ on the other hand only checks if a route is in the table, and with the table rapidly approaching all of the IP space in use that's denying less and less every day. The feature I would like is to set the _packet filter_ based on the _received routes_ over BGP. Actually, received routes post prefix list. Consider this syntax: neighbor 1.2.3.4 install-dynamic-filter Gig10/1/2 prefix-list customer-prefixes Anything that was received would go through the prefix-list customer-prefixes (probably the same list used to filter their announcements), and then get turned into a dynamic ACL applied to the inbound interface (Gig10/1/2 in this case). I suspect such a feature would allow 99.99% of the BGP speakers to be "RPF" filtered in a meaningful way, automatically, where uRPF strict is not usable today. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Once upon a time, Leo Bicknell <bicknell@ufp.org> said:
The feature I would like is to set the _packet filter_ based on the _received routes_ over BGP.
On JUNOS, you can use routing-options { forwarding-table { unicast-reverse-path feasible-paths; } } to get that behavior (although it is a global option, not per-interface, I don't think there's any harm in using it).
Actually, received routes post prefix list. Consider this syntax:
neighbor 1.2.3.4 install-dynamic-filter Gig10/1/2 prefix-list customer-prefixes
Anything that was received would go through the prefix-list customer-prefixes (probably the same list used to filter their announcements), and then get turned into a dynamic ACL applied to the inbound interface (Gig10/1/2 in this case).
JUNOS does that as well. You can use the same prefix-list in both a BGP policy filter and a firewall filter. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Thu, Mar 28, 2013 at 12:19 PM, Leo Bicknell <bicknell@ufp.org> wrote:
If you think about a simple multi-homing situation where a person has their own IP space, their own ASN, and connects to two providers they will announce all of their routes to both providers.
The feature I would like is to set the _packet filter_ based on the _received routes_ over BGP. Actually, received routes post prefix list.
Hi Leo, Since you've configured a prefix list to specify what BGP routes you're willing to accept from the simple multihomed customer (you have, right?) why set a source filter from the same data instead of trying to build it from routing table guesswork? Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
In a message written on Thu, Mar 28, 2013 at 01:10:53PM -0400, William Herrin wrote:
Since you've configured a prefix list to specify what BGP routes you're willing to accept from the simple multihomed customer (you have, right?) why set a source filter from the same data instead of trying to build it from routing table guesswork?
In the simplest case I described (user has for instance one netblock) the packet filter will match the routing filter, and doing what you described would not be a huge extra burden. Howver, it is still a burden, it's writing everything twice (prefix list plus ACL), and it's making configs longer and less readable. But the real power here comes by applying this filter further up the food chain. Consider peering with a regional entity at an IX. Most people don't prefix filter there (and we could have a lively argument about the practicality of that), so the prefix list might be something like: deny my_prefix/foo le 32 permit 0.0.0.0/0 le 24 With a max-prefix of 100. That doesn't turn into a useful packet filter for the peer, but using my method the peer could be RPF filtered based on what they send, automatically. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Thu, Mar 28, 2013 at 1:58 PM, Leo Bicknell <bicknell@ufp.org> wrote:
But the real power here comes by applying this filter further up the food chain. Consider peering with a regional entity at an IX. Most [...]
That doesn't turn into a useful packet filter for the peer, but using my method the peer could be RPF filtered based on what they send, automatically.
Hi Leo, Be nice if that were correct. If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. And if your customer sets a BGP community defined to mean "don't advertise to peers" then you won't advertise it to the peer. Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table. Which means that your peer can't take the received routes from your BGP session as gospel for what source addresses to expect. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. And if your customer sets a BGP community defined to mean "don't advertise to peers" then you won't advertise it to the peer. Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table.
Yes asymmetric routing would kill the update-based urpf unless there would be an informational urpf NRLI we could use for these purposes adam
On Fri, Mar 29, 2013 at 8:36 AM, Adam Vitkovsky <adam.vitkovsky@swan.sk> wrote:
If the best route you pick for the customer's advertisement goes to your upstream instead of your customer, you won't advertise it to your peer. And if your customer sets a BGP community defined to mean "don't advertise to peers" then you won't advertise it to the peer. Yet they may well transmit packets to you for which delivery to that peer is directed by your routing table.
Yes asymmetric routing would kill the update-based urpf unless there would be an informational urpf NRLI we could use for these purposes
Hi Adam, If we go down that path, let's not overload BGP. A distinct source address advisory protocol could have highly desirable auto-aggregation and update rate characteristics versus BGP. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Mar 28, 2013, at 7:20 PM, Adam Vitkovsky wrote:
It's a pity that rpf is not "on" by default for interfaces over which the ebgp session is configured.
As has been noted here and on cisco-nsp several times, unfortunately, there are too many instances in which enabling uRPF automagically would break things and thus overwhelm vendor support desks for network vendors to do this. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Mar 27, 2013, at 10:23 AM, Jay Ashworth <jra@baylink.com> wrote:
Indeed, but I have an even better example of how that's already done, that is probably pertinent.
The National Electric Code is assimilated law now, I think, in every state in the US. It is promulgated by the National Fire Protection Association, which is a standards organization originally started by insurors to reduce their exposure and expenses; by professional consensus, they have become, effectively, a lawmaking body.
So they're not the government, they're subject-matter experts, technically competent to have opinions, and their opinions are assimilated into controlling law.
Indeed... a perfect example of industry self-regulation supplemented by a mandatory legal framework referencing the best practice documents.
Is BCP38 *not* well enough though out even for large and medium sized carriers to adopt as contractual language, ...
You're back to discussing voluntary mechanisms in the above, but your example is a case where compliance is due to legislation at both federal and state levels.
much less for FCC or someone to impose upon them? If so, we should work on it further.
Umm... How many North American ISP's/datacenters/web hosting firms were aware of the BCP 38 development as it was on-going, and participated in some manner in its review? The IETF is a wonderful organization, but it is not exactly overflowing with representation from the service provider community. Also, given that you really need these practices picked up on a global basis, repeat the above question with "Global" rather than North American... If you actually want to see certain technical practices made mandatory for Internet service providers globally, then you need a development process for those practices which fairly robust to insure that the practices are equally germane and reasonable to many different service providers in many different parts of the world. It's actually relatively easy to get governments to require compliance with accepted technical practices for the Internet, the problem has been we've never taken the effort to produce best practices with sufficient rigor than any given government can know that it has the necessary backing (of many of the service providers in its domain) needed to actually require compliance. (With regard to the FCC, there is some question as to whether or not their mandate would allow establishing required practices for ISPs... To the extent that VoIP traffic is being carried, this is far more likely to be possible, and hence folks should be aware of various activities such as the CSRIC "Communications Security, Reliability and Interoperability Council", which develops recommendations that could effectively become requirements on Internet Service Providers in some contexts. <http://www.fcc.gov/encyclopedia/communications-security-reliability-and-interoperability-council-iii> Noe that the problem with this sort of approach is that having dozens of countries all developing their own specific technical best practices is most likely to cumulatively interact in ways impossible to comply with... Hence, the need for clear global technical best practices, through which countries with a particular desire to "improve the state of the Internet" can channel their legislative desires...) FYI, /John
In message <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net>, John Curran writes:
On Mar 27, 2013, at 10:23 AM, Jay Ashworth <jra@baylink.com> wrote:
Indeed, but I have an even better example of how that's already done, that is probably pertinent.
The National Electric Code is assimilated law now, I think, in every state in the US. It is promulgated by the National Fire Protection Association, which is a standards organization originally started by insurors to reduce their exposure and expenses; by professional consensus, they have become, effectively, a lawmaking body.
So they're not the government, they're subject-matter experts, technically competent to have opinions, and their opinions are assimilated into controlling law.
Indeed... a perfect example of industry self-regulation supplemented by a mandatory legal framework referencing the best practice documents.
Is BCP38 *not* well enough though out even for large and medium sized carriers to adopt as contractual language, ...
You're back to discussing voluntary mechanisms in the above, but your example is a case where compliance is due to legislation at both federal and state levels.
much less for FCC or someone to impose upon them? If so, we should work on it further.
Umm... How many North American ISP's/datacenters/web hosting firms were aware of the BCP 38 development as it was on-going, and participated in some manner in its review? The IETF is a wonderful organization, but it is not exactly overflowing with representation from the service provider community. Also, given that you really need these practices picked up on a global basis, repeat the above question with "Global" rather than North American...
I'd say enough were aware. :-) 8. Acknowledgments The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions.
If you actually want to see certain technical practices made mandatory for Internet service providers globally, then you need a development process for those practices which fairly robust to insure that the practices are equally germane and reasonable to many different service providers in many different parts of the world. It's actually relatively easy to get governments to require compliance with accepted technical practices for the Internet, the problem has been we've never taken the effort to produce best practices with sufficient rigor than any given government can know that it has the necessary backing (of many of the service providers in its domain) needed to actually require compliance.
(With regard to the FCC, there is some question as to whether or not their mandate would allow establishing required practices for ISPs... To the extent that VoIP traffic is being carried, this is far more likely to be possible, and hence folks should be aware of various activities such as the CSRIC "Communications Security, Reliability and Interoperability Council", which develops recommendations that could effectively become requirements on Internet Service Providers in some contexts. <http://www.fcc.gov/encyclopedia/communications-security-reliability-and-i nteroperability-council-iii> Noe that the problem with this sort of approach is that having dozens of countries all developing their own specific technical best practices is most likely to cumulatively interact in ways impossible to comply with... Hence, the need for clear global technical best practices, through which countries with a particular desire to "improve the state of the Internet" can channel their legislative desires...)
FYI, /John
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Mar 27, 2013 at 1:54 PM, Mark Andrews <marka@isc.org> wrote:
In message <8DA1853CE466B041B104C1CAEE00B3748FA4E8A0@CHAXCH01.corp.arin.net>, John Curran writes:
Umm... How many North American ISP's/datacenters/web hosting firms were aware of the BCP 38 development as it was on-going, and participated in some manner in its review? The IETF is a wonderful organization, but it is not exactly overflowing with representation from the service provider community. Also, given that you really need these practices picked up on a global basis, repeat the above question with "Global" rather than North American...
I'd say enough were aware. :-)
8. Acknowledgments
The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions.
I think the core group of backbone engineers, and to some degree others at the periphery of the DFZ, understand the issues. And yes, I think it gets back to an education problem on "why you should care". As I mentioned on another list earlier today, let's face it -- this is going to require a large-scale, very public, and probably multi-year education & awareness effort (as if 13+ years isn't enough already!). How long did it take to get some movement on open SMTP relays? You get the idea. Some people are going to have to step and add a few thousand more frequent flier miles and get out to various geographic constituencies, at various events, and start talking about this. And we need a lot more people on board. Nation & international campaigns, etc. And there may even be some stick approaches to accompany the carrot, but some awareness is going to have to happen. Sing it from the mountain tops. - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
On Wed, 27 Mar 2013 14:19:05 -0700, Paul Ferguson said:
And there may even be some stick approaches to accompany the carrot, but some awareness is going to have to happen.
Sing it from the mountain tops.
http://www.sans.org/dosstep/roadmap.php Note the date. Note the list of recommendations. Note the flat spot on my forehead from continual pounding against vertical surfaces. :)
On Wed, Mar 27, 2013 at 4:19 PM, Paul Ferguson <fergdawgster@gmail.com>wrote:
Some people are going to have to step and add a few thousand more frequent flier miles and get out to various geographic constituencies, at various events, and start talking about this. And we need a lot more people on board. Nation & international campaigns, etc.
Agree 100%. One thing that I will mention is a subtle issue that needs more thought. I think one of the challenges for this is answering the question of 'How does this make it better for my network on day one?' . Well , it doesn't for the majority of impact that people may be seeing. For example - Let us say someone is not currently running a fully BCP38-compliant network (shame on them, blah blah). They can do the remaining work to fix this in XXX hours at YYY cost. The issue for them may be that they are the *destination* of the attacks that leverage non-BCP38 compliant networks. So even after investing XXX hours and YYY dollars it doesn't 'cure' the majority of the problems for them related to spoofing. So any spend on this is not a 'fix' as much as it is a 'fix for others'. (which certainly still needs to be done , don't get me wrong!) Spoofing remains a problem until *everyone* gets it done or there is enough motivation to get it done without benefit to your own network. If Network_Zed is the last to go BCP38-complaint in 2023 , then the rest of the internet is still vulnerable to the nasty items that can take place from the Network_Zed network until that time. Accepting that I think we need to find ways to make it where it stays on the radar - as has been suggested via walls of shame, RIR pressure, etc. Perhaps 'spoofing fees' etc ? I hate to have an approach of 'fix this or I will hit you with this stick!' - but this has got to stop.. OK, back to my hole watching all the presumably spoofed incoming traffic that happens to be on udp/53 and looking for ANY? isc.org :-) -- jason
In message <CAA=cXfrO3c8=UYZDExpiYsEhFJDup=gUMvO+d=U34-DjW0AgdA@mail.gmail.com> , Jason Ackley writes:
On Wed, Mar 27, 2013 at 4:19 PM, Paul Ferguson <fergdawgster@gmail.com>wrote:
Some people are going to have to step and add a few thousand more frequent flier miles and get out to various geographic constituencies, at various events, and start talking about this. And we need a lot more people on board. Nation & international campaigns, etc.
Agree 100%.
One thing that I will mention is a subtle issue that needs more thought. I think one of the challenges for this is answering the question of 'How does this make it better for my network on day one?' . Well , it doesn't for the majority of impact that people may be seeing.
Firstly you protect your customers from your other customer machines that are compromised. Secondly you reduce your legal liability. Third you can use it to improve the reputation of your network.
For example - Let us say someone is not currently running a fully BCP38-compliant network (shame on them, blah blah). They can do the remaining work to fix this in XXX hours at YYY cost.
The issue for them may be that they are the *destination* of the attacks that leverage non-BCP38 compliant networks. So even after investing XXX hours and YYY dollars it doesn't 'cure' the majority of the problems for them related to spoofing. So any spend on this is not a 'fix' as much as it is a 'fix for others'. (which certainly still needs to be done , don't get me wrong!)
Spoofing remains a problem until *everyone* gets it done or there is enough motivation to get it done without benefit to your own network.
It's a reducing problem as more networks filter.
If Network_Zed is the last to go BCP38-complaint in 2023 , then the rest of the internet is still vulnerable to the nasty items that can take place from the Network_Zed network until that time.
Or the rest of the world can just shun Network_Zed.
Accepting that I think we need to find ways to make it where it stays on the radar - as has been suggested via walls of shame, RIR pressure, etc. Perhaps 'spoofing fees' etc ?
I hate to have an approach of 'fix this or I will hit you with this stick!' - but this has got to stop..
OK, back to my hole watching all the presumably spoofed incoming traffic that happens to be on udp/53 and looking for ANY? isc.org :-)
Which you can chase back to offending sources and complain to them about. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Mar 28, 2013, at 6:01 AM, Mark Andrews wrote:
Secondly you reduce your legal liability.
IANAL, but this has yet to be proven, AFAIK. One approach that hasn't been tried, to my knowledge, is educating the insurance companies about how they can potentially reduce *their* liability for payouts by requiring that real, actionable security BCPs such as BCP38/84, running closed resolvers, implementing iACLs, et. al. are implemented by those they insure. Does anyone have insight into examples of how insurance policies have been paid out as a result of losses stemming from availability-related security events? Another approach is educating the 'risk management' and 'business continuity' communities about the risks and how to mitigate them, and how doing so enhances business continuity. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
On Wed, Mar 27, 2013 at 9:18 PM, Dobbins, Roland <rdobbins@arbor.net> wrote:
On Mar 28, 2013, at 6:01 AM, Mark Andrews wrote:
Secondly you reduce your legal liability.
IANAL, but this has yet to be proven, AFAIK.
One approach that hasn't been tried, to my knowledge, is educating the insurance companies about how they can potentially reduce *their* liability for payouts by requiring that real, actionable security BCPs such as BCP38/84, running closed resolvers, implementing iACLs, et. al. are implemented by those they insure.
Does anyone have insight into examples of how insurance policies have been paid out as a result of losses stemming from availability-related security events?
Another approach is educating the 'risk management' and 'business continuity' communities about the risks and how to mitigate them, and how doing so enhances business continuity.
Funny you should mention it. Actually, I do know someone who is in the "digital insurance" (for lack of a better term) business, and although I just met them a few weeks ago, somehow I get the feeling that it is a growth industry. I'm semi --> :-) - ferg -- "Fergie", a.k.a. Paul Ferguson fergdawgster(at)gmail.com
On Mar 28, 2013, at 11:42 AM, Paul Ferguson wrote:
Actually, I do know someone who is in the "digital insurance" (for lack of a better term) business, and although I just met them a few weeks ago, somehow I get the feeling that it is a growth industry.
I think this concept applies to traditional insurers, as well as newer tech-focused insurers, as they're all potentially on the hook for payouts due to business-disrupting events of all sorts - including DDoS-induced losses. Perhaps your friend can provide some insight and/or pointers on this general topic? Ideally, it would be a Good Thing to engage with the various actuarial organizations in order to brief them at properly-calibrated level of detail in order to educate them on this topic, followed by engagement with specific insurers. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
I am afraid you are right. It is going to cost us money and time, but unfortunately I do not see another way out. /as On 3/27/13 6:19 PM, Paul Ferguson wrote:
As I mentioned on another list earlier today, let's face it -- this is going to require a large-scale, very public, and probably multi-year education & awareness effort (as if 13+ years isn't enough already!).
----- Original Message -----
From: "Paul Ferguson" <fergdawgster@gmail.com>
As I mentioned on another list earlier today, let's face it -- this is going to require a large-scale, very public, and probably multi-year education & awareness effort (as if 13+ years isn't enough already!).
How long did it take to get some movement on open SMTP relays? You get the idea.
Some people are going to have to step and add a few thousand more frequent flier miles and get out to various geographic constituencies, at various events, and start talking about this. And we need a lot more people on board. Nation & international campaigns, etc.
And there may even be some stick approaches to accompany the carrot, but some awareness is going to have to happen.
Sing it from the mountain tops.
Alain has registered bcp38.info, et al; I'll be talking to him off-list about slapping up a CMS somewhere to pour some content into, and we'll boil it down for everyone, in the immortal words of C.J. Cregg: "...like they are five-year olds... and [we'll try to do it] like we are not." Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On Mar 27, 2013, at 4:54 PM, Mark Andrews <marka@isc.org> wrote:
Umm... How many North American ISP's/datacenters/web hosting firms were aware of the BCP 38 development as it was on-going, and participated in some manner in its review? ...
I'd say enough were aware. :-)
8. Acknowledgments
The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions.
Mark - That's plenty of consideration for voluntary efforts (which is what we've tried to date in various forums with rather limited success...) Whether that's sufficient notice and consideration on which to base mandatory requirements from a public policy perspective is not clear. Frankly, I would suggest that NANOG document a best common operating practice (BCOP) based on BCP38 (written at a somewhat higher level which describes what types of connections ingress filtering it applies to, e.g. consumer edge, business, transit, etc.; whether it should be just a customer default or an absolute requirement, etc.), and then holding an approval process to make the result a NANOG BCOP... <http://www.nanog.org/meetings/nanog57/presentations/Monday/mon.general.Grundemann.BCOP.12.pdf> If this were done in a fairly formal manner, the result would be closer to the prior example (National Fire Protection Association code) and would far more convincing both in aiding governments to pick up this cause in the region, as well as encouraging similar efforts elsewhere. FYI, /John
I think the media fire about this will enlighten many c level executives. After that, it's a matter of them saying "go do this". You can't get any traction if there isn't a perceived issue, from what I've seen anyways. I still think the ipv4 to 6 transition will require media outlets running special coverage on the end of the Internet because we broke it by not addressing issues. I've shouted from roof tops on various occasions, only to hear months later about how we should have seen something coming. Get CNN to run Nanog has a solution and watch the hordes gather. People slow down on the freeway to see an accident, they'll slow down long enough to see what's happened and drive off. When their house is on fire, it's a completely different story.
From my Android phone on T-Mobile. The first nationwide 4G network.
-------- Original message -------- From: John Curran <jcurran@arin.net> Date: 03/27/2013 3:33 PM (GMT-08:00) To: Mark Andrews <marka@isc.org> Cc: NANOG <nanog@nanog.org> Subject: Re: BCP38 - Internet Death Penalty On Mar 27, 2013, at 4:54 PM, Mark Andrews <marka@isc.org> wrote:
Umm... How many North American ISP's/datacenters/web hosting firms were aware of the BCP 38 development as it was on-going, and participated in some manner in its review? ...
I'd say enough were aware. :-)
8. Acknowledgments
The North American Network Operators Group (NANOG) [5] group as a whole deserves special credit for openly discussing these issues and actively seeking possible solutions. Also, thanks to Justin Newton [Priori Networks] and Steve Bielagus [IronBridge Networks]. for their comments and contributions.
Mark - That's plenty of consideration for voluntary efforts (which is what we've tried to date in various forums with rather limited success...) Whether that's sufficient notice and consideration on which to base mandatory requirements from a public policy perspective is not clear. Frankly, I would suggest that NANOG document a best common operating practice (BCOP) based on BCP38 (written at a somewhat higher level which describes what types of connections ingress filtering it applies to, e.g. consumer edge, business, transit, etc.; whether it should be just a customer default or an absolute requirement, etc.), and then holding an approval process to make the result a NANOG BCOP... <http://www.nanog.org/meetings/nanog57/presentations/Monday/mon.general.Grundemann.BCOP.12.pdf> If this were done in a fairly formal manner, the result would be closer to the prior example (National Fire Protection Association code) and would far more convincing both in aiding governments to pick up this cause in the region, as well as encouraging similar efforts elsewhere. FYI, /John
I think this would be a good time for me to quote the best thing I've ever read on NANOG: If you give people the means to hurt you, and they do it, and you take no action except to continue giving them the means to hurt you, and they take no action except to keep hurting you, then one of the ways you can describe the situation is "it isn't scaling well". --- Paul Vixie ---rsk
participants (22)
-
Adam Vitkovsky -
Arturo Servin -
bmanning＠vacation.karoshi.com -
Chris Adams -
Darius Jahandarie -
Dobbins, Roland -
Jack Bates -
Jared Mauch -
Jason Ackley -
Jay Ashworth -
Jimmy Hess -
John Curran -
Leo Bicknell -
Mark Andrews -
Matthew Petach -
Mikael Abrahamsson -
Paul Ferguson -
Rich Kulawiec -
Saku Ytti -
Valdis.Kletnieks＠vt.edu -
Warren Bailey -
William Herrin