draft-ietf-bfd-optimizing-authentication-09.txt   draft-ietf-bfd-optimizing-authentication-10.txt 
Network Working Group M. Jethanandani Network Working Group M. Jethanandani
Internet-Draft VMware Internet-Draft Kloud Services
Intended status: Standards Track A. Mishra Updates: 5880 (if approved) A. Mishra
Expires: June 11, 2020 SES Networks Intended status: Standards Track SES Networks
A. Saxena Expires: January 14, 2021 A. Saxena
Ciena Corporation Ciena Corporation
M. Bhatia M. Bhatia
Nokia Nokia
December 9, 2019 July 13, 2020
Optimizing BFD Authentication Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-09 draft-ietf-bfd-optimizing-authentication-10
Abstract Abstract
This document describes an optimization to BFD Authentication as This document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD RFC5880. described in Section 6.7 of BFD RFC 5880. This document updates RFC
5880.
Requirements Language
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 BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 11, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3 2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 3
3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Authenticating every BFD [RFC5880] packet with a Simple Password, or Authenticating every BFD [RFC5880] packet with a Simple Password, or
with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash
Algorithm (SHA-1) algorithms is computationally intensive process, Algorithm (SHA-1) algorithms is a computationally intensive process.
making it difficult if not impossible to authenticate every packet - This makes it difficult, if not impossible to authenticate every
particularly at faster rates. Also, the recent escalating series of packet - particularly at faster rates. Also, the recent escalating
attacks on MD5 and SHA-1 [SHA-1-attack1] [SHA-1-attack2] raise series of attacks on MD5 and SHA-1 described in Finding Collisions in
concerns about their remaining useful lifetime as outlined in Updated the Full SHA-1 [SHA-1-attack1] and New Collision Search for SHA-1
Security Considerations for the MD5 Message-Digest and the HMAC-MD5 [SHA-1-attack2] raise concerns about their remaining useful lifetime
Algorithm [RFC6151] and Security Considerations for the SHA-0 and as outlined in Updated Security Considerations for the MD5 Message-
SHA-1 Message-Digest Algorithm [RFC6194]. If replaced by stronger Digest and the HMAC-MD5 Algorithm [RFC6151] and Security
algorithms, the computational overhead, will make the task of Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm
authenticating every packet even more difficult to achieve. [RFC6194]. If replaced by stronger algorithms, the computational
overhead, will make the task of authenticating every packet even more
difficult to achieve.
This document proposes that only BFD frames that signal a state This document proposes that only BFD packets that signal a state
change in BFD be authenticated. Rest of the frames can be change, a demand mode change (to D bit) or a poll sequence change (P
transmitted and received without authentication enabled. Most frames or F bit change) in a BFD packet be categorized as a significant
that are transmitted and received have no state change associated change. This document also proposes that all BFD control packets
with them. Limiting authentication to frames that affect a BFD which signal a significant change MUST be authenticated if the
session state allows more sessions to be supported for session's bfd.AuthType is non-zero. Other BFD Control packets MAY be
authentication. Moreover, most BFD frames that signal a state change transmitted and received without the A bit set.
are generally transmitted at a slower interval of 1s leaving enough
time to compute the hash. To detect a Man In the Middle (MITM) Most packets that are transmitted and received have no state change
attack, it is also proposed that a non-state change frame be associated with them. Limiting authentication to packets that affect
authenticated occasionally. The interval of this non-state change a BFD session state allows more sessions to be supported with this
frame can be configured depending on the detect multiplier and the optimized method of authentication. Moreover, most BFD packets that
capability of the system. As an example, this could be equal to the signal a significant change are generally transmitted at a slower
detect multiplier number of packets. interval of 1s, leaving enough time to compute the hash.
To detect a Man In the Middle (MITM) attack, it is also proposed that
a BFD control packet without a significant change be authenticated
occasionally. The interval of this non-state change frame can be
configured depending on the detect multiplier and the capability of
the system. As an example, this could be equal to the detect
multiplier number of packets.
The rest of the document is structured as follows. Section 2 talks The rest of the document is structured as follows. Section 2 talks
about the changes to authentication mode as described in BFD about the changes to authentication mode as described in BFD
[RFC5880]. Section 3 goes into the details of the new Authentication [RFC5880]. Section 3 goes into the details of the new Authentication
TLV. Type.
1.1. Requirements Language
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 BCP 14 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
1.2. Terminology
The following terms used in this document have been defined in BFD
[RFC5880].
o Detect Multiplier
o Detection Time
+--------------+----------------------------------------------------+
| Term | Meaning |
+--------------+----------------------------------------------------+
| significant | State change, a demand model change (to D bit) or |
| change | a poll sequence change (P or F bit). |
| configured | configured authentication periodic interval |
| interval | |
+--------------+----------------------------------------------------+
2. Authentication Mode 2. Authentication Mode
The cryptographic authentication mechanisms specified in BFD The cryptographic authentication mechanisms specified in BFD
[RFC5880] describes enabling and disabling of authentication as a one [RFC5880] describes enabling and disabling of authentication as a one
time operation. As a security precaution, it mentions that time operation. As a security precaution, it mentions that
authentication state be allowed to change at most once. Once authentication state be allowed to change at most once. Once
enabled, every packet must have Authentication Bit set and the enabled, every packet must have Authentication Bit set and the
associated Authentication TLV appended. In addition, it states that associated Authentication Type appended. In addition, it states that
an implementation SHOULD NOT allow the authentication state to be an implementation SHOULD NOT allow the authentication state to be
changed based on the receipt of a BFD Control packet. changed based on the receipt of a BFD Control packet.
This document proposes that the authentication mode be modified to be This document proposes that the authentication mode be modified to be
enabled on demand. Instead of authenticating every packet, BFD peers enabled on demand. Instead of authenticating every packet, BFD peers
are configured for which frames need to be authenticated, and are configured for which packets need to be authenticated, and
authenticate only those frames. Rest of the frames can be authenticate only those packets. Rest of the packets can be
transmitted and received without authentication. For example, the transmitted and received without authentication. For example, the
two ends can be configured such that BFD frames that indicate a state two ends can be configured such that BFD packets that indicate a
change should be authenticated and enable authentication on those significant change should be authenticated and enable authentication
frames only. If the two ends have previously been configured as on those packets only. If the two ends have previously been
such, but at least one side decides not to authenticate a state configured as such, but at least one side decides not to authenticate
change frame, then the BFD session will fail to come up. a significant change frame, then the BFD session will fail to come
up.
This proposal outlines which frames need to be authenticated (carry This proposal outlines which packets need to be authenticated (carry
the A-bit), and which frames can be transmitted or received without the A-bit), and which packets can be transmitted or received without
authentication enabled. A frame that fails authentication is authentication enabled. A frame that fails authentication is
discarded, or a frame that was supposed to be authenticated, but was discarded, or a frame that was supposed to be authenticated, but was
not, e.g. a state-change frame, is discarded. However, there is no not, e.g. a significant change frame, is discarded. However, there
change to the state machine for BFD, as the decision of a state is no change to the state machine for BFD, as the decision of a
change is still decided by how many valid consecutive frames were significant change is still decided by how many valid consecutive
received, authenticated or otherwise. packets were received, authenticated or otherwise.
The state changes for which authentication is being suggested The following table summarizes when the A bit should be set. The
include: table should be read with the column indicating the BFD state the
receiver is currently in, and the row indicating the BFD state the
receiver might transition to based on the packet received. The
interesection of the two indicates whether the received packet should
have the A bit set (Auth), no authentication is needed (NULL), most
packets are NULL AUTH (Select) or the state transition is not
applicable.
Read : On state change from <column> to <row> Read : On state change from <column> to <row>
Auth : Authenticate frame Auth : Authenticate frame
NULL : No Authentication. Use NULL AUTH TLV. NULL : No Authentication. Use NULL AUTH Type.
n/a : Invalid state transition. n/a : Invalid state transition.
Select : Most frames NULL AUTH. Selective (periodic) Select : Most packets NULL AUTH. Selective (periodic)
frames authenticated. packets authenticated.
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+------------+
| | DOWN | INIT | UP | POLL | DEMAND | | | DOWN | INIT | UP | ADMIN DOWN |
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+------------+
| DOWN | NULL | Auth | Auth | Auth | Auth | | DOWN | NULL | Auth | Auth | NULL |
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+------------+
| INIT | Auth | NULL | Auth | Auth | Auth | | INIT | Auth | NULL | n/a | n/a |
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+------------+
| UP | Auth | n/a | Select | Auth | Auth | | UP | Auth | Auth | Select | n/a |
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+------------+
| POLL | Auth | n/a | Auth | Auth | Auth | | ADMIN | NULL | Auth | Auth | NULL |
+--------+--------+--------+--------+--------+--------+ +--------+--------+--------+--------+------------+
| DEMAND | Auth | Auth | Auth | Auth | Auth |
+--------+--------+--------+--------+--------+--------+
Optimized Authentication Map Optimized Authentication Map
All frames already carry the sequence number. The NULL AUTH frames If P or F bit changes value, the packet MUST be authenticated. If
MUST contain the TLV specified in Section 3. This enables a the D bit changes value, the packet MUST be authenticated.
All packets already carry the sequence number. The NULL AUTH packets
MUST contain the Type specified in Section 3. This enables a
monotonically increasing sequence number to be carried in each frame, monotonically increasing sequence number to be carried in each frame,
and prevents man-in-the-middle from capturing and replaying the same and prevents man-in-the-middle from capturing and replaying the same
frame again. Since all frames still carry a sequence number, the frame again. Since all packets still carry a sequence number, the
logic for sequence number maintenance remains unchanged from logic for sequence number maintenance remains unchanged from BFD
[RFC5880]. If at a later time, a different scheme is adopted for [RFC5880]. If at a later time, a different scheme is adopted for
changing sequence number, this method can use the updated scheme changing sequence number, e.g. Secure BFD Sequence Numbers
without any impact. [I-D.ietf-bfd-secure-sequence-numbers], this method can use the
updated scheme without any impact.
Most frames transmitted on a BFD session are BFD CC UP frames. Most packets transmitted on a BFD session are BFD UP packets.
Authenticating a small subset of these frames, for example, a detect Authenticating a small subset of these packets, for example, a detect
multiplier number of packets per configured period, significantly multiplier number of packets per configured period, significantly
reduces the computational demand for the system while maintaining reduces the computational demand for the system while maintaining
security of the session across the configured authentication periods. security of the session across the configured authentication periods.
A minimum of Detect Multiplier packets MUST be transmitted per A minimum of Detect Multiplier packets MUST be transmitted per
configured periodic authentication interval. This ensures that the configured periodic authentication interval. This ensures that the
BFD session should see at least one authenticated packet during that BFD session should see at least one authenticated packet during that
interval. interval.
3. NULL Auth TLV 3. NULL Auth Type
This section describes a new Authentication TLV as: This section describes a new Authentication Type as:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Len | Auth Key ID | Reserved | | Auth Type | Auth Len | Auth Key ID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NULL Auth TLV NULL Auth Type
where: where:
Auth Type: The Authentication Type, which in this case is TBD (NULL Auth Type: The Authentication Type, which in this case is TBD (NULL,
Auth TLV, to be assigned by IANA) to be assigned by IANA)
Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytes Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes
Auth Key ID: The authentication key ID in use for this packet. Must Auth Key ID: The authentication key ID in use for this packet. Must
be set to zero. be set to zero.
Reserved: This byte MUST be set to zero on transmit and ignored on Reserved: This byte MUST be set to zero on transmit and ignored on
receive. receive.
Sequence Number: The sequence number for this packet. Implementation Sequence Number: The sequence number for this packet. Implementation
may use sequence numbers as defined in [RFC5880], or secure sequence may use sequence numbers (bfd.XmitAuthSeq) as defined in BFD
numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. [RFC5880], or secure sequence numbers as defined in Secure BFD
Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers].
The NULL Auth TLV must be used for all frames that are not The NULL Auth Type must be used for all packets that are not
authenticated. This protects against replay-attacks by allowing the authenticated. This protects against replay-attacks by allowing the
session to maintain an incrementing sequence number for all frames session to maintain an incrementing sequence number for all packets
(authenticated and un-authenticated). (authenticated and un-authenticated).
In the future, if a new scheme is adopted for changing the sequence In the future, if a new scheme is adopted for changing the sequence
number, this method can adopt the new scheme without any impact. number, this method can adopt the new scheme without any impact.
4. IANA Considerations 4. IANA Considerations
This document requests an update to the registry titled "BFD This document requests an update to the registry titled "BFD
Authentication Types". IANA is requested to to assign a new BFD Auth Authentication Types". IANA is requested to to assign a new BFD Auth
Type for "NULL Auth TLV" (see Section 3). Type for "NULL" (see Section 3).
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
5. Security Considerations 5. Security Considerations
The approach described in this document enhances the ability to The approach described in this document enhances the ability to
authentication a BFD session by taking away the onerous requirement authenticate a BFD session by taking away the onerous requirement
that every frame be authenticated. By authenticating frames that that every BFD control packet be authenticated. By authenticating
affect the state of the session, the security of the BFD session is packets that affect the state of the session, the security of the BFD
maintained. As such this document does not change the security session is maintained. In this mode, packets that are a significant
considerations for BFD. change but are not authenticated, are dropped by the system.
Therefore, a malicious user that tries to inject a non-authenticated
packet, e.g. with a Down state to take a session down will fail.
That combined with the proposal of using sequence number defined in
Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]
further enhances the security of BFD sessions.
6. References 6. References
6.1. Normative References 6.1. Normative References
[I-D.ietf-bfd-secure-sequence-numbers] [I-D.ietf-bfd-secure-sequence-numbers]
Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and
A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd- A. DeKok, "Secure BFD Sequence Numbers", draft-ietf-bfd-
secure-sequence-numbers-04 (work in progress), August secure-sequence-numbers-05 (work in progress), February
2019. 2020.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References 6.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
skipping to change at page 7, line 16 skipping to change at page 8, line 21
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", 2005. Full SHA-1", 2005.
[SHA-1-attack2] [SHA-1-attack2]
Wang, X., Yao, A., and F. Yao, "New Collision Search for Wang, X., Yao, A., and F. Yao, "New Collision Search for
SHA-1", 2005. SHA-1", 2005.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
VMware Kloud Services
USA USA
Email: mjethanandani@gmail.com Email: mjethanandani@gmail.com
Ashesh Mishra Ashesh Mishra
SES Networks SES Networks
Email: mishra.ashesh@gmail.com Email: mishra.ashesh@gmail.com
Ankur Saxena Ankur Saxena
 End of changes. 37 change blocks. 
112 lines changed or deleted 157 lines changed or added

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