draft-ietf-lisp-threats-00.txt   draft-ietf-lisp-threats-01.txt 
Network Working Group D. Saucez Network Working Group D. Saucez
Internet-Draft Universite catholique de Louvain Internet-Draft INRIA
Intended status: Informational L. Iannone Intended status: Informational L. Iannone
Expires: January 3, 2012 Deutsche Telekom Laboratories AG Expires: September 2, 2012 Telekom Innovation Laboratories
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
July 2, 2011 March 1, 2012
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-00.txt draft-ietf-lisp-threats-01.txt
Abstract Abstract
This document analyzes the threats against the security of the This document analyzes the threats against the security of the
Locator/Identifier Separation Protocol and proposes a set of Locator/Identifier Separation Protocol and proposes a set of
recommendations to mitigate some of the identified security risks. recommendations to mitigate some of the identified security risks.
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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2012. This Internet-Draft will expire on September 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
6.3. Attacks not leveraging on the LISP header . . . . . . . . 9 6.3. Attacks not leveraging on the LISP header . . . . . . . . 9
6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10 6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10 6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11 6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11
6.4.3. Attacks using the Nonce-Present and the Echo-Nonce 6.4.3. Attacks using the Nonce-Present and the Echo-Nonce
bits . . . . . . . . . . . . . . . . . . . . . . . . . 12 bits . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13 6.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13
7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13 7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13
7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13 7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13
7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15 7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15
7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 15 7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 16
8. Threats concerning Interworking . . . . . . . . . . . . . . . 17 8. Threats concerning Interworking . . . . . . . . . . . . . . . 17
9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18 9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18
10. Security of the ALT Mapping System . . . . . . . . . . . . . . 20 10. Security of the Proposed Mapping Systems . . . . . . . . . . . 20
11. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 21 10.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 21 10.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 22 11. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 22
12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 23 11.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 23
13. Document Status and Plans . . . . . . . . . . . . . . . . . . 25 11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25
15. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 26 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
17.2. Informative References . . . . . . . . . . . . . . . . . . 27 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 28 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 17.2. Informative References . . . . . . . . . . . . . . . . . . 29
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Requirements notation 1. Requirements notation
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. Introduction 2. Introduction
The Locator/ID Separation Protocol (LISP) is defined in The Locator/ID Separation Protocol (LISP) is defined in
skipping to change at page 13, line 32 skipping to change at page 13, line 32
routing table identified by the attacked Instance ID, however, end- routing table identified by the attacked Instance ID, however, end-
system security is out of the scope of this document. Nevertheless, system security is out of the scope of this document. Nevertheless,
access lists can be configured to protect the network from Instance access lists can be configured to protect the network from Instance
ID based attacks. ID based attacks.
7. Control Plane Threats 7. Control Plane Threats
In this section, we discuss the different types of attacks that can In this section, we discuss the different types of attacks that can
occur when an off-path attacker sends control plane packets. We occur when an off-path attacker sends control plane packets. We
focus on the packets that are sent directly to the ETR and do not focus on the packets that are sent directly to the ETR and do not
analyze the particularities of a LISP mapping system. The ALT analyze the particularities of a LISP mapping system. The LISP+ALT
mapping system is discussed in Section 10. and LISP-DDT mapping systems are discussed in Section 10.
7.1. Attacks with Map-Request messages 7.1. Attacks with Map-Request messages
An off-path attacker could send Map-Request packets to a victim ETR. An off-path attacker could send Map-Request packets to a victim ETR.
In theory, a Map-Request packet is only used to solicit an answer and In theory, a Map-Request packet is only used to solicit an answer and
as such it should not lead to security problems. However, the LISP as such it should not lead to security problems. However, the LISP
specification [I-D.ietf-lisp] contains several particularities that specification [I-D.ietf-lisp] contains several particularities that
could be exploited by an off-path attacker. could be exploited by an off-path attacker.
The first possible exploitation is the P bit. The P bit is used to The first possible exploitation is the P bit. The P bit is used to
skipping to change at page 15, line 36 skipping to change at page 15, line 36
Prefix with an empty locator-set and specifying an action, Prefix with an empty locator-set and specifying an action,
which may be either Drop, Natively forward, or Send Map- which may be either Drop, Natively forward, or Send Map-
Request. Request.
Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
Negative Map-Reply messages are used to support PTR and interconnect Negative Map-Reply messages are used to support PTR and interconnect
the LISP Internet with the legacy Internet. the LISP Internet with the legacy Internet.
Most of the security of the Map-Reply messages depend on the 64 bits Most of the security of the Map-Reply messages depend on the 64 bits
nonce that is included in a Map-Request and returned in the Map- nonce that is included in a Map-Request and returned in the Map-
Reply. An ETR must never accept a Map-Request message whose nonce Reply. An ETR must never accept a Map-Reply message whose nonce does
does not match one of the pending Map-Request messages. If an ETR not match one of the pending Map-Request messages. If an ETR does
does not accept Map-Reply messages with an invalid nonce, the risk of not accept Map-Reply messages with an invalid nonce, the risk of
attack is very small given the size of the nonce (64 bits). attack is acceptable given the size of the nonce (64 bits).
Note, however, that the nonce only confirms that the Map-Reply was Note, however, that the nonce only confirms that the Map-Reply was
sent by the ETR that received the Map-Request. It does not validate sent by the ETR that received the Map-Request. It does not validate
the content of the Map-Reply message. the content of the Map-Reply message.
In addition, an attacker can perform EID-to-RLOC Cache overflow
attack by de-aggregating (i.e., splitting an EID prefix into
artificially smaller EID prefixes) either positive or negative
mappings.
7.3. Gleaning Attacks 7.3. Gleaning Attacks
A third type of attack involves the gleaning mechanism proposed in A third type of attack involves the gleaning mechanism proposed in
[I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the
time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to
learn a mapping from the LISP data encapsulated packets and the Map- learn a mapping from the LISP data encapsulated packets and the Map-
Request packets that it receives. LISP data encapsulated packet Request packets that it receives. LISP data encapsulated packet
contains a source RLOC, destination RLOC, source EID and destination contains a source RLOC, destination RLOC, source EID and destination
EID. When a ITR receives a data encapsulated packet coming from a EID. When a ITR receives a data encapsulated packet coming from a
source EID for which it does not already know a mapping, it may source EID for which it does not already know a mapping, it may
skipping to change at page 20, line 9 skipping to change at page 20, line 46
relies on the received mapping and possible reachability information relies on the received mapping and possible reachability information
to select the RLOC of the ETR that it uses to reach a given EID or to select the RLOC of the ETR that it uses to reach a given EID or
block of EIDs. However, if the ITR made a mistake, e.g., due to block of EIDs. However, if the ITR made a mistake, e.g., due to
configuration, implementation or other types of errors and has chosen configuration, implementation or other types of errors and has chosen
a RLOC that does not serve the destination EID, there is no easy way a RLOC that does not serve the destination EID, there is no easy way
for the LISP ETR to inform the ITR of its mistake. A possible for the LISP ETR to inform the ITR of its mistake. A possible
solution could be to force a ETR to perform a reachability test with solution could be to force a ETR to perform a reachability test with
the selected ITR as soon as it selects it. This will be analyzed in the selected ITR as soon as it selects it. This will be analyzed in
the next version of this document. the next version of this document.
10. Security of the ALT Mapping System 10. Security of the Proposed Mapping Systems
10.1. LISP+ALT
One of the assumptions in [I-D.ietf-lisp] is that the mapping system One of the assumptions in [I-D.ietf-lisp] is that the mapping system
is more secure than sending Map-Request and Map-Reply messages is more secure than sending Map-Request and Map-Reply messages
directly. We analyze this assumption in this section by analyzing directly. We analyze this assumption in this section by analyzing
the security of the ALT mapping system. the security of the ALT mapping system.
The ALT mapping system is basically a manually configured overlay of The ALT mapping system is basically a manually configured overlay of
GRE tunnels between ALT routers. BGP sessions are established GRE tunnels between ALT routers. BGP sessions are established
between ALT routers that are connected through such a tunnel. An ALT between ALT routers that are connected through such a tunnel. An ALT
router advertises the EID prefixes that it serves over its BGP router advertises the EID prefixes that it serves over its BGP
skipping to change at page 21, line 11 skipping to change at page 22, line 5
advertisements and also answer to received Map-Requests without advertisements and also answer to received Map-Requests without
forwarding them to their final destination on the overlay. This forwarding them to their final destination on the overlay. This
could lead to various types of redirection attacks. Note that in could lead to various types of redirection attacks. Note that in
contrast with a regular IP router that could also manipulate in contrast with a regular IP router that could also manipulate in
transit packets, when a malicious or compromised ALT router replies transit packets, when a malicious or compromised ALT router replies
to a Map-Request, it can redirect legitimate traffic for a long to a Map-Request, it can redirect legitimate traffic for a long
period of time by sending an invalid Map-Reply message. Thus, the period of time by sending an invalid Map-Reply message. Thus, the
impact of a malicious ALT router could be much more severe than a impact of a malicious ALT router could be much more severe than a
malicious router in today's Internet. malicious router in today's Internet.
10.2. LISP-DDT
The LISP Delegated Database Tree (LISP-DDT) mapping system is
proposed as an alternative for LISP+ALT [I-D.fuller-lisp-ddt]. LISP-
DDT is a hierarchical distributed database for EID-to-RLOC mappings.
Each DDT node is configured with an EID prefix it owns, as well as
the RLOC addresses and EID prefixes of the LISP-DDT nodes that own a
more specific EID prefix than the one it owns. In LISP-DDT, mappings
are retrieved iteratively. A MR that needs to locate a mapping
traverses the tree of DDT nodes contacting them one after another
until the leaf of the DDT tree that owns the longest matching EID
prefix for the mapping's EID is reached. The MR traverses the
hierarchy of LISP-DDT nodes by sending Map-Requests, with the LISP-
DDT-originated bit set, to LISP-DDT nodes. The MR first contacts the
root of the hierarchy. When a LISP-DDT node receives a Map-Request,
it replies the MR with a Map-Referral that contains the list of the
locators of its childrens that own a prefix that covers the EID in
the Map-Request. The MR then contacts one of these childrens that
will return, at its turn, a Map-Referral. This procedure is
iteratively executed until a Map-Referral marked with the done flag
is received. The locators that appear in a referral with the done
flag are those of the authoritative ETRs for the EID in the Map-
Request. At that moment, the MR falls back to its normal behavior
and sends a Map-Request to the ETR in order for the ITR to obtain the
mapping. It is worth noticing that the MR can cache the referrals to
avoid traversing all the whole hierarchy for every mapping
retrievals.
The operation in LISP-DDT is different from ALT and thus it does not
present the same threats as LISP+ALT. However, threats exist for
LISP-DDT as well. First, a DoS attack can be performed on the MR by
asking her to retrieve a large amount of mappings at the same time.
Indeed, the iterative operation of the MR implies that it has to
maintain state about the ITR that requested the mapping, this in
order to send the final Map-Request to the ETR on behalf of the ITR.
An attacker might leverage on this to fill the MR memory and then
cause a DoS on the MR.
If an attacker manages to compromise a LISP-DDT node it can send fake
referrals to the MR and then control the mappings delivered to the
ITRs. Furthermore, the effects of such an attack can be longer than
the attack itself if the MR caches the referrals.
11. Threats concerning LISP-MS 11. Threats concerning LISP-MS
LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely
the Map Server and the Map-Resolver, that are meant to be used by the Map Server and the Map-Resolver, that are meant to be used by
xTRs to access the mapping system. The advantage is clearly the fact xTRs to access the mapping system. The advantage is clearly the fact
that even if the mapping system changes in time xTRs do not need to that even if the mapping system changes in time xTRs do not need to
change anything since they deal only with Map Servers and Map- change anything since they deal only with Map Servers and Map-
Resolvers. This includes the security aspects, since no change in Resolvers. This includes the security aspects, since no change in
the local security policies is needed. the local security policies is needed.
skipping to change at page 26, line 24 skipping to change at page 28, line 15
15. Security Considerations 15. Security Considerations
Security considerations are the core of this document and do not need Security considerations are the core of this document and do not need
to be further discussed in this section. to be further discussed in this section.
16. Acknowledgments 16. Acknowledgments
The flooding attack and the reference environment were first The flooding attack and the reference environment were first
described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat]. described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat].
We would like to thank Jeff Wheeler for his comments.
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-14 (work in progress), June 2011. draft-ietf-lisp-22 (work in progress), February 2012.
[I-D.ietf-lisp-alt] [I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10
(work in progress), June 2011. (work in progress), December 2011.
[I-D.ietf-lisp-interworking] [I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02 (work in progress), draft-ietf-lisp-interworking-05 (work in progress),
June 2011. February 2012.
[I-D.ietf-lisp-map-versioning] [I-D.ietf-lisp-map-versioning]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map- Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map-
Versioning", draft-ietf-lisp-map-versioning-01 (work in Versioning", draft-ietf-lisp-map-versioning-08 (work in
progress), March 2011. progress), February 2012.
[I-D.ietf-lisp-ms] [I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server", Fuller, V. and D. Farinacci, "LISP Map Server Interface",
draft-ietf-lisp-ms-09 (work in progress), June 2011. draft-ietf-lisp-ms-15 (work in progress), January 2012.
[I-D.ietf-lisp-multicast] [I-D.ietf-lisp-multicast]
Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-06 (work in progress), draft-ietf-lisp-multicast-14 (work in progress),
June 2011. February 2012.
[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.
17.2. Informative References 17.2. Informative References
[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
Century", 75th IETF, Stockholm, July 2009, Century", 75th IETF, Stockholm, July 2009,
<http://tools.ietf.org/wg/savi/>. <http://tools.ietf.org/wg/savi/>.
[I-D.bagnulo-lisp-threat] [I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis", Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-01 (work in progress), draft-bagnulo-lisp-threat-01 (work in progress),
July 2007. July 2007.
[I-D.fuller-lisp-ddt]
Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated
Database Tree", draft-fuller-lisp-ddt-00 (work in
progress), November 2011.
[I-D.ietf-sidr-arch] [I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011. progress), May 2011.
[I-D.ietf-tcpm-tcp-security] [I-D.ietf-tcpm-tcp-security]
Gont, F., "Security Assessment of the Transmission Control Gont, F., "Security Assessment of the Transmission Control
Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in
progress), January 2011. progress), January 2011.
skipping to change at page 28, line 32 skipping to change at page 30, line 28
[SAVI] IETF, "Source Address Validation Improvements Working [SAVI] IETF, "Source Address Validation Improvements Working
Group", <http://tools.ietf.org/wg/savi/>. Group", <http://tools.ietf.org/wg/savi/>.
[Saucez09] [Saucez09]
Saucez, D. and L. Iannone, "How to mitigate the effect of Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems", Submitted to the Trilogy scans on mapping systems", Submitted to the Trilogy
Summer School on Future Internet. Summer School on Future Internet.
Appendix A. Document Change Log Appendix A. Document Change Log
o Version 01 Posted February 2012.
* Added discussion on LISP-DDT in Section 10.2.
o Version 00 Posted July 2011. o Version 00 Posted July 2011.
* Added discussion on LISP-MS in Section 11. * Added discussion on LISP-MS in Section 11.
* Added discussion on Instance ID in Section 6.4. * Added discussion on Instance ID in Section 6.4.
* Editorial polishing of the whole document. * Editorial polishing of the whole document.
* Added "Change Log" appendix to keep track of main changes. * Added "Change Log" appendix to keep track of main changes.
* Renamed "draft-saucez-lisp-security-03.txt. * Renamed "draft-saucez-lisp-security-03.txt.
Authors' Addresses Authors' Addresses
Damien Saucez Damien Saucez
Universite catholique de Louvain INRIA
Place St. Barbe 2 2004 route des Luciolles BP 93
Louvain la Neuve 06902 Sophia Antipolis Cedex
Belgium France
Email: damien.saucez@uclouvain.be Email: damien.saucez@inria.fr
Luigi Iannone Luigi Iannone
Deutsche Telekom Laboratories AG Telekom Innovation Laboratories
Ernst-Reuter Platz 7 Ernst-Reuter Platz 7
Berlin Berlin
Germany Germany
Email: luigi@net.t-labs.tu-berlin.de Email: luigi@net.t-labs.tu-berlin.de
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
Place St. Barbe 2 Place St. Barbe 2
Louvain la Neuve Louvain la Neuve
 End of changes. 25 change blocks. 
45 lines changed or deleted 107 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/