draft-ietf-pana-preauth-09.txt   rfc5873.txt 
PANA Working Group Y. Ohba Internet Engineering Task Force (IETF) Y. Ohba
Internet-Draft Toshiba Request for Comments: 5873 Toshiba
Intended status: Experimental A. Yegin Category: Experimental A. Yegin
Expires: August 14, 2010 Samsung ISSN: 2070-1721 Samsung
February 10, 2010 May 2010
Pre-authentication Support for PANA Pre-Authentication Support for the Protocol for
draft-ietf-pana-preauth-09 Carrying Authentication for Network Access (PANA)
Abstract Abstract
This document defines an extension to the Protocol for carrying This document defines an extension to the Protocol for Carrying
Authentication for Network Access (PANA) for proactively establishing Authentication for Network Access (PANA) for proactively establishing
a PANA security association between a PANA client in one access a PANA Security Association between a PANA Client in one access
network and a PANA authentication agent in another access network to network and a PANA Authentication Agent in another access network to
which the PANA client may move. which the PANA Client may move.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/ietf/1id-abstracts.txt. published for examination, experimental implementation, and
evaluation.
The list of Internet-Draft Shadow Directories can be accessed at This document defines an Experimental Protocol for the Internet
http://www.ietf.org/shadow.html. community. This document is a product of the Internet Engineering
Task Force (IETF). It has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 14, 2010. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5873.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Specification of Requirements . . . . . . . . . . . . . . . 3 1.1. Specification of Requirements . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Pre-authentication Procedure . . . . . . . . . . . . . . . . . 4 3. Pre-Authentication Procedure . . . . . . . . . . . . . . . . . 3
4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6 4. PANA Extensions . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
The Protocol for carrying Authentication for Network Access (PANA) The Protocol for Carrying Authentication for Network Access (PANA)
[RFC5191] carries EAP messages between a PaC (PANA Client) and a PAA [RFC5191] carries Extensible Authentication Protocol (EAP) messages
(PANA Authentication Agent) in the access network. If the PaC is a between a PANA Client (PaC) and a PANA Authentication Agent (PAA) in
mobile device and is capable of moving from one access network to the access network. If the PaC is a mobile device and is capable of
another while running its applications, it is critical for the PaC to moving from one access network to another while running its
perform a handover seamlessly without degrading the performance of applications, it is critical for the PaC to perform a handover
the applications during the handover period. When the handover seamlessly without degrading the performance of the applications
requires the PaC to establish a PANA session with the PAA in the new during the handover period. When the handover requires the PaC to
access network, the signaling to establish the PANA session should be establish a PANA session with the PAA in the new access network, the
completed as fast as possible. See [I-D.ietf-hokey-preauth-ps] for signaling to establish the PANA session should be completed as fast
the handover latency requirements. as possible. See [RFC5836] for the handover latency requirements.
This document defines an extension to the PANA protocol [RFC5191] This document defines an extension to the PANA protocol [RFC5191]
used for proactively executing EAP authentication and establishing a used for proactively executing EAP authentication and establishing a
PANA SA (Security Association) between a PaC in an access network and PANA SA (Security Association) between a PaC in an access network and
a PAA in another access network to which the PaC may move. The a PAA in another access network to which the PaC may move. The
extension to the PANA protocol is designed to realize direct pre- extension to the PANA protocol is designed to realize direct
authentication defined in [I-D.ietf-hokey-preauth-ps]. How to pre-authentication defined in [RFC5836]. How to realize
realize authorization and accounting with the use of the pre- authorization and accounting with the use of the pre-authentication
authentication extension is out of the scope of this document. extension is out of the scope of this document.
1.1. Specification of Requirements 1.1. Specification of Requirements
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
2. Terminology 2. Terminology
The following terms are used in this document in addition to the The following terms are used in this document, in addition to the
terms defined in [RFC5191]. terms defined in [RFC5191].
Serving Network: The access network to which the host is currently Serving Network: The access network to which the host is currently
attached. attached.
Candidate Network: An access network that is a potential target of Candidate Network: An access network that is a potential target of
host's handover. the host's handover.
Serving PAA (SPAA): A PAA that resides in the serving network and Serving PAA (SPAA): A PAA that resides in the serving network and
provides network access authentication for a particular PaC. provides network access authentication for a particular PaC.
Candidate PAA (CPAA): A PAA that resides in a candidate network to Candidate PAA (CPAA): A PAA that resides in a candidate network to
which the PaC may move. A CPAA for a particular PaC may be a SPAA which the PaC may move. A CPAA for a particular PaC may be a SPAA
for another PaC. for another PaC.
Pre-authentication: Pre-authentication refers to EAP pre- Pre-authentication: Pre-authentication refers to EAP
authentication and defined as the utilization of EAP to pre- pre-authentication and is defined as the utilization of EAP to
establish EAP keying material on an authenticator prior to arrival pre-establish EAP keying material on an authenticator prior to
of the peer at the access network served by that authenticator arrival of the peer at the access network served by that
[I-D.ietf-hokey-preauth-ps]. In this draft, EAP pre- authenticator [RFC5836]. In this document, EAP pre-authentication
authentication is performed between a PaC and a CPAA. is performed between a PaC and a CPAA.
3. Pre-authentication Procedure 3. Pre-Authentication Procedure
A PaC that supports pre-authentication may establish a PANA session A PaC that supports pre-authentication may establish a PANA session
for each CPAA. for each CPAA.
There may be several mechanisms for a PaC to discover a CPAA. An IP There may be several mechanisms for a PaC to discover a CPAA. An IP
address of the discovered CPAA is the output of those mechanisms. address of the discovered CPAA is the output of those mechanisms.
PANA pre-authentication is performed between the PaC and CPAA using PANA pre-authentication is performed between the PaC and CPAA using
the discovered IP address of the CPAA. IEEE 802.21 [802.21] the discovered IP address of the CPAA. IEEE 802.21 [802.21]
Information Service MAY be used as a CPAA discovery mechanism. Information Service MAY be used as a CPAA discovery mechanism.
There may be a number of criteria for CPAA selection, the timing to There may be a number of criteria for CPAA selection, the timing to
start pre-authentication and the timing as to when the CPAA becomes start pre-authentication, and the timing as to when the CPAA becomes
the SPAA. Such criteria can be implementation specific and thus are the SPAA. Such criteria can be implementation-specific and thus are
outside the scope of this document. outside the scope of this document.
Pre-authentication is initiated by a PaC in a similar way as normal Pre-authentication is initiated by a PaC in a way similar to normal
authentication. A new 'E' (prE-authentication) bit is defined in the authentication. A new 'E' (prE-authentication) bit is defined in the
PANA header. When pre-authentication is performed, the 'E' (prE- PANA header. When pre-authentication is performed, the 'E'
authentication) bit of PANA messages is set in order to indicate that (prE-authentication) bit of PANA messages is set in order to indicate
this PANA run is for pre-authentication. Use of pre-authentication that this PANA run is for pre-authentication. Use of
is negotiated as follows. pre-authentication is negotiated as follows.
o When a PaC initiates pre-authentication, it sends a PANA-Client- o When a PaC initiates pre-authentication, it sends a PANA-Client-
Initiation (PCI) message with the 'E' (prE-authentication) bit Initiation (PCI) message with the 'E' (prE-authentication) bit
set. The CPAA responds with a PANA-Auth-Request (PAR) message set. The CPAA responds with a PANA-Auth-Request (PAR) message
with the 'S' (Start) and 'E' (prE-authentication) bits set only if with the 'S' (Start) and 'E' (prE-authentication) bits set only if
it supports pre-authentication. Otherwise, the 'E' (prE- it supports pre-authentication. Otherwise, the 'E'
authentication) bit of the PAR message will be cleared according (prE-authentication) bit of the PAR message will be cleared
to Section 6.2 of [RFC5191], which results in a negotiation according to Section 6.2 of [RFC5191], which results in a
failure. negotiation failure.
o Once the PaC and CPAA have successfully negotiated on performing o Once the PaC and CPAA have successfully negotiated on performing
pre-authentication using the 'S' (Start) and 'E' (prE- pre-authentication using the 'S' (Start) and 'E'
authentication) bits, the subsequent PANA messages exchanged (prE-authentication) bits, the subsequent PANA messages exchanged
between them MUST have the 'E' (prE-authentication) bit set until between them MUST have the 'E' (prE-authentication) bit set until
CPAA becomes SPAA of the PaC. The PaC may conduct this exchange the CPAA becomes the SPAA of the PaC. The PaC may conduct this
with more than one CPAA. If the PaC and CPAA have failed to exchange with more than one CPAA. If the PaC and CPAA have failed
negotiate on performing pre-authentication, the PaC or CPAA that to negotiate on performing pre-authentication, the PaC or CPAA
sent a message with both the 'S' (Start) and 'E' (prE- that sent a message with both the 'S' (Start) and 'E'
authentication) bits set MUST discard the message received from (prE-authentication) bits set MUST discard the message received
the peer with 'S' (Start) bit set and the 'E' (prE-authentication) from the peer with 'S' (Start) bit set and the 'E'
bit cleared, which will eventually result in PANA session (prE-authentication) bit cleared, which will eventually result in
termination. PANA session termination.
If IP reconfiguration is needed in the access network associated with If IP reconfiguration is needed in the access network associated with
the CPAA, the 'I' (IP Reconfiguration) bit in PAR messages used for the CPAA, the 'I' (IP Reconfiguration) bit in PAR messages used for
pre-authentication between the PaC and CPAA is also set. The 'I' (IP pre-authentication between the PaC and CPAA is also set. The 'I' (IP
Reconfiguration) bit in these messages takes effect only after the Reconfiguration) bit in these messages takes effect only after the
CPAA becomes the SPAA. CPAA becomes the SPAA.
When a CPAA of the PaC becomes the SPAA due to, e.g., movement of the When a CPAA of the PaC becomes the SPAA, e.g., due to movement of the
PaC, the PaC informs the PAA of the change using PANA-Notification- PaC, the PaC informs the PAA of the change using PANA-Notification-
Request (PNR) and PANA-Notification-Answer (PNA) messages with the Request (PNR) and PANA-Notification-Answer (PNA) messages with the
'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The 'P' (Ping) bit set and the 'E' (prE-authentication) bit cleared. The
'E' (prE-authentication) bit MUST be cleared in subsequent PANA 'E' (prE-authentication) bit MUST be cleared in subsequent PANA
messages. messages.
A PANA SA is required for pre-authentication in order to securely A PANA SA is required for pre-authentication in order to securely
associate the PNR/PNA exchange to the earlier authentication. associate the PNR/PNA exchange to the earlier authentication.
The PANA session between the PaC and a CPAA is deleted by entering The PANA session between the PaC and a CPAA is deleted by entering
the termination phase of the PANA protocol. the termination phase of the PANA protocol.
Example call flows for pre-authentication is shown in Figure 1. Note An example call flow for pre-authentication is shown in Figure 1.
that EAP authentication is performed over PAR and PAN exchanges. Note that EAP authentication is performed over PAR and
PANA-Auth-Answer (PAN) exchanges, including the one with the 'C'
(Complete) bit set.
PaC CPAA PaC CPAA
| | | |
+------------------+ | +------------------+ |
|Pre-authentication| | |Pre-authentication| |
|trigger | | |trigger | |
+------------------+ | +------------------+ |
| PCI w/'E' bit set | | PCI w/'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| PAR w/'S' and 'E' bits set | | PAR w/'S' and 'E' bits set |
skipping to change at page 6, line 37 skipping to change at page 5, line 37
+----------+ | +----------+ |
| PNR w/ 'P' bit set and w/o 'E' bit set | | PNR w/ 'P' bit set and w/o 'E' bit set |
|------------------------------------------------>| |------------------------------------------------>|
| +-----------------+ | +-----------------+
| |CPAA becomes SPAA| | |CPAA becomes SPAA|
| +-----------------+ | +-----------------+
| PNA w/ 'P' bit set and w/o 'E' bit set | | PNA w/ 'P' bit set and w/o 'E' bit set |
|<------------------------------------------------| |<------------------------------------------------|
| | | |
Figure 1: Pre-authentication Call Flow Figure 1: Pre-Authentication Call Flow
4. PANA Extensions 4. PANA Extensions
A new 'E' (prE-authentication) bit is defined in Flags field of PANA A new 'E' (prE-authentication) bit is defined in the Flags field of
header as follows. the PANA header as follows.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R S C A P I E r r r r r r r r r| |R S C A P I E r r r r r r r r r|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E(PrE-authentication) When pre-authentication is performed, the 'E'
(prE-authentication) bit of PANA messages is set in order to 'E' (prE-authentication) bit: When pre-authentication is performed,
indicate whether this PANA run is for pre-authentication. The the 'E' (prE-authentication) bit of PANA messages is set in order
exact usage of this bit is described in Section 3. This bit is to to indicate whether this PANA run is for pre-authentication. The
be assigned by IANA. exact usage of this bit is described in Section 3. Bit 6 has been
assigned by IANA.
5. Backward Compatibility 5. Backward Compatibility
Backward compatibility between a PANA entity that does not support Backward compatibility between a PANA entity that does not support
the pre-authentication extension and another PANA entity that the pre-authentication extension and another PANA entity that
supports the pre-authentication extension is maintained as follows. supports the pre-authentication extension is maintained as follows.
When a PaC that supports the pre-authentication extension initiates When a PaC that supports the pre-authentication extension initiates
PANA pre-authentication by sending a PCI message with the 'E' (prE- PANA pre-authentication by sending a PCI message with the 'E'
authentication) bit set to a PAA that does not support the pre- (prE-authentication) bit set to a PAA that does not support the
authentication extension, the PAA will ignore the E-bit according to pre-authentication extension, the PAA will ignore the 'E'
Section 6.2 of [RFC5191], and try to process the message as a normal (prE-authentication) bit according to Section 6.2 of [RFC5191], and
authentication attempt. As a result, the PaC will receive a PAR try to process the message as a normal authentication attempt. As a
message with the 'E' (prE-authentication) bit cleared. In this case, result, the PaC will receive a PAR message with the 'E'
the negotiation on the use of pre-authentication will fail and (prE-authentication) bit cleared. In this case, the negotiation on
eventually the PANA session will be terminated as described in the use of pre-authentication will fail, and eventually the PANA
Section Section 3. session will be terminated as described in Section 3.
6. Security Considerations 6. Security Considerations
This specification is based on the PANA protocol and it exhibits the This specification is based on the PANA protocol, and it exhibits the
same security properties, except for one important difference: Pre- same security properties, except for one important difference:
authenticating PaCs are not physically connected to an access network Pre-authenticating PaCs are not physically connected to an access
associated with the PAA, but they are connected to some other network network associated with the PAA, but they are connected to some other
somewhere else on the Internet. This distinction can create greater network somewhere else on the Internet. This distinction can create
DoS vulnerability for systems using PANA pre-authentication if greater denial-of-service (DoS) vulnerability for systems using PANA
appropriate measures are not taken. An unprotected PAA can be forced pre-authentication if appropriate measures are not taken. An
to create state by an attacker PaC which merely sends PCI messages. unprotected PAA can be forced to create state by an attacker PaC that
merely sends PCI messages.
[RFC5191] describes how PAA can stay stateless while responding to [RFC5191] describes how the PAA can stay stateless while responding
incoming PCIs. PAAs using pre-authentication SHOULD be following to incoming PCIs. PAAs using pre-authentication SHOULD be following
those guidelines (see [RFC5191] Section 4.1). those guidelines (see [RFC5191], Section 4.1).
Furthermore, it is recommended that PANA pre-authentication messages Furthermore, it is recommended that PANA pre-authentication messages
are only accepted from PaCs originating from well-known IP networks be only accepted from PaCs originating from well-known IP networks
(e.g., physically adjacent networks) for a given PAA. These IP (e.g., physically adjacent networks) for a given PAA. These IP
networks can be used with a white-list implemented either on the networks can be used with a whitelist implemented on either the
firewall protecting the perimeter around the PAA, or on the PAA firewall protecting the perimeter around the PAA or the PAA itself.
itself. This prevention measure SHOULD be used whenever it can be This prevention measure SHOULD be used whenever it can be practically
practically applied to a given deployment. applied to a given deployment.
7. IANA Considerations 7. IANA Considerations
As described in Section 4 and following the new IANA allocation As described in Section 4, and following the new IANA allocation
policy on PANA message [I-D.arkko-pana-iana], bit 6 of the Flags policy on PANA messages [RFC5872], bit 6 of the Flags field of the
field of the PANA Header needs to be assigned by IANA for the 'E' PANA header has been assigned by IANA for the 'E'
(prE-authentication) bit. (prE-authentication) bit.
8. Acknowledgments 8. Acknowledgments
The author would like to thank Basavaraj Patil, Ashutosh Dutta, The authors would like to thank Basavaraj Patil, Ashutosh Dutta,
Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez, Julien Bournelle, Sasikanth Bharadwaj, Subir Das, Rafa Marin Lopez,
Lionel Morand, Victor Fajardo, Glen Zorn, Qin Wu, Jari Arrko, Pasi Lionel Morand, Victor Fajardo, Glen Zorn, Qin Wu, Jari Arkko,
Eronen and Joseph Salowey for their support and valuable feedback. Pasi Eronen, and Joseph Salowey for their support and valuable
feedback.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008. Access (PANA)", RFC 5191, May 2008.
[I-D.arkko-pana-iana] [RFC5872] Arkko, J. and A. Yegin, "IANA Rules for the Protocol for
Arkko, J. and A. Yegin, "IANA Rules for Protocol for
Carrying Authentication for Network Access (PANA)", Carrying Authentication for Network Access (PANA)",
draft-arkko-pana-iana-00 (work in progress), January 2010. RFC 5872, May 2010.
9.2. Informative References 9.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC5836] Ohba, Y., Ed., Wu, Q., Ed., and G. Zorn, Ed., "Extensible
Requirement Levels", BCP 14, RFC 2119, March 1997. Authentication Protocol (EAP) Early Authentication Problem
Statement", RFC 5836, April 2010.
[I-D.ietf-hokey-preauth-ps]
Ohba, Y. and G. Zorn, "Extensible Authentication Protocol
(EAP) Early Authentication Problem Statement",
draft-ietf-hokey-preauth-ps-12 (work in progress),
January 2010.
[802.21] IEEE, "Standard for Local and Metropolitan Area Networks: [802.21] IEEE, "Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", LAN MAN Standards Media Independent Handover Services", LAN MAN Standards
Committee of the IEEE Computer Society 802.21 2008. Committee of the IEEE Computer Society 802.21, 2008.
Authors' Addresses Authors' Addresses
Yoshihiro Ohba Yoshihiro Ohba
Toshiba Corporate Research and Development Center Toshiba Corporate Research and Development Center
1 Komukai-Toshiba-cho 1 Komukai-Toshiba-cho
Saiwai-ku, Kawasaki, Kanagawa 212-8582 Saiwai-ku, Kawasaki, Kanagawa 212-8582
Japan Japan
Phone: +81 44 549 2230 Phone: +81 44 549 2230
Email: yoshihiro.ohba@toshiba.co.jp EMail: yoshihiro.ohba@toshiba.co.jp
Alper Yegin Alper Yegin
Samsung Samsung
Istanbul Istanbul
Turkey Turkey
Email: alper.yegin@yegin.org EMail: alper.yegin@yegin.org
 End of changes. 43 change blocks. 
143 lines changed or deleted 138 lines changed or added

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