draft-ietf-ipsecme-ikev2-null-auth-01.txt | draft-ietf-ipsecme-ikev2-null-auth-02.txt | |||
---|---|---|---|---|
Network Working Group V. Smyslov | Network Working Group V. Smyslov | |||
Internet-Draft ELVIS-PLUS | Internet-Draft ELVIS-PLUS | |||
Intended status: Standards Track October 22, 2014 | Intended status: Standards Track P. Wouters | |||
Expires: April 25, 2015 | Expires: July 17, 2015 Red Hat | |||
January 13, 2015 | ||||
The NULL Authentication Method in IKEv2 Protocol | The NULL Authentication Method in IKEv2 Protocol | |||
draft-ietf-ipsecme-ikev2-null-auth-01 | draft-ietf-ipsecme-ikev2-null-auth-02 | |||
Abstract | Abstract | |||
This document introduces the NULL authentication method for the IKEv2 | This document specifies the NULL Authentication Method and the | |||
Protocol. This method provides a way to omit peer authentication in | ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This | |||
the IKEv2. It may be used to preserve anonymity of or in the | allows two IKE peers to establish single-side authenticated or mutual | |||
situations, where no trust relationship exists between the parties. | un-authenticated IKE sessions for those use cases where a peer is | |||
unwilling or unable to authenticate itself. This ensures IKEv2 can | ||||
be used for Opportunistic Security (also known as Opportunsitic | ||||
Encryption) to defend against Pervasive Monitoring attacks without | ||||
the need to sacrifice anonimity. | ||||
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 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 April 25, 2015. | This Internet-Draft will expire on July 17, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 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 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 | |||
2. Using the NULL Authentication Method . . . . . . . . . . . . . 4 | 2. Using the NULL Authentication Method . . . . . . . . . . . . . 4 | |||
2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 | 2.1. Authentication Payload . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. Identity Payload . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 4 | 2.3. INITIAL_CONTACT Notification . . . . . . . . . . . . . . . 5 | |||
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1. Audit trail and peer identification . . . . . . . . . . . 6 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 3.2. Resource management and robustness . . . . . . . . . . . . 6 | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . . 9 | 3.3. IKE configuration selection . . . . . . . . . . . . . . . 7 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 3.4. Networking topology changes . . . . . . . . . . . . . . . 7 | |||
3.5. Priviledged IKE operations . . . . . . . . . . . . . . . . 8 | ||||
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | ||||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | ||||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | ||||
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
The Internet Key Exchange Protocol version 2 (IKEv2), specified in | The Internet Key Exchange Protocol version 2 (IKEv2), specified in | |||
[IKEv2], provides a way for two parties to perform authenticated key | [RFC7296], provides a way for two parties to perform an authenticated | |||
exchange. Mutual authentication is mandatory in the IKEv2, so that | key exchange. While the authentication methods used by the peers can | |||
each party must be authenticated by the other. However the | be different, there is no method for one or both parties to remain | |||
authentication methods, used by the peers, need not be the same. | unauthenticated and anonymous. This document extends the | |||
authentication methods to support unauthenticated key exchanges. | ||||
In some situations mutual authentication is undesirable, superfluous | In some situations mutual authentication is undesirable, superfluous | |||
or impossible. For example: | or impossible. The following three examples illustratate these un- | |||
authenticated use cases: | ||||
o User wants to get anonymous access to some server. In this | o A user wants to establish an anonymous secure connection to a | |||
situation he/she should be able to authenticate the server, but to | server. In this situation the user should be able to authenticate | |||
leave out his/her own authentication to preserve anonymity. In | the server without presenting or authenticating to the server with | |||
this case one-way authentication of the responder is desirable. | their own identity. This case uses a single-sided authentication | |||
of the responder. | ||||
o Sensor, that sleeps most of the time, but periodically wakes up, | o A sensor that periodically wakes up from a suspended state wants | |||
makes some measurment (e.g. temperature) and sends the results to | to send a measurement (e.g. temperature) to a collecting server. | |||
some server. The sensor must be authenticated by the server to | The sensor must be authenticated by the server to ensure | |||
ensure authenticity of the measurment, but the server need not be | authenticity of the measurment, but the sensor does not need to | |||
authenticated by the sensor. In this case one-way authentication | authenticate the server. This case uses a single-sided | |||
of the initiator is sufficient. | authentication of the initiator. | |||
o Two peers without any trust relationship want to get some level of | o Two peers without any trust relationship wish to defend against | |||
security in their communications. Without trust relationship they | widespread pervasive monitoring attacks as described in [RFC7258]. | |||
cannot prevent active Man-in-the-Middle attacks, but it is still | Without a trust relationship, the peers cannot authenticate each | |||
possible to prevent passive eavesdropping with opportunistic | other. Opportunistic Security [RFC7435] states that un- | |||
encryption. In this case they can use unauthenticated key | authenticated encrypted communication is prefered over cleartext | |||
exchange. | communication. The peers want to use IKE to setup an un- | |||
authenticated encrypted connection, that gives them protection | ||||
against pervasive monitoring attacks. An attacker that is able | ||||
and willing to send packets can still launch an Man-in-the-Middle | ||||
attack to obtain access to the decrypted communication. This case | ||||
uses a fully anonymous un-authenticated key exchange. | ||||
To meet these needs the document introduces the NULL authentication | To meet these needs this document introduces the NULL authentication | |||
method, which is a "dummy" method, that provides no authentication. | method, and the ID_NULL identity type. This allows an IKE peer to | |||
This allows peer to explicitly indicate to the other side that it is | explicitly indicate that it is unwilling or unable to certify its | |||
unwilling or unable to certify its identity. | identity. | |||
1.1. Conventions Used in This Document | 1.1. Conventions Used in This Document | |||
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 [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
2. Using the NULL Authentication Method | 2. Using the NULL Authentication Method | |||
In IKEv2 each peer independently selects the method to authenticate | In IKEv2, each peer independently selects the method to authenticate | |||
itself to the other side. It means that any of the peers may choose | itself to the other side. A peer may choose to refrain from | |||
to omit its authentication by using the NULL authentication method. | authentication by using the NULL Authentication Method. If a peer | |||
If it is not acceptable for the other peer, it MUST return | that requires authentiation receives an AUTH payload containing the | |||
AUTHENTICATION_FAILED notification. Note, that when the initiator | NULL Authentication Method type, it MUST return an | |||
uses EAP, the responder MUST NOT use the NULL authentication method | AUTHENTICATION_FAILED notification. If an initiator uses EAP, the | |||
(in conformance with the section 2.16 of [IKEv2]). | responder MUST NOT use the NULL Authentication Method (in conformance | |||
with the section 2.16 of [RFC7296]). | ||||
The NULL authentication method affects how the Authentication and the | The NULL Authentication Method affects how the Authentication and the | |||
Identity payloads are formed in the IKE_AUTH exchange. | Identity payloads are formed in the IKE_AUTH exchange. | |||
2.1. Authentication Payload | 2.1. Authentication Payload | |||
Despite the fact that the NULL authentication method provides no | The NULL Authentication Method still requires a properly formed AUTH | |||
authentication, the AUTH payload must still be present in the | payload to be present in the IKE_AUTH exchange messages, as the AUTH | |||
IKE_AUTH exchange messages and must be properly formed, as it | payload cryptographically links the IKE_SA_INIT exchange messages | |||
cryptographically links the IKE_SA_INIT exchange messages with the | with the other messages sent over this IKE SA. | |||
other messages sent over this IKE SA. | ||||
With the NULL authentication method the content of the AUTH payload | When using the NULL Authentication Method, the content of the AUTH | |||
MUST be computed using the syntax for pre-shared secret | payload is computed using the syntax of pre-shared secret | |||
authentication, described in Section 2.15 of [IKEv2]. The values | authentication, described in Section 2.15 of [RFC7296]. The values | |||
SK_pi and SK_pr MUST be used as shared secrets for the content of the | SK_pi and SK_pr are used as shared secrets for the content of the | |||
AUTH payloads generated by the initiator and the responder | AUTH payloads generated by the initiator and the responder | |||
respectively. Note, that this is exactly how the content of the two | respectively. Note that this is identical to how the content of the | |||
last AUTH payloads is calculated for non-key generating EAP method | two last AUTH payloads is generated for the non-key-generating EAP | |||
(see Section 2.16 of [IKEv2] for details). The value for the the | methods (see Section 2.16 of [RFC7296] for details). | |||
NULL authentication method is <TBA by IANA>. | ||||
The KEv2 Authentication Method value for the NULL Authentication | ||||
Method is 13. | ||||
2.2. Identity Payload | 2.2. Identity Payload | |||
The NULL authentication method provides no authentication of the | When a remote peer is not authenticated, any ID presented in the | |||
party using it. For that reason the Identity payload content cannot | Identification Data field of the Identification Payload cannot be | |||
be verified by the peer and MUST be ignored by the IKE. | validated and MUST be ignored. A new Identification Payload ID Type | |||
is introduced to avoid the need of sending a bogus ID Type with | ||||
placeholder data. Furthermore, sending a traditional ID field might | ||||
unwittingly compromise the anonimity of the peer. | ||||
This specification defines new ID Type - ID_NULL, which is intended | This specification defines a new ID Type of ID_NULL, which SHOULD | |||
to be used with the NULL authentication method to explicitely | only be used with the NULL Authentication Method. The Identification | |||
indicate anonymity of the peer. This ID Type MUST NOT be used with | Data field of the Identification Payload MUST be empty. | |||
authentication methods, that provide real authentication. The | ||||
Identification Data in Identity payload for the ID_NULL type MUST be | The IKEv2 Identification Payload ID Type for ID_NULL is 13. | |||
absent and the ID Type is set to <TBA by IANA>. | ||||
2.3. INITIAL_CONTACT Notification | 2.3. INITIAL_CONTACT Notification | |||
The identity of the peer which uses the NULL authentication method | The identity of the peer which uses the NULL Authentication Method | |||
cannot be used to distinguish betweed IKE SAs created by different | cannot be used to distinguish between IKE SAs created by different | |||
peers, because the peers may use the same identity (for example all | peers. For that reason the INITIAL_CONTACT notifications MUST be | |||
endpoints which use identity of type ID_NULL). For that reason the | ignored for IKE SAs using the NULL Authentication Method. | |||
INITIAL_CONTACT notification MUST be ignored if it is present by the | ||||
party using the NULL authentication method. To find out stale IKE | When a new IKE SA is established using the NULL Authentication | |||
SAs in this situation, implementations should perform Liveness Check | Method, implementations MAY perform a Liveness Check on all other IKE | |||
on all IKE SAs with the same peer idenity as the newly created IKE | SAs that were established using the NULL Authentication Method. To | |||
SA. | mitigate the potential impact of sending Liveness Check messages on a | |||
large number of IKE SAs, implementations are advised not to blindly | ||||
perform Liveness Check on every such SA, but to take into | ||||
considerations additional information, that may indicate that the | ||||
particular SA is alive. This information may include the recent | ||||
receipt of cryptographically protected message on the IKE SA or any | ||||
of its Child SAs, or a successfull Liveness Check that was performed | ||||
recently. | ||||
3. Security Considerations | 3. Security Considerations | |||
IKEv2 protocol provides mutual authentication of the peers. If one | If both peers use the NULL Authentication Method, the entire key | |||
peer uses the NULL authentication method, then this peer cannot be | exchange becomes unauthenticated. This makes the IKE session | |||
authenticated by the other side, and it makes authentication in IKEv2 | vulnerable to active Man-in-the-Middle Attacks. Un-authenticated IKE | |||
to be one-way. If both peers use the NULL Authentication method, key | sessions MUST only attempted when authenticated IKE sessions are not | |||
exchange becomes unauthenticated, that makes it susceptible to active | possible for the remote host and the only alternative would be to | |||
attacks. For that reason completely unauthenticated IKE SA must be | send plaintext. See [RFC7435] for details. | |||
used only if the alternative is to send plaintext. | ||||
The identity of the peer using the the NULL authenticated method | Implementations SHOULD use the ID_NULL Identity Type with the NULL | |||
cannot be verified by the other side and, therefore, MUST NOT be used | Authenticated Method. If an un-authenticated remote IKE peer | |||
neither for authorization purposes, nor for policy decisions. All | presents an Identity Type different from ID_NULL, the Identification | |||
peers who use the NULL Authenticated Method should be considered by | Payload data MUST NOT be used for anything except logging. | |||
the other party as "guests" and get the least possible privileges. | ||||
Implementations are advised to use the ID_NULL Identity Type with the | ||||
NULL authenticated method. | ||||
If endpoint receives a request to create an unauthenticated IKE SA | Using an ID Type other than ID_NULL with the NULL Authentication | |||
from the IP address, which is configured on the endpoint to be | Method compromises the client's anonimity. This should be avoided | |||
authenticated, the request SHOULD be rejected. | for regular operation but could be temporarilly enabled, for example | |||
to aid with troubleshooting diagnostics. Sending an unverifiable | ||||
identification for any other purpose is strongly discouraged as it | ||||
leads to a false sense of security, | ||||
If the peer uses the NULL authenticated method, then the content of | IKE implementations without the NULL Authentication Method have | |||
its Traffic Selector payloads must be treated with care. In | always performed mutual authentication and were not designed for use | |||
particular, implementations are advised not to trust blindly that the | with un-authenticated IKE peers. Implementations might have made | |||
public IP addresses the peer put into TS payload are really belong to | assumptions that are no longer valid. Furthermore, the host itself | |||
it. It is RECOMMENDED for security gateways to always assign | might have made trust assumptions or may not be aware of the network | |||
internal IP addresses to unauthenticated clients as described in | topology changes that resulted from IPsec SAs from un-authenticated | |||
Section 2.19 of [IKEv2]. | IKE peers. | |||
3.1. Audit trail and peer identification | ||||
An established IKE session is no longer guaranteed to provide a | ||||
verifiable (authenticated) entity known to the system or network. | ||||
Implementations that add the NULL Authentication Method should audit | ||||
their implementation for any assumptions that depend on IKE peers | ||||
being "friendly", "trusted" or "identifiable". | ||||
3.2. Resource management and robustness | ||||
Section 2.6 of [RFC7296] provides guidance for mitigation of "Denial | ||||
of Service" attacks by issuing COOKIES in response to resource | ||||
consumption of half-open IKE SAs. Furthermore, [DDOS-PROTECTION] | ||||
offers additional counter-meassures in an attempt to distinguish | ||||
attacking IKE packets from legitimate IKE peers. | ||||
These defense mechanisms do not take into account IKE systems that | ||||
allow un-authenticated IKE peers. An attacker using the NULL | ||||
Authentication Method is a fully legitimate IKE peer that is only | ||||
distinguished from authenticated IKE peers by the Authenticaion | ||||
Method | ||||
While implementations should have been written to account for abusive | ||||
authenticated clients, any omission or error in handling abusive | ||||
clients may have gone unnoticed because abusive clients has been a | ||||
rare or non-existent problem. When enabling un-authenticated IKE | ||||
peers, these implementation omissions and errors will be found and | ||||
abused by attackers. For example, an un-authenticated IKE peer could | ||||
send an abusive amount of Liveness probes or Delete requests. | ||||
3.3. IKE configuration selection | ||||
Combining authenticated and un-authenticated IKE peers on a single | ||||
host can be dangerous, assuming the authenticated IKE peer gains more | ||||
or different access from non-authenticated peers (otherwise, why not | ||||
only allow un-authentcated peers). An un-authenticated IKE peer MUST | ||||
NOT be able to reach resources only meant for authenticated IKE peers | ||||
and MUST NOT be able to replace the IPsec SAs of an authenticated IKE | ||||
peer. | ||||
If an IKE peer receives an IKE_AUTH exchange requesting a NULL | ||||
Authentication Method from an IP address that matches a configured | ||||
connection for an authenticated IKE session, it MUST reject the | ||||
IKE_AUTH exchange by sending an AUTHENTICATION_FAILED notification. | ||||
3.4. Networking topology changes | ||||
When a host relies on packet filters or firewall software to protect | ||||
itself, establishing an IKE SA and installing an IPsec SA might | ||||
accidentally circument these packet filters and firewall | ||||
restrictions, as the encrypted ESP (protocol 50) or ESPinUDP (UDP | ||||
port 4500) packets do not match the packet filters defined. IKE | ||||
peers supporting un-authenticated IKE MUST pass all decrypted traffic | ||||
through the same packet filters and security mechanisms as plaintext | ||||
traffic. | ||||
Traffic Selectors and narrowing allow two IKE peers to mutually agree | ||||
on a traffic range for an IPsec SA. An un-authenticated peer MUST | ||||
NOT be allowed to use this mechanism to steal traffic that an IKE | ||||
peer intended to be for another host. This is especially problematic | ||||
when supporting anonymous IKE peers behind NAT, as such IKE peers | ||||
build an IPsec SA using their pre-NAT IP address that are different | ||||
from the source IP of their IKE packets. A rogue IKE peer could use | ||||
malicious Traffic Selectors to obtain access to traffic that the host | ||||
never intended to hand out. Implementations SHOULD restrict and | ||||
isolate all anonymous IKE peers from each other and itself and only | ||||
allow it access to itself and possibly its intended network ranges. | ||||
One of the ways to achive that is to always assign internal IP | ||||
addresses to un-authenticated IKE clients, as described in Section | ||||
2.19 of [RFC7296]. Implementations may also use other techniques, | ||||
such as internal NAT and connection tracking. Implementations MAY | ||||
force un-authenticated IKE peers to single host-to-host IPsec SAs. | ||||
3.5. Priviledged IKE operations | ||||
Some IKE features are not appropriate for un-authenticated IKE peers | ||||
and should be restricted or forbidden. | ||||
4. Acknowledgments | 4. Acknowledgments | |||
The author would like to thank Paul Wouters, Yaron Sheffer and Tero | The authors would like to thank Yaron Sheffer and Tero Kivinen for | |||
Kivinen for their reviews and valuable comments. | their reviews and valuable comments. | |||
5. IANA Considerations | 5. IANA Considerations | |||
This document defines new value in the "IKEv2 Authentication Method" | This document defines a new entry in the "IKEv2 Authentication | |||
registry: | Method" registry: | |||
<TBA> NULL Authentication Method | 13 NULL Authentication Method | |||
It also defines new value in the "IKEv2 Identification Payload ID | This document also defines a new entry in the "IKEv2 Identification | |||
Types" registry: | Payload ID Types" registry: | |||
<TBA> ID_NULL | 13 ID_NULL | |||
6. Normative References | 6. References | |||
6.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. | |||
[IKEv2] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
(IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-04 (work | (IKEv2)", STD 79, RFC 7296, October 2014. | |||
in progress), June 2014. | ||||
Author's Address | 6.2. Informative References | |||
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an | ||||
Attack", BCP 188, RFC 7258, May 2014. | ||||
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection | ||||
Most of the Time", RFC 7435, December 2014. | ||||
[DDOS-PROTECTION] | ||||
Nir, Y., "Protecting Internet Key Exchange (IKE) | ||||
Implementations from Distributed Denial of Service | ||||
Attacks", draft-ietf-ipsecme-ddos-protection-00 (work in | ||||
progress), October 2014. | ||||
Authors' Addresses | ||||
Valery Smyslov | Valery Smyslov | |||
ELVIS-PLUS | ELVIS-PLUS | |||
PO Box 81 | PO Box 81 | |||
Moscow (Zelenograd) 124460 | Moscow (Zelenograd) 124460 | |||
Russian Federation | Russian Federation | |||
Phone: +7 495 276 0211 | Phone: +7 495 276 0211 | |||
Email: svan@elvis.ru | Email: svan@elvis.ru | |||
Paul Wouters | ||||
Red Hat | ||||
Email: pwouters@redhat.com | ||||
End of changes. 35 change blocks. | ||||
115 lines changed or deleted | 239 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |