RFC 2316 (rfc2316) - Page 2 of 9

Report of the IAB Security Architecture Workshop

RFC 2316                   Report of the IAB                  April 1998


   There were twenty-four attendees (their names are listed in Appendix
   A).  Perhaps not surprisingly for such a group, the overwhelming
   majority used some form of cryptography when connecting back to their
   home site from the meeting room.  But the situation on the rest of
   the Internet is not nearly as good; few people use encryption, even
   when they should.

   The problem is that the rate of attacks is increasing.  Apart from
   the usual few elite hackers -- the ones who find the new holes --
   there are many canned exploit scripts around.  ("Click here to attack
   this system.") Furthermore, the attackers have gotten smarter; rather
   than going after random university machines, more and more are
   targeting the Internet infrastructure, such as routers, high-level
   name servers, and the like.

   The problem is compounded by organizational laziness.  Users and
   system administrators want "magic security" -- they want whatever
   they do to be secure, regardless of whether or not it is, or even can
   be.

5. General Philosophy

   We concluded that in general, end-to-end security is better.  Thus,
   one should use something like PGP or S/MIME for email, rather than
   relying on an IPsec layer.  In general, relying on the security of
   the infrastructure is a bad idea; it, too, is under attack.  Even
   firewall-protected intranets can be subverted.  At best, the
   infrastructure should provide availability; it is the responsibility
   of individual protocols not to make unreasonable demands on the
   infrastructure during an attack.

6. IETF Structure

   Our security problem is compounded by the IETF's inherent structure
   (or, in some cases, the lack thereof).  By intent, we are a volunteer
   organization.  Who should do the security work?  The other protocol
   designers?  Often, they have neither the time nor the interest nor
   the training to do it.  Security area members?  What if they are not
   interested in some subject area, or lack the time themselves?  We
   cannot order them to serve.

   To the extent that the IETF does have management, it is embodied in
   the working group charters.  These are in essence contracts between
   the IESG and a working group, spelling out what is to be done and on
   what schedule.  Can the IESG unilaterally impose new requirements on
   existing working groups?  What if security cannot be added on without
   substantial changes to the fundamental structure of a protocol that
   has been reworked over several years?



Bellovin                     Informational