On Sat, 12 Feb 2000 07:18:59 -0800, Randy Bush wrote:

...

it is a necessary evil that we settle this ourselves. because if we don't take care of our own business, someone's going to step in and do it for us, and we won't like it.

as the problem is quite technical, and the ingress filtering is a small panacea not a fix, not bloody likely

While I agree that it's exceedingly unlikely that they'd actually solve the problem, I've yet to see a politician who won't try to do *something*, even if it would be ineffectual or counterproductive. A "Protection of E-Commerce" bill is entirely too plausible - just imagine how many politicians would love to run "I saved the Internet" ads during their next campaign.

If one reads the media as everyone does the government is already attempting to do that with a national infrastructure privacy protection network. I think if this happens every business here is jeopardy of losing control of "Their Network", and it would serve those that want to spy and use the network for intelligence gathering as well. The suggestion that using the SAR to approach the broken networks was A very positive step and should be done, I think "collectively", this can be done with whatever "collective legal maneuvering" and peer pressure. Creating A SAR for like incidents is an excellent idea. I don't much care if you are an ISP or NSP as a group of networks that share common network fabric it is an unspoken duty to work with what keeps the networking going and not your sense of greed or back room politics. The backlash to this if you do not fall in line you will find it difficult to do business online because like any other business " We Can And Will Refuse the Right of Service". The problem with Sun RPC can be addressed with A "Collective Complaint" for lack of responsible service so that funding can be made available to fix the issue, like any other business there has to be sufficient cause to assign funding to a new product, with all the collective knowledge that is here this process can be done in a relatively short time using the best expertise that is here to show the problem and how to correct the errors in the code and at the same time maintain its functionality, correctly and reliably. I think Cisco already got the point since they are customer centric in resolving problems that are injurious to their business interests and reputation. There are brilliant people here who have worked hard to write RFC's and it is a shame when they drew their conclusions some time back, knowing that this would evolve to an eventual happening, that no one listened. It is a bitter lesson that will spawn much destruction. Lets not repeat it. Sam Thomas wrote:

On Fri, Feb 11, 2000 at 10:35:57PM -0500, Paul Ferguson wrote:

...

I hate to ask this, but can't bite my lip, given the fact that people are throwing lawyers at this stuff now.

it is a necessary evil that we settle this ourselves. because if we don't take care of our own business, someone's going to step in and do it for us, and we won't like it. imagine, if you will, a branch of the UN making internet policy in the form of international law. this should be incentive enough.

...

Is it within the realm of possibility that ISP's will start to craft SLA's, peering & transit agreements, to include who is responsible for ingress filtering?

I would think so.

IMHO, ISP's should take full positive control of all the traffic they allow on their network, their route advertisements, and their responsiveness to peers/customers. ultimately, when asked who is responsible for the packets on my network, the answer is "me". it is obscene to think that folks would write contracts in such a way as to avoid their implicit responsibility for their own networks. like I said above, if we do not take responsibility for our own networks, someone else will, and we won't like the results.

...

Also, if so, do you think that this would technically be effcient, given that the filters would actually be applied?

once folks get it through their thick skulls that this is something that needed to happen yesteryear and give harsh stares to their vendors' geeks, I'm sure someone will figure out a way to make it technically efficient. <cliche>necessity is the mother of invention.</cliche> let the word get out that there is an immediate need for devices that can filter at very high capacity line speeds, and someone will figure out how to make it work. even engineers are suceptible to greed. :-)

right now, this is probably not-so-feasable.

-- Sam Thomas Geek Mercenary

-- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

Alex - Have any of your peers complained? I can't imagine anyone caring (strenuously) if a peer applies filters to bogus addresses. Every peer I have dealt with for a matter like that, while it may take time to get to the right people, have made no complaints about us doing the filtering or even adding the filtering (on a temporary basis) to their own border/core routers. Deepak Jain AiNET On Sat, 12 Feb 2000, Alex Bligh wrote:

Paul,

...

Is it within the realm of possibility that ISP's will start to craft SLA's, peering & transit agreements, to include who is responsible for ingress filtering?

It is in the realm of fact. Our (*) agreements with our customers specifically prevent them from sending packets with source IP addresses outside agreed ranges, and have done for close on 2 years. Our peering agreements (and this is in the LINX template agreement too, which shares the same author) have provisions which make the peer responsible for ensuring they aren't sending spoofed source addresses.

I know several other people do this too. We have not yet tested enforceability, though we have used the existence of the clause to justify unilateral application of filters in one or two occurrences.

(*) 'Our' in this context means GX Networks a.k.a. Concentric Europe. I am unfamiliar with the US situation.

-- Alex Bligh VP Core Network, Concentric Network Corporation (formerly GX Networks, Xara Networks)