--- 1/draft-ietf-drinks-spp-protocol-over-soap-08.txt 2016-04-04 13:16:30.724690421 -0700 +++ 2/draft-ietf-drinks-spp-protocol-over-soap-09.txt 2016-04-04 13:16:30.876694208 -0700 @@ -1,22 +1,22 @@ DRINKS K. Cartwright Internet-Draft V. Bhatia Intended status: Standards Track TNS -Expires: January 23, 2016 J-F. Mule +Expires: October 5, 2016 J-F. Mule CableLabs A. Mayrhofer - enum.at GmbH - July 22, 2015 + nic.at GmbH + April 3, 2016 Session Peering Provisioning (SPP) Protocol over SOAP - draft-ietf-drinks-spp-protocol-over-soap-08 + draft-ietf-drinks-spp-protocol-over-soap-09 Abstract The Session Peering Provisioning Framework (SPPF) specifies the data model and the overall structure to provision session establishment data into Session Data Registries and SIP Service Provider data stores. To utilize this framework one needs a substrate protocol. Given that Simple Object Access Protocol (SOAP) is currently widely used for messaging between elements of such provisioning systems, this document specifies the usage of SOAP (via HTTPS) as the @@ -33,25 +33,25 @@ 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 January 23, 2016. + This Internet-Draft will expire on October 5, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 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 (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 @@ -61,67 +61,67 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. SOAP Features and Protocol Layering . . . . . . . . . . . . . 4 4. HTTP(s) Features and SPP Protocol over SOAP . . . . . . . . . 7 5. Authentication, Integrity and Confidentiality . . . . . . . . 7 6. Language Identification . . . . . . . . . . . . . . . . . . . 7 7. SPP Protocol SOAP Data Structures . . . . . . . . . . . . . . 7 7.1. Concrete Object Key Types . . . . . . . . . . . . . . . . 8 7.1.1. Generic Object Key . . . . . . . . . . . . . . . . . 8 - 7.1.2. Public Identity Object Key . . . . . . . . . . . . . 9 + 7.1.2. Public Identifier Object Key . . . . . . . . . . . . 9 7.1.3. SED Group Offer Key . . . . . . . . . . . . . . . . . 10 - 7.2. Operation Request and Response Structures . . . . . . . . 10 + 7.2. Operation Request and Response Structures . . . . . . . . 11 7.2.1. Add Operation Structure . . . . . . . . . . . . . . . 11 7.2.2. Delete Operation Structure . . . . . . . . . . . . . 14 7.2.3. Accept Operation Structure . . . . . . . . . . . . . 17 7.2.4. Reject Operation Structure . . . . . . . . . . . . . 20 7.2.5. Batch Operation Structure . . . . . . . . . . . . . . 23 7.2.6. Get Operation Structure . . . . . . . . . . . . . . . 26 7.2.7. Get SED Group Offers Operation Structure . . . . . . 27 7.2.8. Generic Query Response . . . . . . . . . . . . . . . 29 7.2.9. Get Server Details Operation Structure . . . . . . . 29 7.3. Response Codes and Messages . . . . . . . . . . . . . . . 31 7.4. Minor Version Identifier . . . . . . . . . . . . . . . . 33 8. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 33 9. SPP Protocol over SOAP WSDL Definition . . . . . . . . . . . 33 - 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 44 + 10. SPP Protocol over SOAP Examples . . . . . . . . . . . . . . . 45 10.1. Add Destination Group . . . . . . . . . . . . . . . . . 45 10.2. Add SED Records . . . . . . . . . . . . . . . . . . . . 47 10.3. Add SED Records -- URIType . . . . . . . . . . . . . . . 48 10.4. Add SED Group . . . . . . . . . . . . . . . . . . . . . 49 - 10.5. Add Public Identity -- Successful COR claim . . . . . . 51 + 10.5. Add Public Identifier -- Successful COR claim . . . . . 51 10.6. Add LRN . . . . . . . . . . . . . . . . . . . . . . . . 53 10.7. Add TN Range . . . . . . . . . . . . . . . . . . . . . . 54 10.8. Add TN Prefix . . . . . . . . . . . . . . . . . . . . . 55 10.9. Enable Peering -- SED Group Offer . . . . . . . . . . . 57 10.10. Enable Peering -- SED Group Offer Accept . . . . . . . . 58 10.11. Add Egress Route . . . . . . . . . . . . . . . . . . . . 59 10.12. Remove Peering -- SED Group Offer Reject . . . . . . . . 61 10.13. Get Destination Group . . . . . . . . . . . . . . . . . 62 - 10.14. Get Public Identity . . . . . . . . . . . . . . . . . . 64 + 10.14. Get Public Identifier . . . . . . . . . . . . . . . . . 64 10.15. Get SED Group Request . . . . . . . . . . . . . . . . . 65 10.16. Get SED Group Offers Request . . . . . . . . . . . . . . 67 10.17. Get Egress Route . . . . . . . . . . . . . . . . . . . . 69 10.18. Delete Destination Group . . . . . . . . . . . . . . . . 71 - 10.19. Delete Public Identity . . . . . . . . . . . . . . . . . 72 + 10.19. Delete Public Identifier . . . . . . . . . . . . . . . . 72 10.20. Delete SED Group Request . . . . . . . . . . . . . . . . 73 10.21. Delete SED Group Offers Request . . . . . . . . . . . . 74 10.22. Delete Egress Route . . . . . . . . . . . . . . . . . . 76 10.23. Batch Request . . . . . . . . . . . . . . . . . . . . . 77 11. Security Considerations . . . . . . . . . . . . . . . . . . . 79 11.1. Vulnerabilities . . . . . . . . . . . . . . . . . . . . 80 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 80 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 81 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 14.1. Normative References . . . . . . . . . . . . . . . . . . 81 - 14.2. Informative References . . . . . . . . . . . . . . . . . 81 + 14.2. Informative References . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82 1. Introduction SPPF, defined in [I-D.draft-ietf-drinks-spp-framework], 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 SPPF is likely to be integrated with @@ -241,22 +241,25 @@ respectively, of the SOAP operation. SOAP faults are not used by the SPP Protocol over SOAP. All success and error responses are specified in Section 7.3 of this document. 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. - This document RECOMMENDS SOAP 1.2 [SOAPREF] or higher, and WSDL 1.1 - [WSDLREF] or higher. + Implementations MUST use SOAP 1.2 [SOAPREF] or higher, and MUST + support SOAP 1.2. Implementations SHOULD use WSDL 1.1 [WSDLREF], and + MUST NOT use earlier versions. Use of WSDL versions greater than 1.1 + may introduce interopability problems with implementations that use + 1.1. SPPF is a request/reply framework that allows a client application to submit provisioning data and query requests to a server. The SPPF data structures are designed to be protocol agnostic. Concerns regarding encryption, non-repudiation, and authentication are beyond the scope of this document. For more details, please refer to Section 4 ("Substrate Protocol Requirements") of [I-D.draft-ietf-drinks-spp-framework]. As illustrated in the previous diagram, SPPF can be viewed as a set @@ -283,44 +286,45 @@ 4. HTTP(s) Features and SPP Protocol over SOAP While SOAP is not tied to HTTP(S), for reasons described in the introduction, HTTP(S) is a good choice as the substrate protocol for the SPP Protocol 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. + consuming TLS handshake has occurred. Implementations compliant with this document MUST use HTTP 1.1 - [RFC2616] or higher. Also, implementations SHOULD use persistent + [RFC7230] or higher. Also, implementations SHOULD use persistent connections. 5. Authentication, Integrity and Confidentiality To accomplish authentication, conforming SPP Protocol over SOAP Clients and Servers MUST use HTTP Digest Authentication as defined in [RFC2617]. To achieve integrity and privacy, conforming SPP Protocol over SOAP Clients and Servers MUST support Transport Layer Security (TLS) as - defined in [RFC5246] as the secure transport mechanism. + defined in [RFC5246] as the secure transport mechanism. Use of TLS + MUST follow the recommendations contained in [RFC7525] 6. Language Identification Section 9 of [I-D.draft-ietf-drinks-spp-framework] requires protocols to provide a mechanism to transmit language tags together with human- readable messages. When conforming SPP Protocol SOAP servers use such tagging, the XML "lang" attribute ([W3C.REC-xml-20081126], Section 2.12) MUST be used. Clients MAY use the HTTP "Accept- - Language" header field (see Section 14.4 of [RFC2616]) in order to + Language" header field (see Section 5.3.5 of [RFC7231]) in order to indicate their language preference. 7. SPP Protocol SOAP Data Structures SPP Protocol over SOAP uses a set of XML based data structures for all the supported operations and any parameters that those operations are applied to. As also mentioned earlier in this document, these XML structures are envelope-independent and substrate-independent. Refer the "Protocol Operations" (Section 8) of this document for a description of all the operations that MUST be supported. @@ -378,26 +382,26 @@ -7.1.2. Public Identity Object Key +7.1.2. Public Identifier Object Key - Public Identity type objects can further be of various sub-types like - a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or a TN - Range and cannot be cleanly identified with the attributes in the - generic ObjKeyType. The definition of PubIdKeyType is as below: + Public Identifier type objects can further be of various sub-types + like a Telephone Number (TN), Routing Number (RN), TN Prefix, URI, or + a TN Range and cannot be cleanly identified with the attributes in + the generic ObjKeyType. The definition of PubIdKeyType is as below: txn_1479 tx_12345 1000 Request Succeeded. -10.5. Add Public Identity -- Successful COR claim +10.5. Add Public Identifier -- Successful COR claim - SSP2 activates a TN public identity by associating it with a valid + SSP2 activates a TN public identifier by associating it with a valid destination group. Further, SSP2 puts forth a claim that it is the carrier-of-record for the TN. @@ -2485,25 +2498,25 @@ iana-en:222 SED_GRP_SSP2_1 SedGrp iana-en:111 Registry confirms that the request has been processed successfully. - From this point forward, if SSP1 looks up a public identity through - the query resolution server, where the public identity is part of the - destination group by way of "SED_GRP_SSP2_1" session establishment - data association, SSP2 ingress SBE information will be shared with - SSP1. + From this point forward, if SSP1 looks up a public identifier through + the query resolution server, where the public identifier is part of + the destination group by way of "SED_GRP_SSP2_1" session + establishment data association, SSP2 ingress SBE information will be + shared with SSP1. txn_1479 tx_12350 @@ -2592,26 +2605,26 @@ iana-en:222 SED_GRP_SSP2_1 SedGrp iana-en:111 Registry confirms that the request has been processed successfully. - From this point forward, if SSP1 looks up a public identity through - the query resolution server, where the public identity is part of the - destination group by way of "SED_GRP_SSP2_1" session establishment - data association, SSP2 ingress SBE information will not be shared - with SSP1 and hence SSP2 ingress SBE will not be returned in the - query response. + From this point forward, if SSP1 looks up a public identifier through + the query resolution server, where the public identifier is part of + the destination group by way of "SED_GRP_SSP2_1" session + establishment data association, SSP2 ingress SBE information will not + be shared with SSP1 and hence SSP2 ingress SBE will not be returned + in the query response. txn_1479 tx_12350 @@ -2664,21 +2677,21 @@ iana-en:222 iana-en:223 2012-10-22T09:30:10Z DEST_GRP_SSP2_1 -10.14. Get Public Identity +10.14. Get Public Identifier SSP2 obtains the last provisioned record associated with a given TN. @@ -2940,21 +2953,21 @@ xmlns:ns3="urn:ietf:params:xml:ns:sppf:soap:1"> tx_12354 1000 Request Succeeded. -10.19. Delete Public Identity +10.19. Delete Public Identifier SSP2 chooses to de-activate the TN and remove it from the registry. @@ -3246,20 +3259,25 @@ 1000 Request Succeeded. 11. Security Considerations + The base security considerations of SPPP outlined in Section 9 of + [I-D.draft-ietf-drinks-spp-framework] also apply to SPP Protocol over + SOAP implementations. Additionally, the following must be + considered: + SPP Protocol 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 @@ -3313,41 +3331,55 @@ 14. References 14.1. Normative References [I-D.draft-ietf-drinks-spp-framework] Cartwright, K., Bhatia, V., Ali, S., and D. Schwartz, "Session Peering Provisioning Framework", draft-ietf- drinks-spp-framework-08 (work in progress), July 2015. [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. + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [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, DOI 10.17487/RFC2617, June 1999, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . + [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + + [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, + . + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May + 2015, . + [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. 14.2. Informative References [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . @@ -3386,16 +3417,16 @@ Jean-Francois Mule CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA Email: jfm@cablelabs.com Alexander Mayrhofer - enum.at GmbH - Karlsplatz 1/9 + nic.at GmbH + Karlsplatz 1/2/9 Wien A-1010 Austria - Email: alexander.mayrhofer@enum.at + Email: alexander.mayrhofer@nic.at