RFC 2316 (rfc2316) - Page 3 of 9
Report of the IAB Security Architecture Workshop
Alternative Format: Original Text Document
RFC 2316 Report of the IAB April 1998 Finally, there is a perception problem: that IPsec will somehow solve the security problem. It won't; indeed, it can't. IPsec provides excellent protection of packets in transit. But it's hard to deploy on individual hosts, does not protect objects that may be retransmitted (i.e., email messages), does not address authorization issues, cannot block against excess resource consumption, etc. 7. Documents to be Written Collectively, we decided on several documents that need to be written: Taxonomy of Attacks In order to defend a protocol against attacks, one must, of course, know the kinds of attacks that are possible. While the specifics differ from protocol to protocol, a number of general categories can be constructed. Implementation Hints and Pitfalls Even if a protocol is sound, a host running it can be vulnerable if the protocol is implemented improperly. A variety of common errors can and do subvert the best designs. Firewall Issues Firewalls are both a common defense and a much-reviled wart on the Internet. Regardless, they are unlikely to go away any time soon. They have both strengths and weaknesses that must be considered when deploying them. Furthermore, some protocols have characteristics that are unnecessarily firewall-hostile; such practices should be avoided. Workshop Report This document. 8. Working Group Charters The actual text in the working group charter is likely to be something fairly simple, like Protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases. The actual charter text represents a policy enjoined and enforced by the IESG, and may change from time to time and from charter to Bellovin Informational



