diff --git a/security/network-security-considerations.md b/security/network-security-considerations.md
new file mode 100644
index 0000000..798a1d6
--- /dev/null
+++ b/security/network-security-considerations.md
@@ -0,0 +1,263 @@
+# Network Security Considerations
+
+This describes network services provided by OpenBMC-based systems,
+some threats the BMC faces from its network interfaces, and steps
+OpenBMC takes to address these threats.
+
+This is only intended to be a guide; security is ultimately the
+responsibility of projects which choose to incorporate OpenBMC into
+their project.  If you find a security vulnerability, please
+consider [how to report a security vulnerability][].
+
+[how to report a security vulnerability]: https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
+
+Threats to the BMC are classified using the [CIA triad][].  All threat
+types are significant; here is an example of each:
+ - Confidentiality: If an attacker can get data from the BMC, they may
+   be able to chain other vulnerabilities to establish a covert
+   information channel to get sensitive information from the host.
+ - Integrity: If an attacker can modify BMC settings or data, they may
+   be able to gain additional access, and launch more attacks.
+ - Availability: If an agent can overwhelm the BMC's resources, either
+   by accident or on purpose, the BMC will not be available to service
+   its host (denial of service).
+
+[CIA triad]: https://en.wikipedia.org/wiki/Information_security#Key_concepts
+
+This document is organized by how OpenBMC services connect to the
+network.  The general flow is:
+ - The BMC is presumed to have a network adapter.  The security
+   considerations of the NIC are important to the BMC security, but
+   are outside the scope of this document.
+ - Network traffic then flows through the kernel, detailed below.
+ - Finally, connections flow to various OpenBMC services.
+
+OpenBMC provides services on TCP and UDP ports.  For example, the
+HTTPS protocol on port 443 is used to provide REST APIs and serve Web
+applications.  These services are detailed below.  Implicit is that
+all other ports are inactive.
+
+OpenBMC also initiates network communications, for example, NTP, LDAP,
+etc.  These are covered with their associated functions.
+
+
+## Kernel and ICMP messages
+
+Network traffic is handled by the Linux kernel.  The exact kernel and
+device driver have security considerations which are important to BMC
+security, but are better addressed by the Linux kernel community.
+You can learn which kernel and patches are used from the kernel
+recipes typically found in the board support packages for the BMC
+referenced by your machine's configuration.  For example, in the
+`https://github.com/openbmc/meta-aspeed` repository under
+`recipes-kernel/linux/linux-aspeed_git.bb`.
+
+Per [CVE 1999-0524][], responding to certain ICMP packets can give an
+attacker more information about the BMC's clock or subnet, which can
+help with subsequent attacks.  OpenBMC responds to all ICMP requests.
+
+[CVE 1999-0524]: https://nvd.nist.gov/vuln/detail/CVE-1999-0524
+
+General considerations for ICMP messages apply.  For example, packet
+fragmentation and packet flooding vulnerabilities.
+
+It is sometimes useful to filter and log network messages for debug and
+other diagnostic purposes.  OpenBMC provides no support for this.
+
+
+## General considerations for services
+
+Several services perform user identification and authentication:
+ - Phosphor REST APIs
+ - Redfish REST API SessionService
+ - Network IPMI
+ - SSH secure shell
+
+OpenBMC's [phosphor-user-manager][] provides the underlying
+authentication and authorization functions and ties into IPMI, Linux
+PAM, LDAP, and logging.  Some of OpenBMC services use phosphor-user-manager.
+
+[phosphor-user-manager]: https://github.com/openbmc/docs/blob/master/user_management.md
+
+Transport layer security (TLS) protocols are configured for each
+service at compile time, become part of the image, and cannot be
+changed dynamically.  The protocols which use TLS include:
+ - RAKP for IPMI.
+ - SSH for ssh and scp.
+ - HTTPS for Web and REST APIs.
+
+Automated network agents (such as hardware management consoles) may
+malfunction in a way that the BMC continuously gets authentication
+failures, which may lead to denial of service.  For example, a brief
+delay before reporting the failure, for example, of one second, may
+help prevent this problem or lessen its severity.  See [OWASP Blocking
+Brute Force Attacks][].
+
+[OWASP Blocking Brute Force Attacks]: https://www.owasp.org/index.php/Blocking_Brute_Force_Attacks
+
+Network agents may fail to end a session properly, which causes the
+service to use resources to keep track of orphaned sessions.  To help
+prevent this, services may limit the maximum number of concurrent
+sessions, or have a session inactivity timeout.
+
+Services which are not required should be disabled to limit the BMC's
+attack surface.  For example, a large scale data center may not need a
+Web interface.  Services can be disabled in several ways:
+ 1. Configure OpenBMC recipes to build the unwanted feature out of the
+    BMC's firmware image.  This gives the BMC the advantage of a
+    smaller attack surface.
+ 2. Implement something like the [Redfish ManagerNetworkProtocol][]
+    properties for IPMI, SSH, and other BMC services, possibly by
+    using shell commands like 'systemctl disable ipmid' and 'systemctl
+    stop ipmid'.
+
+[Redfish ManagerNetworkProtocol]: https://redfish.dmtf.org/schemas/ManagerNetworkProtocol.v1_4_0.json
+
+Network services should log all authentication attempts with their
+outcomes to satisfy basic monitoring and forensic analysis
+requirements.  For example, as part of a real-time monitoring service,
+or to answer who accessed which services at what times.
+
+OpenBMC does not have a firewall.
+
+Laws may require products built on OpenBMC to have reasonable security
+built into them, for example, by not having a default password.  See,
+for example, [CA Law SB-327].
+
+[CA Law SB-327]: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327
+
+## Services provided on TCP and UPD ports
+
+### TCP port 22 - Secure Shell (SSH) access to the BMC
+
+The Secure Shell (SSH) protocol is provided, including secure shell
+(ssh command) access to the BMC's shell, and secure copy (scp command)
+to the BMC's file system.
+
+The default SSH server implementation is provided by Dropbear.
+All configuration is at compile-time with defaults for:
+ - Authentication provided by Linux PAM, where methods include
+   username and password, and SSH certificates (the `ssh-keygen`
+   command).
+ - Transport layer security (TLS) protocols offered.
+
+SSH access to the BMC's shell is not the intended way to operate the
+BMC, gives the operator more privilege than is needed, and may not be
+allowed on BMCs which service hosts that process sensitive data.
+However, BMC shell access may be needed to provision the BMC or to
+help diagnose problems during its operation.
+
+
+### TCP port 443 - HTTPS REST APIs and Web application
+
+BMCWeb is the Web server for:
+ - The Redfish REST APIs.
+ - The phosphor-webui Web interface.
+ - The Phosphor D-Bus REST interface.
+And initiates WebSockets for:
+ - Host KVM.
+ - Virtual media.
+ - Host serial console.
+
+The [BMCWeb configuration][] controls which services are provided.
+
+General security considerations for HTTP servers apply such as given
+by [OWASP Application Security][].
+
+BMCWeb controls which HTTPS transport layer security (TLS) ciphers it
+offers via compile-time header file `include/ssl_key_handler.hpp` in
+the https://github.com/openbmc/bmcweb repository.  The implementation
+is provided by OpenSSL.
+
+BMCWeb provides appropriate HTTP response headers, for example, in
+header file `include/security_headers_middleware.hpp` and
+`crow/include/crow/websocket.h` in the
+https://github.com/openbmc/bmcweb repository.
+
+[BMCWeb configuration]: https://github.com/openbmc/bmcweb#configuration
+[OWASP Application Security]: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
+
+#### REST APIs
+
+BMCWeb offers three authentication methods:
+
+ 1. The Redfish SessionService, which takes a username and password
+    and provides an X-Auth token.
+ 2. The Phosphor D-Bus REST interface '/login' URI, which takes a
+    username and password and provides a session cookie.  This method
+    is deprecated in OpenBMC.
+ 3. Basic Access Authentication, which takes a username and password
+    (often URL encoded like https://user:pass@host/...) in an
+    "Authorization" request header, and returns no credentials.  This
+    method is deprecated by RFC 3986.
+
+The username and password are presented to phosphor-user-manager for
+authentication.
+
+The first two methods create the same kind of session but return
+different credentials.  For example, you can create a Redfish session,
+and use your credentials to invoke Phosphor D-Bus REST APIs.  Note,
+however, that the X-Auth tokens are required to use POST, PUT, PATCH,
+or DELETE methods.
+
+General security considerations for REST APIs apply:
+https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/REST_Security_Cheat_Sheet.md
+
+Redfish provides security considerations in the "Security Detail"
+section of the "Redfish Specification" (document ID DSP0266) available
+from https://www.dmtf.org/standards/redfish.
+
+#### The phosphor-webui Web application
+
+General considerations for Web applications such as given by [OWASP
+Web Application Security Guidance][] apply to OpenBMC.  The
+phosphor-webui uses username and password-based authentication, and
+REST APIs for subsequent access.
+
+[OWASP Web Application Security Guidance]: https://www.owasp.org/index.php/Web_Application_Security_Guidance
+
+The web app also provides interfaces to use the host serial console,
+virtual media, and host KVM.
+
+### TCP port 2200
+
+Access to the BMC's [host serial console][] is provided via the SSH
+protocol on port 2200.
+
+[host serial console]: https://github.com/openbmc/docs/blob/master/console.md
+
+This uses the same server implementation as port 22, including the
+same TLS mechanisms.
+
+How the host secures its console (for example, username and password
+prompts) is outside the scope of this document.
+
+### TCP and UDP ports 5355 - mDNS service discovery
+
+General security considerations for service discovery apply.  For
+example, described here: https://attack.mitre.org/techniques/T1046/
+
+### UDP port 427 - SLP, Avahi
+
+General security considerations for service discovery apply.
+
+### UDP port 623 - IPMI RCMP
+
+The IPMI network-facing design is described here:
+https://github.com/openbmc/docs/blob/master/ipmi-architecture.md and
+the implementation is described here:
+https://github.com/openbmc/phosphor-net-ipmid.
+Note that host IPMI is outside the scope of this document.
+
+General security considerations for IPMI apply.  For example,
+described here: https://www.us-cert.gov/ncas/alerts/TA13-207A
+
+OpenBMC implements RCMP+ and IPMI 2.0.  The phosphor-user-manager
+provides the underlying authentication mechanism.
+
+Supported IPMI ciphers can be found in the code, for example, by
+searching for function `isAlgorithmSupported`, or from the `ipmitool`
+command such as `ipmitool channel getciphers ipmi`.
+
+OpenBMC supports IPMI "serial over LAN" (SOL) connections (via
+`impitool sol activate`) which shares the host serial console socket.