At 08:27 PM 8/4/2002 -0400, Sean Donelan wrote:
On Sun, 4 Aug 2002, Dave Crocker wrote: There is a difference between technical/operational matters and policy matters. I respectfully disagree this can be treated as a technical problem.
Yes, it's essential to be clear about technical spec. vs. policy spec, although they seem to have some overlap. Maybe a lot. But no, that does not make them the same. However the list of questions you asked, in the note I was responding to, looked like technical choices. My assumption was that the "policy" issue was in choosing between technologies. I consider the IETF Best Current Practises label as intended specifically for guidance in operations matters. Hence the suggestion to consider it.
What group is the best forum for developing consensus views on Internet operation policy issues?
In between pure tech specs and abstract policy discussion there is technically based consideration of tradeoffs, etc., for technical alternatives. That's not something to leave to purely policy folk and my sense is that the IETF venue can work for such discussion.
One of the Mr. Clarke's complaints in his speech was there is no group the government can go to find out what the consensus view of Internet operators is. IETF doesn't appear to want to take on that role.
Hmmm. As soon as a policy becomes multi-operator, I'll bet it starts looking like a technical spec. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
I consider the IETF Best Current Practises label as intended specifically for guidance in operations matters. Hence the suggestion to consider it.
You may be in the minority in you opinion here.
One of the Mr. Clarke's complaints in his speech was there is no group the government can go to find out what the consensus view of Internet operators is. IETF doesn't appear to want to take on that role.
Hmmm. As soon as a policy becomes multi-operator, I'll bet it starts looking like a technical spec.
To avoid RICO?
Dave Crocker <mailto:dave@tribalwise.com>
--bill
This is becoming ridiculous. Our rights have been eroded enough in the course of fighting this "war on terrorism" ... Now they're coming after our packets. While I'm certainly in favor of anything edge providers can do to eliminate denial of service attacks based on source-routing, I certainly don't want anything further. If this trend isn't checked we're going to see efforts made to (as an example) curb the use of encrption protocols, or whole countries being filtered, and someone, somewhere that I didn't elect will be deciding what traffic I can or cannot pass. Maybe this is an exaggeration of the possibilities, but now that all the pseudo-security-experts have jumped on the bandwagon, there is an overwhelming level of hysteria being generated on "cyber attacks" and bog knows what else with a push to limit what can and cannot be done with the net. The IETF/IAB/ISOC and other bodies historically have been all the leadership the net needs, let's not be so quick to hand over the reigns to people who don't have the best interest of the internet itself in mind. Len On Mon, Aug 05, 2002 at 11:37:31AM +0000, bmanning@karoshi.com wrote:
I consider the IETF Best Current Practises label as intended specifically for guidance in operations matters. Hence the suggestion to consider it.
You may be in the minority in you opinion here.
One of the Mr. Clarke's complaints in his speech was there is no group the government can go to find out what the consensus view of Internet operators is. IETF doesn't appear to want to take on that role.
Hmmm. As soon as a policy becomes multi-operator, I'll bet it starts looking like a technical spec.
To avoid RICO?
Dave Crocker <mailto:dave@tribalwise.com>
--bill
<snip>
our packets. While I'm certainly in favor of anything edge providers can do to eliminate denial of service attacks based on source-routing, I certainly don't want anything further. <snip>
denial of service based upon source routing? I hadn't heard of any denial of service attacks of that sort. Disabling source-routing is like filtering icmp, sure you might block a few abuses, but more often than not, you are throwing out legitimate traffic.
Of course, I mean denial of service attacks using source routing, i.e. made possible by use of same. I guess I need to be semantically perfect and I don't always have a wonderful command of the english language it seems, but please grant that I'm not stupid. Thanks On Mon, Aug 05, 2002 at 10:51:45AM -0400, bdragon@gweep.net wrote: [snip]
denial of service based upon source routing? I hadn't heard of any denial of service attacks of that sort.
Disabling source-routing is like filtering icmp, sure you might block a few abuses, but more often than not, you are throwing out legitimate traffic.
Of course, I mean denial of service attacks using source routing, i.e. made possible by use of same. I guess I need to be semantically perfect and I don't always have a wonderful command of the english language it seems, but please grant that I'm not stupid.
Thanks
I understood what you were saying, I just was not aware of any attacks which used source routing. I was, and am, asking for clarification on that. Is it just a simple "overwhelm the router with whatever ip options I can" type attack? Or are you aware of people actively using source routing to get around weak defenses? Something else?
On Mon, 5 Aug 2002 12:00:20 -0400 (EDT) bdragon@gweep.net wrote:
I understood what you were saying, I just was not aware of any attacks which used source routing.
umm, haven't you ever heard of smurf? richard -- Richard Welty rwelty@averillpark.net Averill Park Networking 518-573-7592 Unix, Linux, IP Network Engineering, Security
Thus spake <bdragon@gweep.net>
<snip>
our packets. While I'm certainly in favor of anything edge providers can do to eliminate denial of service attacks based on source-routing, I certainly don't want anything further. <snip>
denial of service based upon source routing? I hadn't heard of any denial of service attacks of that sort.
Disabling source-routing is like filtering icmp, sure you might block a few abuses, but more often than not, you are throwing out legitimate traffic.
I can't come up with any legitimate reason to use source-routed packets today. If your routers even support them, they probably consume orders of magnitude more processing power than normal packets; that is enough reason to disable source-routing, not to mention the security implications. S
On Mon, 05 Aug 2002 09:03:03 EDT, Len Rose <len@netsys.com> said:
If this trend isn't checked we're going to see efforts made to (as an example) curb the use of encrption protocols, or whole countries being filtered, and someone, somewhere that I didn't elect will be deciding what traffic I can or cannot pass.
I wasn't aware that "we're going to" was a past-tense conjugation.
On Mon, Aug 05, 2002 at 09:03:03AM -0400, Len Rose wrote:
The IETF/IAB/ISOC and other bodies historically have been all the leadership the net needs, let's not be so quick to hand over the reigns to people who don't have the best interest of the internet itself in mind.
The above entities don't really have much to say about "leadership" except in a very general way. Much like open-source programmers operate, theres a certain amount of guidance by those who have the patience, the ego or the visibility to direct a wildly diverse group of people who want to contribute. These organizations generally work because they are mostly composed of reasonable people who want reasonable outcomes. Those who aren't reasonable are hopefully shouted down. The U.S. government would prefer to deal with something a little more concrete than this. I'm rather frightened that it will create the organization it wants to deal with and impose it upon us.
Len
-- Jeff Haas NextHop Technologies
"You know, there's quite a difference between source routing and IP spoofing .." As true as this statement is, the two walk hand in hand (especially during certain attacks). If I send an attack from a spoofed address to a victim, I can turn blue in the face waiting for a response that will never come. If I spoof an address and use loose source routing I can force the response to return right through my network. Also loose source routing can be used for Man-in-the-middle attacks by using a loose source route you can force all traffic to pass through the attackers network. Strict source routing does not benefit an attacker, but as I said loose source routing does.
On Sun, 4 Aug 2002, Dave Crocker wrote:
However the list of questions you asked, in the note I was responding to, looked like technical choices. My assumption was that the "policy" issue was in choosing between technologies.
That's actually part of the problem. What happens when you put a bunch of technical people in a room and ask them to solve a problem? You get technical solutions without consideration of what the policy should be. In this case I think we've got the technical version of Mr. Smith Goes to Washington. Technical people who mean well, but don't understand the rules are different inside the washington beltway. I put myself in the same catagory. Mr. Clarke and crew are coming up with a national policy. Technical folks gave lots of technical suggestions. A firewall is a technical tool, but a firewall may not be a good policy. If firewalls were the answer to a national security policy, China would have one of the most secure networks in the world.
I consider the IETF Best Current Practises label as intended specifically for guidance in operations matters. Hence the suggestion to consider it.
IETF BCPs are great guidance for operational matters, they are a lousy basis for regulations or enforcement. Whether you are writing a new TCP/IP stack, or a contract with a vendor, just referencing the RFCs isn't sufficient to get a working system. This is a good thing. OSI tried to cover everything so there is no doubt products from different vendors would work together. IETF just tries to cover enough, and leaves the rest up to interoperability "goodwill" between implementors. But when that goodwill is missing, the IETF and BCPs run into problems.
In between pure tech specs and abstract policy discussion there is technically based consideration of tradeoffs, etc., for technical alternatives. That's not something to leave to purely policy folk and my sense is that the IETF venue can work for such discussion.
Maybe, but IETF has slowly been moving away from anything that doesn't involve running code, bits and photons for a few years. There also seems to be fewer network operators and more vendors at IETF.
participants (10)
-
bdragon＠gweep.net -
bmanning＠karoshi.com -
Dave Crocker -
Gerardo A. Gregory -
Jeffrey Haas -
Len Rose -
Richard Welty -
Sean Donelan -
Stephen Sprunk -
Valdis.Kletnieks＠vt.edu