draft-ietf-sip-fork-loop-fix-01.txt   draft-ietf-sip-fork-loop-fix-02.txt 
Network Working Group R. Sparks, Ed. Network Working Group R. Sparks, Ed.
Internet-Draft Estacado Systems Internet-Draft Estacado Systems
Updates: 3261 (if approved) S. Lawrence Updates: 3261 (if approved) S. Lawrence
Expires: October 2, 2006 Pingtel Corp. Expires: December 27, 2006 Pingtel Corp.
A. Hawrylyshen A. Hawrylyshen
Ditech Communications Corp. Ditech Networks Inc.
March 31, 2006 June 25, 2006
Addressing an Amplification Vulnerability in Forking Proxies Addressing an Amplification Vulnerability in Session Initiation Protocol
draft-ietf-sip-fork-loop-fix-01 (SIP) Forking Proxies
draft-ietf-sip-fork-loop-fix-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 2, 2006. This Internet-Draft will expire on December 27, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document normatively updates RFC 3261, the Session Initiation This document normatively updates RFC 3261, the Session Initiation
Protocol (SIP), to address a security vulnerability identified in SIP Protocol (SIP), to address a security vulnerability identified in SIP
proxy behavior. This vulnerability enables an attack against SIP proxy behavior. This vulnerability enables an attack against SIP
networks where a small number of legitimate, even authorized, SIP networks where a small number of legitimate, even authorized, SIP
requests can stimulate massive amounts of proxy-to-proxy traffic. requests can stimulate massive amounts of proxy-to-proxy traffic.
This document strengthens loop-detection requirements on SIP proxies This document strengthens loop-detection requirements on SIP proxies
when they fork requests (that is, forward a request to more than one when they fork requests (that is, forward a request to more than one
destination). destination). It also corrects and clarifies the description of the
loop-detection algorithm such proxies are required to implement.
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . . 3 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3 3. Vulnerability: Leveraging Forking to Flood a Network . . . . . 3
4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . . 5 4. Normative changes to RFC 3261 . . . . . . . . . . . . . . . . 5
5. Impact on overall network performance . . . . . . . . . . . . . 6 4.1. Strengthening the requirement to perform loop-detection . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Correcting and clarifying the RFC 3261 loop-detection
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 algorithm . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.1. Update to section 16.6 . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2.2. Update to section 16.3 . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6 4.2.3. Note to Implementers . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 7 5. Impact on overall network performance . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Conventions and Definitions 1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
2. Introduction 2. Introduction
Interoperability testing uncovered a vulnerability in the behavior of Interoperability testing uncovered a vulnerability in the behavior of
skipping to change at page 4, line 24 skipping to change at page 4, line 24
To: <sip:a@P2> To: <sip:a@P2>
Contact: <sip:a@P1>, <sip:b@P1> Contact: <sip:a@P1>, <sip:b@P1>
REGISTER sip:P2 SIP/2.0 REGISTER sip:P2 SIP/2.0
To: <sip:b@P2> To: <sip:b@P2>
Contact: <sip:a@P1>, <sip:b@P1> Contact: <sip:a@P1>, <sip:b@P1>
With these bindings in place, introduce an INVITE to any of the four With these bindings in place, introduce an INVITE to any of the four
AoRs, say a@P1. This request will fork to two requests handled by AoRs, say a@P1. This request will fork to two requests handled by
P2, which will fork to four requests handled by P1, which will fork P2, which will fork to four requests handled by P1, which will fork
to eight messages handled by P2, and so on: to eight messages handled by P2, and so on. This message flow is
represented in Figure 2.
| |
a@P1 a@P1
/ \ / \
/ \ / \
/ \ / \
/ \ / \
a@P2 b@P2 a@P2 b@P2
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \ / \ / \ / \
a@P1 b@P1 a@P1 b@P1 a@P1 b@P1 a@P1 b@P1
/ \ / \ / \ / \ / \ / \ / \ / \
a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2 a@P2 b@P2
/\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\ /\
. .
. .
. .
Figure 2 Figure 2: Attack request propagation
Requests will continue to propagate down this tree until Max-Forwards Requests will continue to propagate down this tree until Max-Forwards
reaches zero. If the endpoint and two proxies involved follow RFC reaches zero. If the endpoint and two proxies involved follow RFC
3261 recommendations, the tree will be 70 rows deep, representing 3261 recommendations, the tree will be 70 rows deep, representing
2^70 requests. The actual number of messages may be much larger if 2^70 requests. The actual number of messages may be much larger if
the time to process the entire tree worth of requests is longer than the time to process the entire tree worth of requests is longer than
Timer C at either proxy. In this case, a storm of 408s, and/or a Timer C at either proxy. In this case, a storm of 408s, and/or a
storm of CANCELs will also be propagating through the tree along with storm of CANCELs will also be propagating through the tree along with
the INVITEs. Remember that there are only two proxies involved in the INVITEs. Remember that there are only two proxies involved in
this scenario - each having to hold the state for all the this scenario - each having to hold the state for all the
transactions it sees (at least 2^69 simultaneously active transactions it sees (at least 2^69 simultaneously active
transactions near the end of the scenario). transactions near the end of the scenario).
The attack can be simplified to one account at one server if the The attack can be simplified to one account at one server if the
service can be convinced that contacts with varying attributes service can be convinced that contacts with varying attributes
(parameters, schemes, embedded headers) are sufficiently distinct, (parameters, schemes, embedded headers) are sufficiently distinct,
and these parameters are not used as part of AOR comparisons when and these parameters are not used as part of AOR comparisons when
forwarding a new request. Perhaps: forwarding a new request. Since RFC 3261 mandates that all URI
parameters must be removed from a URI before looking it up in a
location service and that the URIs from the Contact header are
compared using URI equality, the following registration should be
sufficient to set this attack up using a single REGISTER request to a
single account:
REGISTER sip:P1 SIP/2.0 REGISTER sip:P1 SIP/2.0
To: <sip:a@P1> To: <sip:a@P1>
Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud> Contact: <sip:a@P1;unknown-param=whack>,<sip:a@P1;unknown-param=thud>
This attack was realized in practice during one of the SIP This attack was realized in practice during one of the SIP
Interoperability Test (SIPit) sessions. The scenario was extended to Interoperability Test (SIPit) sessions. The scenario was extended to
include more than two proxies, and the participating proxies all include more than two proxies, and the participating proxies all
limited Max-Forwards to be no larger than 20. After a handful of limited Max-Forwards to be no larger than 20. After a handful of
messages to construct the attack, the participating proxies began messages to construct the attack, the participating proxies began
skipping to change at page 5, line 39 skipping to change at page 5, line 45
complete the processing of the single INVITE that initiated the complete the processing of the single INVITE that initiated the
attack. It is interesting to note that a few proxies rebooted during attack. It is interesting to note that a few proxies rebooted during
the scenario, and rejoined in the attack when they restarted (as long the scenario, and rejoined in the attack when they restarted (as long
as they maintained registration state across reboots). This points as they maintained registration state across reboots). This points
out that if this attack were launched on the Internet at large, it out that if this attack were launched on the Internet at large, it
might require coordination among all the affected elements to stop might require coordination among all the affected elements to stop
it. it.
4. Normative changes to RFC 3261 4. Normative changes to RFC 3261
4.1. Strengthening the requirement to perform loop-detection
The following requirements mitigate the risk of a proxy falling The following requirements mitigate the risk of a proxy falling
victim to the attack described in this document. victim to the attack described in this document.
When a SIP proxy forks a particular request to more than one When a SIP proxy forks a particular request to more than one
destination, it MUST ensure that request is not looping through this destination, it MUST ensure that request is not looping through this
proxy. It is RECOMMENDED that proxies meet this requirement by proxy. It is RECOMMENDED that proxies meet this requirement by
performing the Loop-Detection steps defined as an optional step in performing the Loop-Detection steps defined in this document.
Section 16.3 of RFC 3261.
The requirement to use the loop-detection algorithm in RFC 3261 is The requirement to use this document's refinement of the loop-
set at should-strength since it is expected that other mechanisms detection algorithm in RFC 3261 is set at should-strength to allow
that will allow a proxy to determine it is not looping will be for future standards track mechanisms that will allow a proxy to
standardized in the near future. For example, a proxy forking to determine it is not looping. For example, a proxy forking to
destinations established using the sip-outbound mechanism [I-D.ietf- destinations established using the sip-outbound mechanism [I-D.ietf-
sip-outbound] would know those branches will not loop. sip-outbound] would know those branches will not loop.
A SIP proxy forwarding a request to only one location MAY perform A SIP proxy forwarding a request to only one location MAY perform
loop detection but is not required to. When forwarding to only one loop detection but is not required to. When forwarding to only one
location, the amplification risk being exploited is not present, and location, the amplification risk being exploited is not present, and
the Max-Forwards mechanism is sufficient to protect the network. A the Max-Forwards mechanism is sufficient to protect the network. A
proxy is not required to perform loop detection when forwarding a proxy is not required to perform loop detection when forwarding a
request to a single location even if it previously forked that request to a single location even if it happened to have previously
request in its progression through the network. forked that request (and performed loop detection) in its progression
through the network.
4.2. Correcting and clarifying the RFC 3261 loop-detection algorithm
4.2.1. Update to section 16.6
This section replaces all of item 8 in section 16.6 of RFC 3261 (item
8 begins on page 105 and ends on page 106 of RFC 3261).
8. Add a Via header field value
The proxy MUST insert a Via header field value into the copy before
the existing Via header field values. The construction of this value
follows the same guidelines of Section 8.1.1.7. This implies that
the proxy will compute its own branch parameter, which will be
globally unique for that branch, and will contain the requisite magic
cookie. Note that following only the guidelines in Section 8.1.1.7
will result in a branch parameter that will be different for
different instances of a spiraled or looped request through a proxy.
Proxies required to perform loop-detection by RFC XXXX (RFC-Editor:
replace XXXX with the RFC number of this document) have an additional
constraint on the value they place in the Via header field. Such
proxies SHOULD crate a branch value separable into two parts in any
implementation dependent way. The first part MUST satisfy the
constraints of Section 8.1.1.7. The second part is used to perform
loop detection and distinguish loops from spirals.
This second part MUST vary with any field used by the location
service logic in determining where to retarget or forward this
request. This is necessary to distinguish looped requests from
spirals by allowing the proxy to recognize if none of the values
affecting the processing of the request have changed. Hence, The
second part MUST depend at least on the received Request-URI and any
Route header field values in the received request. Implementers need
to take care to include all fields used by the location service logic
in that particular implementation.
This second part MUST NOT include the request method. CANCEL and
non-200 ACK requests MUST have the same branch parameter value as the
corresponding request they cancel or acknowledge. This branch
parameter value is used in correlating those requests at the server
handling them (see Sections 17.2.3 and 9.2).
Open Issue 1 : Why do all the Route header field values need to be
included? Only the top two in the received request will normally
influence processing (in general, the topmost and any others this
proxy removes from the message, plus the topmost in the message
the proxy emits). Can we simplify this to only include those
Route header field values that actually affect the processing of
the message?
Open Issue 2 : RFC 3261 recommends Call-ID, To-tag, and From-tag and
CSeq be included in this second part. Why? This are guaranteed
to be invariant each time the request passes through this proxy.
Further the created value will only be compared with Vias received
from previous times the request went through this proxy, so there
is no possibility of comparing this value with a hash created from
some other request with a different Call-ID, To-tag, or From-tag
or CSeq. I've removed these fields from the recommended set for
this version of the draft.
Open Issue 3 : RFC 3261 recommends including any Proxy-Require and
Proxy-Authorization header field values in the second part. Why
it it valuable to call these out as special cases? What is the
use case where they will be the only thing in a message returning
to a proxy that varies, making the return a spiral instead of a
loop? I haven't been able to remember the motivation - we need to
re-identify that and capture it here or remove the text making
these anything other than a case covered by the abstract "fields
used by the location service logic". This draft is taking the
second option.
4.2.2. Update to section 16.3
This section replaces all of item 4 in section 16.3 of RFC 3261 (item
4 appears on page 95 RFC 3261).
4. Loop Detection Check
Proxies required to perform loop-detection by RFC-XXXX (RFC-Editor:
replace XXXX with the RFC number of this document) MUST perform the
following loop-detection test before forwarding a request. Each Via
header field value in the request whose sent-by value matches a value
placed into previous requests by this proxy MUST be inspected for the
"second part" defined in Section 4.2.1 of RFC-XXXX. This second part
will not be present if the message was not forked when that Via
header field value was added. If the second field is present, the
proxy MUST perform the second part calculation described in
Section 4.2.1 of RFC-XXXX on this request and compare the result to
the value from the Via header field. If these values are equal, the
request has looped and the proxy MUST reject the request with a 482
(Loop Detected) response. If the values differ, the request is
spiraling and processing continues to the next step.
4.2.3. Note to Implementers
A common way to create the second part of the branch parameter value
when forking a request is to compute a cryptographic hash over the
concatenation of the Request-URI, all Route header field values, and
any other values used by the location service logic while processing
this request. An MD5 [RFC1321] hash expressed in hexadecimal (base64
is not permissible for a token) is a reasonable choice of a hash
function.
A common point of failure to interoperate at SIPit events has been
due to parsers objecting to the contents of other's Via header field
values when inspecting the Via stack for loops. Implementers need to
take care to avoid making assumptions about the format of another
element's Via header field value beyond the basic constraints placed
on that format by RFC 3261. In particular, parsing a header field
value with unknown parameter names, parameters with no values,
parameters values with and without quoted strings must not cause an
implementation to fail.
5. Impact on overall network performance 5. Impact on overall network performance
These requirements and the recommendation to use the loop-detection These requirements and the recommendation to use the loop-detection
mechanisms from RFC 3261 make the favorable trade of exponential mechanisms in this document make the favorable trade of exponential
message growth for work that is at worst case order n^2 as a message message growth for work that is at worst case order n^2 as a message
crosses n proxies. Specifically, this work is order m*n where m is crosses n proxies. Specifically, this work is order m*n where m is
the number of proxies in the path that fork the request to more than the number of proxies in the path that fork the request to more than
one location. In practice, m is expected to be small. one location. In practice, m is expected to be small.
The loop detection algorithm expressed in this document requires a
proxy to inspect each Via element in a received request. In the
worst case where a message crosses N proxies, each of which loop
detect, proxy k does k inspections, and the overall number of
inspections spread across the proxies handling this request is the
sum of k from k=1 to k=N = N(N+1)/2.
6. IANA Considerations 6. IANA Considerations
None. None.
7. Security Considerations 7. Security Considerations
This document is entirely about addressing a vulnerability in SIP This document is entirely about documenting and addressing a
proxies as defined by RFC 3261 that can lead to an exponentially vulnerability in SIP proxies as defined by RFC 3261 that can lead to
growing message exchange attack. an exponentially growing message exchange attack.
8. Acknowledgements Alternative solutions that were discussed included
Doing nothing - rely on suing the offender : While systems that have
accounts have logs that can be mined to locate abusers, it isn't
clear that this provides a credible deterrent or defense against
the attack described in this document. Systems that don't
recognize the situation and take corrective/preventative action
are likely to experience failure of a magnitude that precludes
retrieval of the records documenting the setup of the attack. (In
one scenario, the registrations can occur in a radically different
time period than the invite. The invite itself may have come from
an innocent). It's even possible that the scenario may be set up
unintentionally. Furthermore, for some existing deployments, the
cost and audit ability of an account is simply an email address.
Finding someone to punish may be impossible. Finally, there are
individuals who will not respond to any threat of legal action,
and the effect of even a single successful instance of this kind
of attack would be devastating to a service-provider.
Putting a smaller cap on Max-Forwards: The effect of the attack is
exponential with respect to the initial Max-Forwards value.
Turning this value down limits the effect of the attack. This
comes at the expense of severely limiting the reach of requests in
the network, possibly to the point that existing architectures
will begin to fail.
Controlling the number of concurrent requests : Bounding the total
number branches to which the original request can be forwarded
simultaneously limits the impact of the attack at any given point
in time. Proposals for limiting mechanisms where considered, but
no consensus to adopt them currently exists.
Disallowing registration bindings to arbitrary contacts : The way
registration binding is currently defined is a key part of the
success of the kind of attack documented here. The alternative of
limiting registration bindings to allow only binding to the
network element performing the registration, perhaps to the
extreme of ignoring bits provided in the Contact in favor of
transport artifacts observed in the registration request has been
discussed (particularly in the context of the mechanisms being
defined in [I-D.ietf-sip-outbound]. Mechanisms like this may be
considered again in the future, but are currently insufficiently
developed to address the present threat.
Deprecate forking : This attack does not exist in a system that
relies entirely on redirection and initiation of new requests by
the original endpoint. Removing such a large architectural
component from the system at this time was deemed a too extreme
solution.
8. Acknowledgments
Thanks go to the implementors that subjected their code to this Thanks go to the implementors that subjected their code to this
scenario and helped analyze the results at SIPit 17. scenario and helped analyze the results at SIPit 17.
9. References 9. Change Log
9.1. Normative References RFC Editor - Remove this section before publication
9.1. -01 to -02
Integrated several editorial fixes suggested by Jonathan Rosenberg
Noted that the reduction of the attack to a single registration
against a single URI as documented in previous versions, is, in
fact, going to be effective against implementations conforming to
the standards before this repair.
Re-incorporated motivation from the original maxforwards-problem
draft into the security considerations section based on feedback
from Cullen Jennings
Introduced replacement text for the loop detection algorithm
description in RFC 3261, fixing the bug 648 (the topmost Via value
must not be included in the second part) and clarifying the
algorithm. Removed several other fields suggested by 3261 and
placed open issues around their presence.
Added a Notes to Implementors section capturing the "common way"
text and pointing to the interoperability issues that have been
observed with loop detection at previous SIPits
10. References
10.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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
9.2. Informative References 10.2. Informative References
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-03 (work in progress), March 2006. draft-ietf-sip-outbound-03 (work in progress), March 2006.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
Authors' Addresses Authors' Addresses
Robert Sparks (editor) Robert Sparks (editor)
Estacado Systems Estacado Systems
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, Texas 75254-4203 Dallas, Texas 75254-4203
USA USA
Email: RjS@nostrum.com Email: RjS@nostrum.com
skipping to change at page 8, line 27 skipping to change at page 12, line 27
Pingtel Corp. Pingtel Corp.
400 West Cummings Park 400 West Cummings Park
Suite 2200 Suite 2200
Woburn, MA 01801 Woburn, MA 01801
USA USA
Phone: +1 781 938 5306 Phone: +1 781 938 5306
Email: slawrence@pingtel.com Email: slawrence@pingtel.com
Alan Hawrylyshen Alan Hawrylyshen
Ditech Communications Corp. Ditech Networks Inc.
602 - 11 Ave SW 1167 Kensington Rd NW
Suite 310 Suite 200
Calgary, Alberta T2R 1J8 Calgary, Alberta T2N 1X7
Canada Canada
Phone: +1 403 561 7313 Phone: +1 403 806 3366
Email: ahawrylyshen@ditechcom.com Email: ahawrylyshen@ditechnetworks.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 24 change blocks. 
43 lines changed or deleted 260 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/