Safe(r) Limited Domains
draft-wkumari-intarea-safe-limited-domains-04
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|
|
|---|---|---|---|
| Authors | Warren Kumari , Andrew Alston , Éric Vyncke , Suresh Krishnan , Donald E. Eastlake 3rd | ||
| Last updated | 2025-09-04 (Latest revision 2025-03-03) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Documents describing protocols that are only intended to be used within "limited domains" often do not clearly define how the boundary of the limited domain is implemented and enforced, or require that operators of these limited domains perfectly filter at all of the boundary nodes of the domain to protect the rest of the global Internet from these protocols and vice-versa. This document discusses some design principles and offers mechanisms to allow protocols that are designed to operate in a limited domain "fail-closed" rather than "fail-open", thereby making these protocols safer to deploy on the Internet. These mechanism are not applicable to all protocols intended for use in a limited domain, but if implemented on certain classes of protocols, they can significantly reduce the risks.
Authors
Warren Kumari
Andrew Alston
Éric Vyncke
Suresh Krishnan
Donald E. Eastlake 3rd
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)