< draft-ietf-soc-load-control-event-package-09.txt   draft-ietf-soc-load-control-event-package-10.txt >
IETF SOC Working Group C. Shen IETF SOC Working Group C. Shen
Internet-Draft H. Schulzrinne Internet-Draft H. Schulzrinne
Intended status: Standards Track Columbia U. Intended status: Standards Track Columbia U.
Expires: January 31, 2014 A. Koike Expires: May 09, 2014 A. Koike
NTT NTT
July 30, 2013 November 05, 2013
A Session Initiation Protocol (SIP) Load Control Event Package A Session Initiation Protocol (SIP) Load Control Event Package
draft-ietf-soc-load-control-event-package-09.txt draft-ietf-soc-load-control-event-package-10.txt
Abstract Abstract
We define a load control event package for the Session Initiation We define a load control event package for the Session Initiation
Protocol (SIP). It allows SIP entities to distribute load filtering Protocol (SIP). It allows SIP entities to distribute load filtering
policies to other SIP entities in the network. The load filtering policies to other SIP entities in the network. The load filtering
policies contain rules to throttle calls based on their source or policies contain rules to throttle calls based on their source or
destination domain, telephone number prefix or for a specific user. destination domain, telephone number prefix or for a specific user.
The mechanism helps to prevent signaling overload and complements The mechanism helps to prevent signaling overload and complements
feedback-based SIP overload control efforts. feedback-based SIP overload control efforts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 31, 2014. This Internet-Draft will expire on May 09, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 22 skipping to change at page 2, line 22
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6
5. SIP Load Filtering Overview . . . . . . . . . . . . . . . . . 6 5. SIP Load Filtering Overview . . . . . . . . . . . . . . . . . 6
5.1. Load Filtering Policy Format . . . . . . . . . . . . . . 6 5.1. Load Filtering Policy Format . . . . . . . . . . . . . . 6
5.2. Load Filtering Policy Computation . . . . . . . . . . . . 7 5.2. Load Filtering Policy Computation . . . . . . . . . . . . 7
5.3. Load Filtering Policy Distribution . . . . . . . . . . . 7 5.3. Load Filtering Policy Distribution . . . . . . . . . . . 7
5.4. Applicable Network Domains . . . . . . . . . . . . . . . 10 5.4. Applicable Network Domains . . . . . . . . . . . . . . . 10
6. Load Control Event Package . . . . . . . . . . . . . . . . . 11 6. Load Control Event Package . . . . . . . . . . . . . . . . . 11
6.1. Event Package Name . . . . . . . . . . . . . . . . . . . 11 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . 11
6.2. Event Package Parameters . . . . . . . . . . . . . . . . 11 6.2. Event Package Parameters . . . . . . . . . . . . . . . . 12
6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 12 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . 12
6.4. SUBSCRIBE Duration . . . . . . . . . . . . . . . . . . . 12 6.4. SUBSCRIBE Duration . . . . . . . . . . . . . . . . . . . 12
6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 12
6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12
6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 12 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . 13
6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 13 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . 13
6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 14 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 14
6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 14 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 15
6.11. State Delta . . . . . . . . . . . . . . . . . . . . . . . 15 6.11. State Delta . . . . . . . . . . . . . . . . . . . . . . . 15
7. Load Control Document . . . . . . . . . . . . . . . . . . . . 15 7. Load Control Document . . . . . . . . . . . . . . . . . . . . 15
7.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 16
7.3. Conditions . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Conditions . . . . . . . . . . . . . . . . . . . . . . . 16
7.3.1. Call Identity . . . . . . . . . . . . . . . . . . . . 16 7.3.1. Call Identity . . . . . . . . . . . . . . . . . . . . 16
7.3.2. Method . . . . . . . . . . . . . . . . . . . . . . . 19 7.3.2. Method . . . . . . . . . . . . . . . . . . . . . . . 19
7.3.3. Target SIP Entity . . . . . . . . . . . . . . . . . . 19 7.3.3. Target SIP Entity . . . . . . . . . . . . . . . . . . 19
7.3.4. Validity . . . . . . . . . . . . . . . . . . . . . . 20 7.3.4. Validity . . . . . . . . . . . . . . . . . . . . . . 20
7.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.5. Complete Examples . . . . . . . . . . . . . . . . . . . . 22 7.5. Complete Examples . . . . . . . . . . . . . . . . . . . . 22
7.5.1. Load Control Document Examples . . . . . . . . . . . 22 7.5.1. Load Control Document Examples . . . . . . . . . . . 22
7.5.2. Message Flow Examples . . . . . . . . . . . . . . . . 25 7.5.2. Message Flow Examples . . . . . . . . . . . . . . . . 25
8. XML Schema Definition for Load Control . . . . . . . . . . . 27 8. XML Schema Definition for Load Control . . . . . . . . . . . 27
9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 30 9. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Relationship with Load Filtering in PSTN . . . . . . . . 30 9.1. Relationship with Load Filtering in PSTN . . . . . . . . 30
9.2. Relationship with Other IETF SIP Overload Control Efforts 31 9.2. Relationship with Other IETF SIP Overload Control Efforts 31
10. Discussion of this specification meeting the requirements of 10. Discussion of this specification meeting the requirements of
RFC5390 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 RFC5390 . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Security Considerations . . . . . . . . . . . . . . . . . . . 37 11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. Load Control Event Package Registration . . . . . . . . 37 12.1. Load Control Event Package Registration . . . . . . . . 38
12.2. application/load-control+xml MIME Registration . . . . . 38 12.2. application/load-control+xml MIME Registration . . . . . 38
12.3. Load Control Schema Registration . . . . . . . . . . . . 39 12.3. Load Control Schema Registration . . . . . . . . . . . . 39
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.1. Normative References . . . . . . . . . . . . . . . . . . 39 14.1. Normative References . . . . . . . . . . . . . . . . . . 40
14.2. Informative References . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Proper functioning of Session Initiation Protocol (SIP) [RFC3261] Proper functioning of Session Initiation Protocol (SIP) [RFC3261]
signaling servers is critical in SIP-based communications networks. signaling servers is critical in SIP-based communications networks.
The performance of SIP servers can be severely degraded when the The performance of SIP servers can be severely degraded when the
server is overloaded with excessive number of signaling requests. server is overloaded with excessive number of signaling requests.
Both legitimate and malicious traffic can overload SIP servers, Both legitimate and malicious traffic can overload SIP servers,
despite appropriate capacity planning. despite appropriate capacity planning.
skipping to change at page 11, line 18 skipping to change at page 11, line 18
o The manner used to determine which SIP entities are part of the o The manner used to determine which SIP entities are part of the
Trust Domain. Trust Domain.
o That SIP entities in the Trust Domain are compliant to SIP o That SIP entities in the Trust Domain are compliant to SIP
[RFC3261] [RFC3261]
o That SIP entities in the Trust Domain are compliant to this o That SIP entities in the Trust Domain are compliant to this
document. document.
o The agreement on what types of calls can be affected by this SIP
load filtering mechanism. For example, call identity condition
elements (Section 7.3.1) <one> and <many> might be limited to
describe specific domains; <many-tel> and <except-tel> might be
limited to describe within certain prefixes.
o The agreement on the destinations to which calls may be redirected
when the "redirect" action (Section 7.4) is used. For example,
the URI might have to match a given set of domains.
It is important to note that effectiveness of SIP load filtering It is important to note that effectiveness of SIP load filtering
requires that all neighbors that are possible signaling sources requires that all neighbors that are possible signaling sources
participate and enforce the designated load filtering policies. participate and enforce the designated load filtering policies.
Otherwise, a single non-conforming neighbor could make the whole Otherwise, a single non-conforming neighbor could make the whole
filtering efforts useless by pumping in excessive traffic to overload filtering efforts useless by pumping in excessive traffic to overload
the server. Therefore, the SIP server that distributes load the server. Therefore, the SIP server that distributes load
filtering policies needs to take counter-measures towards any non- filtering policies needs to take counter-measures towards any non-
conforming neighbors. A simple method is to reject excessive conforming neighbors. A simple method is to reject excessive
requests with 503 (Service Unavailable) response messages as if they requests with 503 (Service Unavailable) response messages as if they
were obeying the rate. Considering the rejection costs, a more were obeying the rate. Considering the rejection costs, a more
skipping to change at page 37, line 41 skipping to change at page 37, line 51
Security considerations for load filtering policy enforcement depends Security considerations for load filtering policy enforcement depends
very much on the contents of the policy. This specification defines very much on the contents of the policy. This specification defines
possible match of the following SIP header fields in a load filtering possible match of the following SIP header fields in a load filtering
policy: <from>, <to>, <request-uri> and <p-asserted-identity>. The policy: <from>, <to>, <request-uri> and <p-asserted-identity>. The
exact requirement to authenticate and authorize these fields is up to exact requirement to authenticate and authorize these fields is up to
the service provider. In general, if the identity field represents the service provider. In general, if the identity field represents
the source of the request, it SHOULD be authenticated and authorized; the source of the request, it SHOULD be authenticated and authorized;
if the identity field represents the destination of the request, the if the identity field represents the destination of the request, the
authentication and authorization is optional. authentication and authorization is optional.
In addition, there could be one specific type of attack around the
use the "redirect" action (Section 7.4). Assuming a number of SIP
proxy servers in a Trust Domain are using UDP, and configured to get
their policies from a central server. An attacker spoofs the central
server's address to send a number of NOTIFY bodies telling the proxy
servers to redirect all calls to victim@outside-of-trust-domain.com.
The proxy servers then redirect all calls to victim, who is then
DoSed off of the Internet. To address this type of threat, this
document requires that a Trust Domain agrees on what types of calls
can be affected as well as on the destinations to which calls may be
redirected, as in Section 5.4.
12. IANA Considerations 12. IANA Considerations
This specification registers a SIP event package, a new MIME type, a This specification registers a SIP event package, a new MIME type, a
new XML namespace, and a new XML schema. new XML namespace, and a new XML schema.
12.1. Load Control Event Package Registration 12.1. Load Control Event Package Registration
This section registers an event package based on the registration This section registers an event package based on the registration
procedures defined in [RFC6665]. procedures defined in [RFC6665].
skipping to change at page 39, line 41 skipping to change at page 40, line 15
of the SOC and SIPPING working group for many helpful comments. In of the SOC and SIPPING working group for many helpful comments. In
particular, Bruno Chatras proposed the <method> and <target-sip- particular, Bruno Chatras proposed the <method> and <target-sip-
entity> condition elements along with many other text improvements. entity> condition elements along with many other text improvements.
Janet Gunn provided detailed text suggestions including Section 10. Janet Gunn provided detailed text suggestions including Section 10.
Eric Noel suggested clarification on load filtering policy Eric Noel suggested clarification on load filtering policy
distribution initialization process. Shida Schubert made many distribution initialization process. Shida Schubert made many
suggestions such as terminology usage. Phil Williams suggested suggestions such as terminology usage. Phil Williams suggested
adding support for delta updates. Ashutosh Dutta gave pointers to adding support for delta updates. Ashutosh Dutta gave pointers to
PSTN references. Adam Roach suggested RFC6665-related and other PSTN references. Adam Roach suggested RFC6665-related and other
helpful clarifications. Richard Barnes made many suggestions such as helpful clarifications. Richard Barnes made many suggestions such as
referencing the Trust Domain concept of RFC3324 and the use of a referencing the Trust Domain concept of RFC3324, the use of a
separate element for 'tel' URI grouping. separate element for 'tel' URI grouping and addressing the "redirect"
action security threat.
14. References 14. References
14.1. Normative References 14.1. Normative References
[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, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
 End of changes. 12 change blocks. 
14 lines changed or deleted 37 lines changed or added

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