Not liking the solution is not a reason to abandon the problem. This sounds like "I don't like eating right and exercising, so keeping my weight under control is the wrong question"
All protocols rely on certain assumptions of what the fields mean - when you send them and when you receive them. Analyzing a protocol for vulnerabilities starts with identifying what happens if those assumptions are broken. (Like the assumption in IP that the source address is the node
Two points. First, I did NOT say, "I don't like this." What I did say was technically precise, and, I think, perfectly clear. It's telling that the folks defending BGPSEC must immediately redirect the discussion into the side alleys of who "likes" what, and "rtfm," and "you can do this only it will cost you, so don't do that even though it's probably the right thing to do," straw man arguments, etc. Second, if you said, "If I eat one carrot a day, and I still can't keep my weight under control," you have some other problem than not being able to control your eating, and you might want to check into it a bit with a doctor. BGPSEC can eat one carrot a day and it's still too fat, IMHO -- it has a very high cost for some gain, counterbalanced by a slate of new risks and problems that must be solved. Again -- the ROI just isn't there. that
sent the packet - spoofing breaks that assumption.) Breaking the semantics creates attacks.
Sorry, Sandy, but this is a narrow view of security. The question is -- "what information is being transmitted, and how can it be validated (once you've actually defined validated?" One possible answer is, "by making certain the protocol's semantics are being followed." There are other possible answers to that questions, however. When your first attempt doesn't meet ROI, you don't ask the same questions -- you go back to the original requirements to see if you asked the right questions in the first place. To do anything else will quickly resolve to the insanity pattern. Russ