One document matched: draft-ietf-drinks-sppp-over-soap-05.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3688 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml">
<!ENTITY rfc5486 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5486.xml">
<!ENTITY rfc5246 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc2617 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
<!ENTITY rfc2616 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY rfc2818 PUBLIC ""
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
]>
<rfc category="std" docName="draft-ietf-drinks-sppp-over-soap-05" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="draft-ietf-drinks-sppp-over-soap">SPPP Over SOAP and HTTP</title>
<author initials='K.C.' surname="Cartwright" fullname='Kenneth Cartwright'>
<organization>TNS</organization>
<address>
<postal>
<street>1939 Roland Clarke Place</street>
<city>Reston</city> <region>VA</region>
<code>20191</code>
<country>USA</country>
</postal>
<email>kcartwright@tnsi.com</email>
</address>
</author>
<date year="2011" month="September"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>DRINKS</workgroup>
<abstract>
<t>The Session Peering Provisioning Protocol (SPPP) is an XML protocol
that exists to enable the provisioning of session establishment data into
Session Data Registries or SIP Service Provider data stores. Sending XML
data structures over Simple Object Access Protocol (SOAP) and HTTP(s) is
a widely used, de-facto standard for messaging between elements of
provisioning systems. Therefore the combination of SOAP and HTTP(s) as
a transport for SPPP is a natural fit. The obvious benefits include
leveraging existing industry expertise, leveraging existing standards,
and a higher probability that existing provisioning systems can be more
easily integrated with this protocol. This document describes the
specification for transporting SPPP XML structures over SOAP and HTTP(s).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>SPPP, defined in <xref target="I-D.draft-ietf-drinks-spprov"/>,
is best supported by a transport and messaging infrastructure
that is connection oriented, request-response oriented, easily secured,
supports propagation through firewalls in a standard fashion, and that
is easily integrated into back-office systems. This is due to the fact that
the client side of SPPP is likely to be integrated with organizations'
operational support systems that facilitate transactional provisioning of user
addresses and their associated session establishment data. While the server
side of SPPP is likely to reside in a separate organization's network, resulting
the SPPP provisioning transactions traversing the Internet as
they are propagated from the SPPP client to the SPPP server. Given the
current state of industry practice and technologies,
SOAP and HTTP(s) are well suited for this type of environment. This document
describes the specification for transporting SPPP XML structures over
SOAP and HTTP(s).</t>
<t>The specification in this document for transporting SPPP XML structures
over SOAP and HTTP(s) is primarily comprised of five subjects: (1) a
description of any applicable SOAP features, (2) any applicable HTTP
features, (3) security considerations, and perhaps most importantly,
(5) the Web Services Description Language (WSDL) definition for SPPP over
SOAP.</t>
</section>
<section anchor="Terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<section anchor="SOAPFeatures" title="SOAP Features and SPPP">
<t>The list of SOAP features that are explicitly used and required for SPPP are limited. Most SOAP features are not necessary for SPPP. SPPP primarily uses SOAP simply as a standard message envelope technology. The SOAP message envelope is comprised of the SOAP header and body. As described in the SOAP specifications, the SOAP header can contain optional, application specific, information about the message. The SOAP body contains the SPPP message itself, whose structure is defined by the combination of one of the WSDL operations defined in this document and the SPPP XML data structures defined in the SPPP protocol document. SPPP does not rely on any data elements in the SOAP header. All relevant data elements are defined in the SPPP XML schema described in <xref target="I-D.draft-ietf-drinks-spprov"/> and the SPPP WSDL specification described in this document.</t>
<t>WSDL is a widely standardized and adopted technology for defining the top-level structures of the messages that are transported within the body of a SOAP message. The WSDL definition for the SPPP SOAP messages is defined later in this document, which imports by reference the XML data types contained in the SPPP schema. The IANA registry where the SPPP schema resides is described in The IETF XML Registry <xref target="RFC3688"/>.</t>
<t>There are multiple structural styles that SOAP WSDL allows. But the best practice for this type of application is what is sometimes referred to as the Document Literal Wrapped style of designing SOAP WSDL. This style is generally regarded as an optimal approach that enhances maintainability, comprehension, portability, and, to a certain extent, performance. It is characterized by setting the soapAction binding style as _document_, the soapAction encoding style as _literal_, and then defining the SOAP messages to simply contain a single data element that _wraps_ that is a data structure containing all the required input or output data elements. The figure below illustrates this high level technical structure.</t>
<figure anchor="TechnicalStructureofSPPP"
title="Technical Structure of the SPPP SOAP Messages">
<artwork align="left"><![CDATA[
+---------------+
+------| SOAP |------+
| | Operation | |
Contains | +----------------+ | Contains
| Example: |
V submitUpdateRqst V
+--------------+ +-------------+
|SOAP Request | |SOAP Response|
Example:| Message | | Message | Example:
spppUpdate | (Operation | | (Operation |spppUpdate
RequestMsg | Input) | | Output) | ResponseMsg
+--------------+ +-------------+
| |
Contains | | Contains
| |
V V
+---------------+ +---------------+
Example:| Wrapped | | Wrapped | Example:
spppUpdate |Request Object | |Response Object| spppUpdate
Request +---------------+ +---------------+ Response
| |
Contains | | Contains
| |
V V
+---------------+ +---------------------+
| SPPP | | SPPP |
| XML Types | | XML Types |
+---------------+ +---------------------+
]]></artwork>
</figure>
<t>The SOAP operations supported by SPPP are normatively defined later in this
document. Each SOAP operation defines a request/input message and a
response/output message. Each such request and response message then
contains a single object that wraps the SPPP XML data types that comprise
the inputs and the outputs, respectively, of the SOAP operation.</t>
<t>SOAP faults are not used by the SPPP SOAP mapping. All SPPP success
and error responses are specified within the SPPP protocol specification
<xref target="I-D.draft-ietf-drinks-spprov"/>. However, if a SOAP fault were
to occur, perhaps due to failures in the SOAP message handling layer of a SOAP
library, the client application should capture and handle the fault. Specifics
on how to handle such SOAP faults, if they should occur, will be specific to
the chosen SOAP implementation. </t>
<t>SOAP 1.2 <xref target="SOAPREF"/> or higher and WSDL 1.1 <xref target="WSDLREF"/> or higher SHOULD be used.</t>
</section>
<section anchor="HTTPFeatures" title="HTTP(s) Features and SPPP">
<t>SOAP is not tied to HTTP(s), however, for reasons described in the
introduction, HTTP(s) is a good choice as the transport mechanism for
the SPPP SOAP messages. HTTP 1.1 includes the "persistent connection"
feature, which allows multiple HTTP request/response pairs to be transported
across a single HTTP connection. This is an important performance
optimization feature, particularly when the connections is an HTTPS
connection where the relatively time consuming SSL handshake has occurred.
Persistent connections SHOULD be used for the SPPP HTTP connections.</t>
<t>HTTP 1.1 <xref target="RFC2616"/> or higher SHOULD be used.</t>
</section>
<section anchor="AuthenticationSessionManagement" title="Authentication and Session Management">
<t>To achieve integrity and privacy, conforming SPPP SOAP Clients and Servers MUST support SOAP over HTTP over TLS <xref target="RFC5246"/> as the secure transport mechanism. This combination of HTTP and TLS is referred to as HTTPS. And to accomplish authentication, conforming SOAP SPPP Clients and Servers MUST use HTTP Digest Authentication as defined in <xref target="RFC2617"/>. As a result, the communication session is established through the initial HTTP connection setup, the digest authentication, and the TLS handshake. When the HTTP connection is broken down, the communication session ends.</t>
</section>
<section anchor="SPPPWSDL" title="SPPP SOAP WSDL Definition">
<t>The SPPP WSDL is defined below. The WSDL design approach is commonly referred to as _Generic WSDL_. It is generic in the sense that there is not a specific WSDL operation defined for each object type that is supported by the SPPP protocol. There is a single WSDL update operation called submitUpdateRqst, and a single WSDL query operation called submitQueryRqst. The submitUpdateRqst operation takes as input an spppUpdateRequestMsg object and returns as output an spppUpdateResponseMsg object. These objects _wrap_ the spppUpdateRequest and spppUpdateResponse objects respectively. These two object data structures are described in the SPPP protocol specification <xref target="I-D.draft-ietf-drinks-spprov"/>. And finally, the spppSOAPBinding in the WSDL defines the binding style as _document_ and the encoding as _literal_. It is this combination of _wrapped_ input and output data structures, _document_ binding style, and _literal_ encoding that characterize the Document Literal Wrapped style of WSDL specifications.</t>
<t>The advantage of generic WSDL is that the WSDL is more succinct, much simpler, and therfore more easily maintained. As new types of protocol objects and actions are added into or removed from the SPPP protocol, the WSDL does not need to change. This approach is made possible by the fact that the SPP XML data types and supported actions are defined in the SPPP XML schema, not in the WSDL. As a result the supported actions do not need to be re-defined here inside the SPPP SOAP WSDL.</t>
<t>
Note: The following WSDL has been formatted (e.g., tabs, spaces) to meet I-D requirements.
</t>
<t>
<figure anchor="WSDL" title="WSDL">
<artwork align="left"><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:spppb="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:sppps="urn:ietf:params:xml:ns:sppp:soap:1"
targetNamespace="urn:ietf:params:xml:ns:sppp:soap:1"
xsi:schemaLocation="spppbase.xsd">
<wsdl:types>
<xsd:schema>
<xsd:import namespace="urn:ietf:params:xml:ns:sppp:base:1"
schemaLocation="spppbase.xsd"/>
</xsd:schema>
</wsdl:types>
<wsdl:message name="spppUpdateRequestMsg">
<wsdl:part name="rqst" element="spppb:spppUpdateRequest"/>
</wsdl:message>
<wsdl:message name="spppUpdateResponseMsg">
<wsdl:part name="rspns" element="spppb:spppUpdateResponse"/>
</wsdl:message>
<wsdl:message name="spppQueryRequestMsg">
<wsdl:part name="rqst" element="spppb:spppQueryRequest"/>
</wsdl:message>
<wsdl:message name="spppQueryResponseMsg">
<wsdl:part name="rspns" element="spppb:spppQueryResponse"/>
</wsdl:message>
<wsdl:message name="spppServerStatusRequestMsg">
<wsdl:part name="rqst" element="spppb:spppServerStatusRequest"/>
</wsdl:message>
<wsdl:message name="spppServerStatusResponseMsg">
<wsdl:part name="rspns" element="spppb:spppServerStatusResponse"/>
</wsdl:message>
<wsdl:portType name="spppPortType">
<wsdl:operation name="submitUpdateRqst">
<wsdl:input message="sppps:spppUpdateRequestMsg"/>
<wsdl:output message="sppps:spppUpdateResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitQueryRqst">
<wsdl:input message="sppps:spppQueryRequestMsg"/>
<wsdl:output message="sppps:spppQueryResponseMsg"/>
</wsdl:operation>
<wsdl:operation name="submitServerStatusRqst">
<wsdl:input message="sppps:spppServerStatusRequestMsg"/>
<wsdl:output message="sppps:spppServerStatusResponseMsg"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="spppSoapBinding" type="sppps:spppPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="submitUpdateRqst">
<soap:operation soapAction="submitUpdateRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitQueryRqst">
<soap:operation soapAction="submitQueryRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
<wsdl:operation name="submitServerStatusRqst">
<soap:operation soapAction="submitServerStatusRqst" style="document"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="spppService">
<wsdl:port name="spppPort" binding="sppps:spppSoapBinding">
<soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
]]></artwork>
</figure></t>
</section>
<section anchor="SPPPExamples" title="SPPP SOAP Examples">
<t>This section provides a few examples of SPPP SOAP messages. This section of course
relies on the XML data structures defined in the SPPP protocol specification <xref target="I-D.draft-ietf-drinks-spprov"/>. So refer to that document to understand XML object types embedded in these example messages.</t>
<t>
Note: The following examples have been formatted (e.g., tabs, spaces) to meet I-D requirements.
</t>
<t>
<figure anchor="Example1" title="Example 1 - SPPP Update Request - Add Destination Group">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:spb="urn:ietf:params:xml:ns:sppp:base:1">
<soapenv:Header/>
<soapenv:Body>
<spb:spppUpdateRequest
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spb:clientTransId>888</spb:clientTransId>
<spb:minorVer>1</spb:minorVer>
<spb:rqst xsi:type="spb:AddDestGrpRqstType">
<spb:destGrp>
<spb:rant>registrant2</spb:rant>
<spb:dgName>DEST_GRP_SPPP_5</spb:dgName>
</spb:destGrp>
</spb:rqst>
</spb:spppUpdateRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="Example2" title="Example 2 - SPPP Query Request - Get Destination Group">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:spb="urn:ietf:params:xml:ns:sppp:base:1">
<soapenv:Header/>
<soapenv:Body>
<spb:spppQueryRequest
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spb:minorVer>1</spb:minorVer>
<spb:rqst xsi:type="spb:GetDestGrpsRqstType">
<spb:objKey>
<spb:rant>registrant2</spb:rant>
<spb:name>DEST_GRP_SPPP_5</spb:name>
</spb:objKey>
</spb:rqst>
</spb:spppQueryRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="Example3" title="Example 2 - SPPP Query Request - Del Destination Group">
<artwork align="left">
<![CDATA[
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:spb="urn:ietf:params:xml:ns:sppp:base:1">
<soapenv:Header/>
<soapenv:Body>
<spb:spppQueryRequest
xsi:schemaLocation="urn:ietf:params:xml:ns:sppp:base:1 sppp.xsd"
xmlns="urn:ietf:params:xml:ns:sppp:base:1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<spb:clientTransId>999</spb:clientTransId>
<spb:minorVer>1</spb:minorVer>
<spb:rqst xsi:type="spb:DelDestGrpRqstType">
<spb:objKey>
<spb:rant>registrant2</spb:rant>
<spb:name>DEST_GRP_SPPP_5</spb:name>
</spb:objKey>
</spb:rqst>
</spb:spppQueryRequest>
</soapenv:Body>
</soapenv:Envelope>
]]>
</artwork>
</figure>
</t>
</section>
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>SPPP 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 <xref target="RFC2818"/>.
SPPP data may include sensitive
information, routing data, lists of resolvable addresses, etc. So when used
in a production setting and across non-secure networks, SPPP
should only be used over communications channels that provide strong
encryption for data privacy.</t>
<section anchor="IntegrityPrivacyAuthentication" title="Integrity, Privacy, and Authentication">
<t>The SPPP SOAP binding relies on an underlying secure transport for
integrity and privacy. Such transports are expected to include TLS/HTTPS.
In addition to the application level authentication imposed by an SPPP
server, there are a number of options for authentication within the transport
layer and the messaging envelope. These include TLS client certificates,
HTTP Digest Access Authentication, and digital signatures within SOAP headers. </t>
<t>At a miniumum, all conforming SPPP over SOAP implementations MUST
support HTTPS.</t>
</section>
<section anchor="Vulnerabilities" title="Vulnerabilities">
<t>The above protocols may have various vulnerabilities, and these may
be inherited by SPPP over SOAP. And SPPP itself may have vulnerabilities
because an authorization model is not explicitly specified in the current
specification.
</t>
<t>It is important that SPPP implementations implement an authorization
model that considers the source of each SPPP query or update request and
determines whether it is reasonable to authorize that source to perform that
specific query or update. </t>
</section>
<section anchor="DeploymentEnvironmentSpecifics" title="Deployment Environment Specifics">
<t>Some deployments of SPPP over SOAP could choose to use transports
without encryption. This presents vulnerabilities but could be
selected for deployments involving closed networks or debugging
scenarios. However, the vulnerabilities of such a deployment could be a
lack of integrity and privacy of the data transported over SPPP messages in
this type of deployment.</t>
</section>
</section>
<section anchor="IANAConsiderations" title="IANA Considerations">
<t>This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in <xref target="RFC3688"/>.
</t>
<t>URN assignments are requested: urn:ietf:params:xml:ns:sppp:soap</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
This document is a result of various discussions held by the DRINKS design team, which is comprised of the following individuals, in no specific order: Syed Ali (NeuStar), Sumanth Channabasappa (Cable Labs), David Schwartz (XConnect), Jean-Francois Mule (CableLabs), Kenneth Cartwright (TNS, Inc.), Manjul Maharishi (TNS, Inc.), Alexander Mayrhofer (enum.at GmbH).
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3688;
&rfc5246;
&rfc2617;
&rfc2616;
<reference anchor="I-D.draft-ietf-drinks-spprov">
<front>
<title>DRINKS Use cases and Protocol Requirements</title>
<author initials="J-F.M." surname="Mule"/>
<author initials="K.C." surname="Cartwright"/>
<author initials="S.A." surname="Ali"/>
<author initials="A.M." surname="Mayrhofer"/>
<date month="June" year="2011" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-drinks-spprov-09"/>
<format target="http://tools.ietf.org/html/draft-ietf-drinks-spprov-09" type="HTML" />
</reference>
<reference anchor="SOAPREF">
<front>
<title>SOAP Version 1.2 Part 1: Messaging Framework</title>
<author initials="M." surname="Gudgin"/>
<author initials="M." surname="Hadley"/>
<author initials="J." surname="Moreau"/>
<author initials="H." surname="Nielsen"/>
<date month="June" year="2002" />
</front>
<seriesInfo name="W3C Recommendation" value="REC-SOAP12-part1-20030624"/>
<format target="http://www.w3.org/TR/soap12-part1/" type="HTML" />
</reference>
</references>
<references title="Informative References">
&rfc2818;
<reference anchor="WSDLREF">
<front>
<title>Web Services Description Language (WSDL) 1.1</title>
<author initials="E." surname="Christensen"/>
<author initials="F." surname="Curbera"/>
<author initials="G." surname="Meredith"/>
<author initials="S." surname="Weerawarana"/>
<date month="March" year="2001" />
</front>
<seriesInfo name="W3C Note" value="NOTE-wsdl-20010315"/>
<format target="http://www.w3.org/TR/2001/NOTE-wsdl-20010315" type="HTML" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 11:34:36 |