draft-ietf-drinks-spp-framework-11.txt   draft-ietf-drinks-spp-framework-12.txt 
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: January 23, 2016 S. Ali Expires: February 13, 2016 S. Ali
NeuStar NeuStar
D. Schwartz D. Schwartz
XConnect XConnect
July 22, 2015 August 12, 2015
Session Peering Provisioning Framework (SPPF) Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-11 draft-ietf-drinks-spp-framework-12
Abstract Abstract
This document specifies the data model and the overall structure for This document specifies the data model and the overall structure for
a framework to provision session establishment data into Session Data a framework to provision session establishment data into Session Data
Registries and SIP Service Provider data stores. The framework is Registries and SIP Service Provider data stores. The framework is
called the Session Peering Provisioning Framework (SPPF). The called the Session Peering Provisioning Framework (SPPF). The
provisioned data is typically used by network elements for session provisioned data is typically used by network elements for session
establishment. establishment.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 February 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
8.2. Versioning and Character Encoding . . . . . . . . . . . . 39 8.2. Versioning and Character Encoding . . . . . . . . . . . . 39
9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9.1. Confidentiality and Authentication . . . . . . . . . . . 40 9.1. Confidentiality and Authentication . . . . . . . . . . . 40
9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40 9.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 40
9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40 9.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
9.3.1. DoS Issues Inherited from Substrate Mechanism . . . . 41 9.3.1. DoS Issues Inherited from Substrate Mechanism . . . . 41
9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41 9.3.2. DoS Issues Specific to SPPF . . . . . . . . . . . . . 41
9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42 9.4. Information Disclosure . . . . . . . . . . . . . . . . . 42
9.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 42 9.5. Non-repudiation . . . . . . . . . . . . . . . . . . . . . 42
9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42 9.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 42
9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43 9.7. Compromised or Malicious Intermediary . . . . . . . . . . 43
10. Internationalization Considerations . . . . . . . . . . . . . 43 10. Internationalization Considerations . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43 11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43
11.2. Organization Identifier Namespace Registry . . . . . . . 44 11.2. Organization Identifier Namespace Registry . . . . . . . 44
12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44 12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
skipping to change at page 10, line 44 skipping to change at page 10, line 44
Some request and response messages in SPPF include time value(s) Some request and response messages in SPPF include time value(s)
defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use defined as type xs:dateTime, a built-in W3C XML Schema Datatype. Use
of unqualified local time value is disallowed as it can lead to of unqualified local time value is disallowed as it can lead to
interoperability issues. The value of a time attribute MUST be interoperability issues. The value of a time attribute MUST be
expressed in Coordinated Universal Time (UTC) format without the expressed in Coordinated Universal Time (UTC) format without the
timezone digits. timezone digits.
"2010-05-30T09:30:10Z" is an example of an acceptable time value for "2010-05-30T09:30:10Z" is an example of an acceptable time value for
use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC use in SPPF messages. "2010-05-30T06:30:10+3:00" is a valid UTC
time, but MUST NOT be used in SPPF messages. time, but not acceptable for use in SPPF messages.
3.3. Extensibility 3.3. Extensibility
The framework contains various points of extensibility in form of the The framework contains various points of extensibility in form of the
"ext" elements. Extensions used beyond the scope of private SPPF "ext" elements. Extensions used beyond the scope of private SPPF
installations need to be documented in an RFC, and the first such installations need to be documented in an RFC, and the first such
extension is expected to define an IANA registry, holding a list of extension is expected to define an IANA registry, holding a list of
documented extensions. documented extensions.
4. Transport Substrate Protocol Requirements 4. Transport Substrate Protocol Requirements
This section provides requirements for substrate protocols suitable This section provides requirements for substrate protocols suitable
as "transports" for SPPF. More specifically, this section specifies to carry SPPF. More specifically, this section specifies the
the services, features, and assumptions that SPPF framework delegates services, features, and assumptions that SPPF framework delegates to
to the chosen substrate and envelope technologies. the chosen substrate and envelope technologies.
4.1. Mandatory Substrate 4.1. Mandatory Substrate
None of the existing transport protocols carried directly over IP, None of the existing transport protocols carried directly over IP,
appearing as "Protocol" in the IPv4 headers, of "Next Header" in the appearing as "Protocol" in the IPv4 headers, or "Next Header" in the
IPv6 headers, meet the requirements for a "transport" listed in this IPv6 headers, meet the requirements listed in this section to carry
section. SPPF.
Therefore, one choice of "transport" has been provided in the SPP Therefore, one choice to carry SPPF has been provided in the SPP
Protocol over SOAP document [I-D.ietf-drinks-spp-protocol-over-soap], Protocol over SOAP document [I-D.ietf-drinks-spp-protocol-over-soap],
using SOAP as the substrate. To encourage interoperability, the SPPF using SOAP as the substrate. To encourage interoperability, the SPPF
server MUST provide support for this protocol. With time, it is server MUST provide support for this protocol. With time, it is
possible that other choices may surface that agree with the possible that other choices may surface that comply with with the
requirements discussed above. requirements discussed above.
4.2. Connection Oriented 4.2. Connection Oriented
The SPPF follows a model where a client establishes a connection to a The SPPF follows a model where a client establishes a connection to a
server in order to further exchange SPPF messages over such a point- server in order to further exchange SPPF messages over such a point-
to-point connection. A substrate protocol for SPPF will therefore be to-point connection. A substrate protocol for SPPF will therefore be
connection oriented. connection oriented.
4.3. Request and Response Model 4.3. Request and Response Model
Provisioning operations in SPPF follow the request-response model, Provisioning operations in SPPF follow the request-response model,
where a client sends a request message to initiate a transaction and where a client sends a request message to initiate a transaction and
the server responds with a response. Multiple subsequent request- the server responds with a response. Multiple subsequent request-
response exchanges MAY be performed over a single persistent response exchanges MAY be performed over a single persistent
connection. connection.
Therefore, a substrate protocol for SPPF will follow the request- Therefore, a substrate protocol for SPPF will follow the request-
response model by ensuring a response to be sent to the request response model by ensuring a response is sent to the request
initiator. initiator.
4.4. Connection Lifetime 4.4. Connection Lifetime
Some use cases involve provisioning a single request to a network Some use cases involve provisioning a single request to a network
element. Connections supporting such provisioning requests might be element. Connections supporting such provisioning requests might be
short-lived, and may be established only on demand, for the duration short-lived, and may be established only on demand, for the duration
of a few seconds. Other use cases involve either provisioning a of a few seconds. Other use cases involve either provisioning a
large dataset, or a constant stream of small updates, either of which large dataset, or a constant stream of small updates, either of which
would likely require long-lived connections, spanning multiple hours would likely require long-lived connections, spanning multiple hours
skipping to change at page 16, line 46 skipping to change at page 16, line 46
</extension> </extension>
</complexContent> </complexContent>
</complexType> </complexType>
A Public Identity object MUST use attributes of PubIdKeyType for its A Public Identity object MUST use attributes of PubIdKeyType for its
unique identification . Refer to Section 6 for a description of unique identification . Refer to Section 6 for a description of
Public Identity object. Public Identity object.
5.3. Response Message Types 5.3. Response Message Types
The following table contains the list of response types a "transport" The following table contains the list of response types which MUST by
definition for a substrate protocol MUST define. An SPPF server MUST defined for a substrate protocol used to carry SPPF. An SPPF server
implement all of the following at minimum. MUST implement all of the following at minimum.
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Response Type | Description | | Response Type | Description |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
| Request Succeeded | A given request succeeded. | | Request Succeeded | A given request succeeded. |
| | | | | |
| Request syntax | The syntax of a given request was found | | Request syntax | The syntax of a given request was found |
| invalid | invalid. | | invalid | invalid. |
| | | | | |
| Request too large | The count of entities in the request is | | Request too large | The count of entities in the request is |
skipping to change at page 39, line 28 skipping to change at page 39, line 28
from amongst the response messages defined in the "Response Message from amongst the response messages defined in the "Response Message
Types" section of the document. Types" section of the document.
8. XML Considerations 8. XML Considerations
XML serves as the encoding format for SPPF, allowing complex XML serves as the encoding format for SPPF, allowing complex
hierarchical data to be expressed in a text format that can be read, hierarchical data to be expressed in a text format that can be read,
saved, and manipulated with both traditional text tools and tools saved, and manipulated with both traditional text tools and tools
specific to XML. specific to XML.
XML is case sensitive. Unless stated otherwise, XML specifications XML is case sensitive. Unless stated otherwise, the character casing
and examples provided in this document MUST be interpreted in the of XML specifications in this document MUST be preserved to develop a
character case presented to develop a conforming implementation. conforming specification.
This section discusses a small number of XML-related considerations This section discusses a small number of XML-related considerations
pertaining to SPPF. pertaining to SPPF.
8.1. Namespaces 8.1. Namespaces
All SPPF elements are defined in the namespaces in the IANA All SPPF elements are defined in the namespaces in the IANA
Considerations section and in the Formal Framework Specification Considerations section and in the Formal Framework Specification
section of this document. section of this document.
skipping to change at page 43, line 7 skipping to change at page 43, line 7
Anti-replay protection ensures that a given SPPF object replayed at a Anti-replay protection ensures that a given SPPF object replayed at a
later time doesn't affect the integrity of the system. SPPF provides later time doesn't affect the integrity of the system. SPPF provides
at least one mechanism to fight against replay attacks. Use of the at least one mechanism to fight against replay attacks. Use of the
optional client transaction identifier allows the SPPF client to optional client transaction identifier allows the SPPF client to
correlate the request message with the response and to be sure that correlate the request message with the response and to be sure that
it is not a replay of a server response from earlier exchanges. Use it is not a replay of a server response from earlier exchanges. Use
of unique values for the client transaction identifier is highly of unique values for the client transaction identifier is highly
encouraged to avoid chance matches to a potential replay message. encouraged to avoid chance matches to a potential replay message.
9.7. Man in the Middle 9.7. Compromised or Malicious Intermediary
The SPPF client or Registrar can be a separate entity acting on The SPPF client or Registrar can be a separate entity acting on
behalf of the Registrant in facilitating provisioning transactions to behalf of the Registrant in facilitating provisioning transactions to
the Registry. Therefore, even though the substrate layer provides the Registry. Therefore, even though the substrate layer provides
end-to-end protection for each specific SPPP connection between end-to-end protection for each specific SPPP connection between
client and server, data might be available in clear text before or client and server, data might be available in clear text before or
after it traverses a SPPP connection. Therefore, a man-in-the-middle after it traverses a SPPP connection. Therefore, a man-in-the-middle
attack by one of the actors is a possibility that could affect the attack by one of the intermediaries is a possibility that could
integrity of the data that belongs to the Registrant and/or expose affect the integrity of the data that belongs to the Registrant and/
peering data to unintended actors. or expose peering data to unintended actors.
10. Internationalization Considerations 10. Internationalization Considerations
Character encodings to be used for SPPF elements are described in Character encodings to be used for SPPF elements are described in
Section 8.2. The use of time elements in the protocol is specified Section 8.2. The use of time elements in the protocol is specified
in Section 3.2. Where human-readable messages that are presented to in Section 3.2. Where human-readable messages that are presented to
an end user are used in the protocol, those messages SHOULD be tagged an end user are used in the protocol, those messages SHOULD be tagged
according to [RFC5646], and the substrate protocol MUST support a according to [RFC5646], and the substrate protocol MUST support a
respective mechanism to transmit such tags together with those human- respective mechanism to transmit such tags together with those human-
readable messages. readable messages.
skipping to change at page 53, line 12 skipping to change at page 53, line 12
Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas Shockey, Samuel Melloul, Sumanth Channabasappa, Syed Ali, Vikas
Bhatia, and Jeremy Barkan. Bhatia, and Jeremy Barkan.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-drinks-spp-protocol-over-soap] [I-D.ietf-drinks-spp-protocol-over-soap]
Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer, Cartwright, K., Bhatia, V., Mule, J., and A. Mayrhofer,
"Session Peering Provisioning (SPP) Protocol over SOAP", "Session Peering Provisioning (SPP) Protocol over SOAP",
draft-ietf-drinks-spp-protocol-over-soap-07 (work in draft-ietf-drinks-spp-protocol-over-soap-08 (work in
progress), October 2014. progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277,
January 1998, <http://www.rfc-editor.org/info/rfc2277>. January 1998, <http://www.rfc-editor.org/info/rfc2277>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
 End of changes. 17 change blocks. 
28 lines changed or deleted 30 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/