One document matched: draft-ietf-drinks-sppp-over-soap-05.txt
Differences from draft-ietf-drinks-sppp-over-soap-04.txt
DRINKS K. Cartwright
Internet-Draft TNS
Intended status: Standards Track September 2, 2011
Expires: March 5, 2012
SPPP Over SOAP and HTTP
draft-ietf-drinks-sppp-over-soap-05
Abstract
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).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 5, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Cartwright Expires March 5, 2012 [Page 1]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SOAP Features and SPPP . . . . . . . . . . . . . . . . . . . . 5
4. HTTP(s) Features and SPPP . . . . . . . . . . . . . . . . . . 8
5. Authentication and Session Management . . . . . . . . . . . . 9
6. SPPP SOAP WSDL Definition . . . . . . . . . . . . . . . . . . 10
7. SPPP SOAP Examples . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.1. Integrity, Privacy, and Authentication . . . . . . . . . . 15
8.2. Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 15
8.3. Deployment Environment Specifics . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Cartwright Expires March 5, 2012 [Page 2]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
1. Introduction
SPPP, defined in [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).
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.
Cartwright Expires March 5, 2012 [Page 3]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
2. Terminology
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 [RFC2119].
Cartwright Expires March 5, 2012 [Page 4]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
3. SOAP Features and SPPP
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 [I-D.draft-ietf-drinks-spprov] and the
SPPP WSDL specification described in this document.
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 [RFC3688].
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.
Cartwright Expires March 5, 2012 [Page 5]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
+---------------+
+------| 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 |
+---------------+ +---------------------+
Figure 1: Technical Structure of the SPPP SOAP Messages
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.
SOAP faults are not used by the SPPP SOAP mapping. All SPPP success
and error responses are specified within the SPPP protocol
specification [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.
SOAP 1.2 [SOAPREF] or higher and WSDL 1.1 [WSDLREF] or higher SHOULD
Cartwright Expires March 5, 2012 [Page 6]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
be used.
Cartwright Expires March 5, 2012 [Page 7]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
4. HTTP(s) Features and SPPP
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.
HTTP 1.1 [RFC2616] or higher SHOULD be used.
Cartwright Expires March 5, 2012 [Page 8]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
5. Authentication and Session Management
To achieve integrity and privacy, conforming SPPP SOAP Clients and
Servers MUST support SOAP over HTTP over TLS [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
[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.
Cartwright Expires March 5, 2012 [Page 9]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
6. SPPP SOAP WSDL Definition
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 [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.
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.
Note: The following WSDL has been formatted (e.g., tabs, spaces) to
meet I-D requirements.
<?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>
Cartwright Expires March 5, 2012 [Page 10]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
<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"/>
Cartwright Expires March 5, 2012 [Page 11]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
</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>
Figure 2: WSDL
Cartwright Expires March 5, 2012 [Page 12]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
7. SPPP SOAP Examples
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 [I-D.draft-ietf-drinks-spprov]. So refer
to that document to understand XML object types embedded in these
example messages.
Note: The following examples have been formatted (e.g., tabs, spaces)
to meet I-D requirements.
<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>
Figure 3: Example 1 - SPPP Update Request - Add Destination Group
Cartwright Expires March 5, 2012 [Page 13]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
<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>
Figure 4: Example 2 - SPPP Query Request - Get Destination Group
<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>
Figure 5: Example 2 - SPPP Query Request - Del Destination Group
Cartwright Expires March 5, 2012 [Page 14]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
8. Security Considerations
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 [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.
8.1. Integrity, Privacy, and Authentication
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.
At a miniumum, all conforming SPPP over SOAP implementations MUST
support HTTPS.
8.2. Vulnerabilities
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.
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.
8.3. Deployment Environment Specifics
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.
Cartwright Expires March 5, 2012 [Page 15]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
9. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688].
URN assignments are requested: urn:ietf:params:xml:ns:sppp:soap
Cartwright Expires March 5, 2012 [Page 16]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
10. Acknowledgements
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).
Cartwright Expires March 5, 2012 [Page 17]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
11. References
11.1. Normative References
[I-D.draft-ietf-drinks-spprov]
Mule, J-F., Cartwright, K., Ali, S., and A. Mayrhofer,
"DRINKS Use cases and Protocol Requirements",
draft-ietf-drinks-spprov-09 (work in progress), June 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SOAPREF] Gudgin, M., Hadley, M., Moreau, J., and H. Nielsen, "SOAP
Version 1.2 Part 1: Messaging Framework", W3C
Recommendation REC-SOAP12-part1-20030624, June 2002.
11.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[WSDLREF] Christensen, E., Curbera, F., Meredith, G., and S.
Weerawarana, "Web Services Description Language (WSDL)
1.1", W3C Note NOTE-wsdl-20010315, March 2001.
Cartwright Expires March 5, 2012 [Page 18]
Internet-Draft draft-ietf-drinks-sppp-over-soap September 2011
Author's Address
Kenneth Cartwright
TNS
1939 Roland Clarke Place
Reston, VA 20191
USA
Email: kcartwright@tnsi.com
Cartwright Expires March 5, 2012 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 09:59:08 |