11. Security Considerations
The base security considerations of SPPP outlined in Section 9 of
[RFC7877] also apply to SPPP over SOAP implementations.
Additionally, the following must be considered:
SPPP over SOAP is used to query and update session peering data and
addresses, so the ability to access this protocol should be limited
to users and systems that are authorized to query and update this
data. Because this data is sent in both directions, it may not be
sufficient for just the client or user to be authenticated with the
server. The identity of the server should also be authenticated by
the client, which is often accomplished using the TLS certificate
exchange and validation described in [RFC2818].
11.1. Vulnerabilities
Section 5 describes the use of HTTP and TLS as the underlying
substrate protocols for SPPP over SOAP. These underlying protocols
may have various vulnerabilities, and these may be inherited by SPPP
over SOAP. SPPP over SOAP itself may have vulnerabilities because an
authorization model is not explicitly specified in this document.
During a TLS handshake, TLS servers can optionally request a
certificate from a TLS client; that option is not a requirement for
this protocol. This presents a denial-of-service risk in which
unauthenticated clients can consume server CPU resources by creating
TLS sessions. The risk is increased if the server supports client-
initiated renegotiation. This risk can be mitigated by disabling
client-initiated renegotiation on the server and by ensuring that
other means (such as firewall access control lists) are used to
restrict unauthenticated client access to servers.
In conjunction with the above, it is important that SPPP over SOAP
implementations implement an authorization model that considers the
source of each query or update request and determines whether it is
reasonable to authorize that source to perform that specific query or
update.