draft-ietf-lisp-sec-01.txt   draft-ietf-lisp-sec-02.txt 
Network Working Group F. Maino Network Working Group F. Maino
Internet-Draft V. Ermagan Internet-Draft V. Ermagan
Intended status: Experimental Cisco Systems Intended status: Experimental Cisco Systems
Expires: July 4, 2012 A. Cabellos Expires: September 13, 2012 A. Cabellos
Technical University of Technical University of
Catalonia Catalonia
D. Saucez D. Saucez
INRIA
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
January 1, 2012 March 12, 2012
LISP-Security (LISP-SEC) LISP-Security (LISP-SEC)
draft-ietf-lisp-sec-01.txt draft-ietf-lisp-sec-02.txt
Abstract Abstract
This memo specifies LISP-SEC, a set of security mechanisms that This memo specifies LISP-SEC, a set of security mechanisms that
provide origin authentication, integrity and anti-replay protection provide origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via mapping lookup to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
process. LISP-SEC also enables verification of authorization on EID- process. LISP-SEC also enables verification of authorization on EID-
prefix claims in Map-Reply messages. prefix claims in Map-Reply messages.
Requirements Language Requirements Language
skipping to change at page 1, line 46 skipping to change at page 1, line 47
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 July 4, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4
5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7
5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 7 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 7
5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9
5.3. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . . 10
5.3.1. Map-Reply Record Validation . . . . . . . . . . . . . 12 5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13 5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 12
5.4. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13 5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13
5.5. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13
5.6. Map-Server Processing . . . . . . . . . . . . . . . . . . 14 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14
5.6.1. Map-Server Processing in Proxy mode . . . . . . . . . 15 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 14
5.7. ETR Processing . . . . . . . . . . . . . . . . . . . . . . 15 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 15
5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16
6.2. Random Number Generation . . . . . . . . . . . . . . . . . 16 6.2. Random Number Generation . . . . . . . . . . . . . . . . . 16
6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 16 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . . 17 7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . . 17 7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . . 17
7.3. Key Derivation Functions . . . . . . . . . . . . . . . . . 17 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Locator/ID Separation Protocol [I-D.ietf-lisp] defines a set of The Locator/ID Separation Protocol [I-D.ietf-lisp] defines a set of
functions for routers to exchange information used to map from non- functions for routers to exchange information used to map from non-
routable Endpoint Identifiers (EIDs) to routable Routing Locators routable Endpoint Identifiers (EIDs) to routable Routing Locators
(RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply (RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply
skipping to change at page 6, line 8 skipping to change at page 6, line 8
sent to the Map-Resolver. To provide confidentiality to the ITR- sent to the Map-Resolver. To provide confidentiality to the ITR-
OTK over the path between the ITR and its Map-Resolver, the ITR- OTK over the path between the ITR and its Map-Resolver, the ITR-
OTK SHOULD be encrypted using a preconfigured key shared between OTK SHOULD be encrypted using a preconfigured key shared between
the ITR and the Map-Resolver, similar to the key shared between the ITR and the Map-Resolver, similar to the key shared between
the ETR and the Map-Server in order to secure ETR registration the ETR and the Map-Server in order to secure ETR registration
[I-D.ietf-lisp-ms]. [I-D.ietf-lisp-ms].
o The Map-Resolver decapsulates the ECM message, decrypts the ITR- o The Map-Resolver decapsulates the ECM message, decrypts the ITR-
OTK, if needed, and forwards through the Mapping System the OTK, if needed, and forwards through the Mapping System the
received Map-Request and the ITR-OTK, as part of a new ECM received Map-Request and the ITR-OTK, as part of a new ECM
message. As described in Section 5.5, the LISP Mapping System message. As described in Section 5.6, the LISP Mapping System
delivers the ECM to the appropriate Map-Server, as identified by delivers the ECM to the appropriate Map-Server, as identified by
the EID destination address of the Map-Request. the EID destination address of the Map-Request.
o The Map-Server is configured with the location mappings and policy o The Map-Server is configured with the location mappings and policy
information for the ETR responsible for the destination EID information for the ETR responsible for the destination EID
address. Using this preconfigured information the Map-Server, address. Using this preconfigured information the Map-Server,
after the decapsulation of the ECM message, finds the longest after the decapsulation of the ECM message, finds the longest
match EID-prefix that covers the requested EID in the received match EID-prefix that covers the requested EID in the received
Map-Request. The Map-Server adds this EID-prefix, together with Map-Request. The Map-Server adds this EID-prefix, together with
an HMAC computed using the ITR-OTK, to a new Encapsulated Control an HMAC computed using the ITR-OTK, to a new Encapsulated Control
skipping to change at page 8, line 13 skipping to change at page 8, line 13
LISP-SEC ECM Authentication Data LISP-SEC ECM Authentication Data
AD Type: 1 (LISP-SEC Authentication Data) AD Type: 1 (LISP-SEC Authentication Data)
V: Key Version bit. This bit is toggled when the sender switches V: Key Version bit. This bit is toggled when the sender switches
to a new OTK wrapping key to a new OTK wrapping key
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
Requested HMAC ID: The HMAC algorithm requested by the ITR. See Requested HMAC ID: The HMAC algorithm requested by the ITR. See
Section 5.3 for details. Section 5.4 for details.
OTK Length: The length (in bytes) of the OTK Authentication Data OTK Length: The length (in bytes) of the OTK Authentication Data
(OTK-AD), that contains the OTK Preamble and the OTK. (OTK-AD), that contains the OTK Preamble and the OTK.
OTK Encryption ID: The identifier of the key wrapping algorithm OTK Encryption ID: The identifier of the key wrapping algorithm
used to encrypt the One-Time-Key. When a 128-bit OTK is sent used to encrypt the One-Time-Key. When a 128-bit OTK is sent
unencrypted by the Map-Resolver, the OTK Encryption ID is set to unencrypted by the Map-Resolver, the OTK Encryption ID is set to
NULL_KEY_WRAP_128. See Section 5.4 for more details. NULL_KEY_WRAP_128. See Section 5.5 for more details.
One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When
the OTK is encrypted, this field may carry additional metadata the OTK is encrypted, this field may carry additional metadata
resulting from the key wrapping operation. When a 128-bit OTK is resulting from the key wrapping operation. When a 128-bit OTK is
sent unencrypted by Map-Resolver, the OTK Preamble is set to sent unencrypted by Map-Resolver, the OTK Preamble is set to
0x0000000000000000 (64 bits). See Section 5.4 for details. 0x0000000000000000 (64 bits). See Section 5.5 for details.
One-Time-Key: the OTK encrypted (or not) as specified by OTK One-Time-Key: the OTK encrypted (or not) as specified by OTK
Encryption ID. See Section 5.4 for details. Encryption ID. See Section 5.5 for details.
EID-AD Length: length (in bytes) of the EID Authentication Data EID-AD Length: length (in bytes) of the EID Authentication Data
(EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only
fills the KDF ID field, and all the remaining fields part of the fills the KDF ID field, and all the remaining fields part of the
EID-AD are not present. An EID-AD MAY contain multiple EID- EID-AD are not present. An EID-AD MAY contain multiple EID-
records. Each EID-record is 4-byte long plus the length of the records. Each EID-record is 4-byte long plus the length of the
AFI-encoded EID-prefix. AFI-encoded EID-prefix.
KDF ID: Identifier of the Key Derivation Function used to derive KDF ID: Identifier of the Key Derivation Function used to derive
the MS-OTK. The ITR SHOULD use this field to indicate the the MS-OTK. The ITR SHOULD use this field to indicate the
skipping to change at page 10, line 6 skipping to change at page 10, line 6
LISP-SEC Map-Reply Authentication Data LISP-SEC Map-Reply Authentication Data
AD Type: 1 (LISP-SEC Authentication Data) AD Type: 1 (LISP-SEC Authentication Data)
EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY
contain multiple EID-records. Each EID-record is 4-byte long plus contain multiple EID-records. Each EID-record is 4-byte long plus
the length of the AFI-encoded EID-prefix. the length of the AFI-encoded EID-prefix.
KDF ID: Identifier of the Key Derivation Function used to derive KDF ID: Identifier of the Key Derivation Function used to derive
MS-OTK. See Section 5.6 for more details. MS-OTK. See Section 5.7 for more details.
Record Count: The number of records in this Map-Reply message. A Record Count: The number of records in this Map-Reply message. A
record is comprised of the portion of the packet that is labeled record is comprised of the portion of the packet that is labeled
'Rec' above and occurs the number of times equal to Record Count. 'Rec' above and occurs the number of times equal to Record Count.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and ignored on receipt.
EID HMAC ID: Identifier of the HMAC algorithm used to protect the EID HMAC ID: Identifier of the HMAC algorithm used to protect the
integrity of the EID-AD. See Section 5.6 for more details. integrity of the EID-AD. See Section 5.7 for more details.
EID mask-len: Mask length for EID-prefix. EID mask-len: Mask length for EID-prefix.
EID-AFI: Address family of EID-prefix according to [RFC5226]. EID-AFI: Address family of EID-prefix according to [RFC5226].
EID-prefix: This field contains an EID-prefix that the destination EID-prefix: This field contains an EID-prefix that the destination
ETR is authoritative for, and is the longest match for the ETR is authoritative for, and is the longest match for the
requested EID. requested EID.
EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. EID HMAC: HMAC of the EID-AD, as computed by the Map-Server.
skipping to change at page 10, line 39 skipping to change at page 10, line 39
PKT-AD Length: length (in bytes) of the Packet Authentication Data PKT-AD Length: length (in bytes) of the Packet Authentication Data
(PKT-AD). (PKT-AD).
PKT HMAC ID: Identifier of the HMAC algorithm used to protect the PKT HMAC ID: Identifier of the HMAC algorithm used to protect the
integrity of the Map-reply Location Data. integrity of the Map-reply Location Data.
PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP-
SEC Authentication Data. The scope of the authentication goes SEC Authentication Data. The scope of the authentication goes
from the Map-Reply Type field to the PKT HMAC field included. from the Map-Reply Type field to the PKT HMAC field included.
Before computing the HMAC operation the PKT HMAC field MUST be set Before computing the HMAC operation the PKT HMAC field MUST be set
to 0. See Section 5.7 for more details. to 0. See Section 5.8 for more details.
5.3. ITR Processing 5.3. Map-Register LISP-SEC Extentions
The second bit after the Type field in a Map-Register message is
allocated as the S bit. The S bit indicates to the Map-Server that
the registering ETR is LISP-SEC enabled. An ETR that supports LISP-
SEC MUST set the S bit in its Map-Register messages.
5.4. ITR Processing
Upon creating a Map-Request, the ITR generates a random ITR-OTK that Upon creating a Map-Request, the ITR generates a random ITR-OTK that
is stored locally, together with the nonce generated as specified in is stored locally, together with the nonce generated as specified in
[I-D.ietf-lisp]. [I-D.ietf-lisp].
The Map-Request MUST be encapsulated in an ECM, with the S-bit set to The Map-Request MUST be encapsulated in an ECM, with the S-bit set to
1, to indicate the presence of Authentication Data. If the ITR and 1, to indicate the presence of Authentication Data. If the ITR and
the Map-Resolver are configured with a shared key, the ITR-OTK the Map-Resolver are configured with a shared key, the ITR-OTK
confidentiality SHOULD be protected by wrapping the ITR-OTK with the confidentiality SHOULD be protected by wrapping the ITR-OTK with the
algorithm specified by the OTK Encryption ID field. See Section 5.4 algorithm specified by the OTK Encryption ID field. See Section 5.5
for further details on OTK encryption. for further details on OTK encryption.
The Requested HMAC ID field contains the suggested HMAC algorithm to The Requested HMAC ID field contains the suggested HMAC algorithm to
be used by the Map-Server and the ETR to protect the integrity of the be used by the Map-Server and the ETR to protect the integrity of the
ECM Authentication data and of the Map-Reply. ECM Authentication data and of the Map-Reply.
The KDF ID field, specifies the suggested key derivation function to The KDF ID field, specifies the suggested key derivation function to
be used by the Map-Server to derive the MS-OTK. be used by the Map-Server to derive the MS-OTK.
The EID-AD length is set to 4 bytes, since the Authentication Data The EID-AD length is set to 4 bytes, since the Authentication Data
skipping to change at page 12, line 9 skipping to change at page 12, line 16
ITR's local policy. ITR's local policy.
Each individual Map-Reply EID-record is considered valid only if: (1) Each individual Map-Reply EID-record is considered valid only if: (1)
both EID-AD and PKT-AD are valid, and (2) the intersection of the both EID-AD and PKT-AD are valid, and (2) the intersection of the
EID-prefix in the Map-Reply EID-record with one of the EID-prefixes EID-prefix in the Map-Reply EID-record with one of the EID-prefixes
contained in the EID-AD is not empty. After identifying the Map- contained in the EID-AD is not empty. After identifying the Map-
Reply record as valid, the ITR sets the EID-prefix in the Map-Reply Reply record as valid, the ITR sets the EID-prefix in the Map-Reply
record to the value of the intersection set computed before, and adds record to the value of the intersection set computed before, and adds
the Map-Reply EID-record to its EID-to-RLOC cache, as described in the Map-Reply EID-record to its EID-to-RLOC cache, as described in
[I-D.ietf-lisp]. An example of Map-Reply record validation is [I-D.ietf-lisp]. An example of Map-Reply record validation is
provided in Section 5.3.1. provided in Section 5.4.1.
The ITR SHOULD send SMR triggered Map Requests over the mapping The ITR SHOULD send SMR triggered Map Requests over the mapping
system in order to receive a secure Map-Reply. If an ITR accepts system in order to receive a secure Map-Reply. If an ITR accepts
piggybacked Map-Replies, it SHOULD also send a Map-Request over the piggybacked Map-Replies, it SHOULD also send a Map-Request over the
mapping system in order to securely verify the piggybacked Map-Reply. mapping system in order to securely verify the piggybacked Map-Reply.
5.3.1. Map-Reply Record Validation 5.4.1. Map-Reply Record Validation
The payload of a Map-Reply may contain multiple EID-records. The The payload of a Map-Reply may contain multiple EID-records. The
whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide
integrity protection and origin authentication to the EID-prefix integrity protection and origin authentication to the EID-prefix
records claimed by the ETR. The Authentication Data field of a Map- records claimed by the ETR. The Authentication Data field of a Map-
Reply may contain multiple EID-records in the EID-AD. The EID-AD is Reply may contain multiple EID-records in the EID-AD. The EID-AD is
signed by the Map-Server, with the EID HMAC, to provide integrity signed by the Map-Server, with the EID HMAC, to provide integrity
protection and origin authentication to the EID-prefix records protection and origin authentication to the EID-prefix records
inserted by the Map-Server. inserted by the Map-Server.
skipping to change at page 13, line 18 skipping to change at page 13, line 25
The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache
because it matches the second EID-prefix contained in the EID-AD. because it matches the second EID-prefix contained in the EID-AD.
The EID-record with EID-prefix 1.2.0.0/16 is not processed since it The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
is not included in any of the EID-ADs signed by the Map-Server. A is not included in any of the EID-ADs signed by the Map-Server. A
log message is issued. In this last example the ETR is trying to log message is issued. In this last example the ETR is trying to
over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
only 1.2.3.0/24, hence the EID-record is discarded. only 1.2.3.0/24, hence the EID-record is discarded.
5.3.2. PITR Processing 5.4.2. PITR Processing
The processing performed by a PITR is equivalent to the processing of The processing performed by a PITR is equivalent to the processing of
an ITR. However, if the PITR is directly connected to the ALT, the an ITR. However, if the PITR is directly connected to the ALT, the
PITR performs the functions of both the ITR and the Map-Resolver PITR performs the functions of both the ITR and the Map-Resolver
forwarding the Map-Request encapsulated in an ECM header that forwarding the Map-Request encapsulated in an ECM header that
includes the Authentication Data fields as described in Section 5.5. includes the Authentication Data fields as described in Section 5.6.
5.4. Encrypting and Decrypting an OTK 5.5. Encrypting and Decrypting an OTK
MS-OTK confidentiality is required in the path between the Map-Server MS-OTK confidentiality is required in the path between the Map-Server
and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured
key shared between the Map-Server and the ETR for the purpose of key shared between the Map-Server and the ETR for the purpose of
securing ETR registration [I-D.ietf-lisp-ms]. Similarly, if ITR-OTK securing ETR registration [I-D.ietf-lisp-ms]. Similarly, if ITR-OTK
confidentiality is required in the path between the ITR and the Map- confidentiality is required in the path between the ITR and the Map-
Resolver, the ITR-OTK SHOULD be encrypted with a key shared between Resolver, the ITR-OTK SHOULD be encrypted with a key shared between
the ITR and the Map-Resolver. the ITR and the Map-Resolver.
The OTK is encrypted using the algorithm specified in the OTK The OTK is encrypted using the algorithm specified in the OTK
skipping to change at page 14, line 5 skipping to change at page 14, line 14
When decrypting an encrypted OTK the receiver MUST verify that the When decrypting an encrypted OTK the receiver MUST verify that the
Initialization Value resulting from the AES Key Wrap decryption Initialization Value resulting from the AES Key Wrap decryption
operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails
the receiver MUST discard the entire message. the receiver MUST discard the entire message.
When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set
to NULL_KEY_WRAP_128, and the OTK Preamble is set to to NULL_KEY_WRAP_128, and the OTK Preamble is set to
0x0000000000000000 (64 bits). 0x0000000000000000 (64 bits).
5.5. Map-Resolver Processing 5.6. Map-Resolver Processing
Upon receiving an encapsulated Map-Request with the S-bit set, the Upon receiving an encapsulated Map-Request with the S-bit set, the
Map-Resolver decapsulates the ECM message. The ITR-OTK, if Map-Resolver decapsulates the ECM message. The ITR-OTK, if
encrypted, is decrypted as specified in Section 5.4. encrypted, is decrypted as specified in Section 5.5.
The Map-Resolver, as specified in [I-D.ietf-lisp-ms], originates a The Map-Resolver, as specified in [I-D.ietf-lisp-ms], originates a
new ECM header with the S-bit set, that contains the unencrypted ITR- new ECM header with the S-bit set, that contains the unencrypted ITR-
OTK, as specified in Section 5.4, and the other data derived from the OTK, as specified in Section 5.5, and the other data derived from the
ECM Authentication Data of the received encapsulated Map-Request. ECM Authentication Data of the received encapsulated Map-Request.
The Map-Resolver then forwards the received Map-Request, encapsulated The Map-Resolver then forwards the received Map-Request, encapsulated
in the new ECM header that includes the newly computed Authentication in the new ECM header that includes the newly computed Authentication
Data fields. Data fields.
5.6. Map-Server Processing 5.7. Map-Server Processing
Upon receiving an ECM encapsulated Map-Request with the S-bit set, Upon receiving an ECM encapsulated Map-Request with the S-bit set,
the Map-Server process the Map-Request according to the value of the the Map-Server process the Map-Request according to the value of the
S-bit contained in the Map-Register sent by the ETR during S-bit contained in the Map-Register sent by the ETR during
registration. registration.
If the S-bit contained in the Map-Register was clear the Map-Server If the S-bit contained in the Map-Register was clear the Map-Server
decapsulates the ECM and generates a new ECM encapsulated Map-Request decapsulates the ECM and generates a new ECM encapsulated Map-Request
that does not contain an ECM Authentication Data, as specified in that does not contain an ECM Authentication Data, as specified in
[I-D.ietf-lisp]. The Map-Server does not perform any further LISP- [I-D.ietf-lisp]. The Map-Server does not perform any further LISP-
skipping to change at page 14, line 50 skipping to change at page 15, line 10
the ITR-OTK received with the Map-Request. MS-OTK is derived the ITR-OTK received with the Map-Request. MS-OTK is derived
applying the key derivation function specified in the KDF ID field. applying the key derivation function specified in the KDF ID field.
If the algorithm specified in the KDF ID field is not supported, the If the algorithm specified in the KDF ID field is not supported, the
Map-Server uses a different algorithm to derive the key and updates Map-Server uses a different algorithm to derive the key and updates
the KDF ID field accordingly. the KDF ID field accordingly.
The Map-Server and the ETR MUST be configured with a shared key for The Map-Server and the ETR MUST be configured with a shared key for
mapping registration according to [I-D.ietf-lisp-ms]. If MS-OTK mapping registration according to [I-D.ietf-lisp-ms]. If MS-OTK
confidentiality is required, then the MS-OTK SHOULD be encrypted, by confidentiality is required, then the MS-OTK SHOULD be encrypted, by
wrapping the MS-OTK with the algorithm specified by the OTK wrapping the MS-OTK with the algorithm specified by the OTK
Encryption ID field as specified in Section 5.4. Encryption ID field as specified in Section 5.5.
The Map-Server includes in the EID-AD the longest match registered The Map-Server includes in the EID-AD the longest match registered
EID-prefix for the destination EID, and an HMAC of this EID-prefix. EID-prefix for the destination EID, and an HMAC of this EID-prefix.
The HMAC is keyed with the ITR-OTK contained in the received ECM The HMAC is keyed with the ITR-OTK contained in the received ECM
Authentication Data, and the HMAC algorithm is chosen according to Authentication Data, and the HMAC algorithm is chosen according to
the Requested HMAC ID field. If The Map-Server does not support this the Requested HMAC ID field. If The Map-Server does not support this
algorithm, the Map-Server uses a different algorithm and specifies it algorithm, the Map-Server uses a different algorithm and specifies it
in the EID HMAC ID field. The scope of the HMAC operation covers the in the EID HMAC ID field. The scope of the HMAC operation covers the
entire EID-AD, from the EID-AD Length field to the EID HMAC field, entire EID-AD, from the EID-AD Length field to the EID HMAC field,
which must be set to 0 before the computation. which must be set to 0 before the computation.
The Map-Server then forwards the updated ECM encapsulated Map- The Map-Server then forwards the updated ECM encapsulated Map-
Request, that contains the OTK-AD, the EID-AD, and the received Map- Request, that contains the OTK-AD, the EID-AD, and the received Map-
Request to an authoritative ETR as specified in [I-D.ietf-lisp]. Request to an authoritative ETR as specified in [I-D.ietf-lisp].
5.6.1. Map-Server Processing in Proxy mode 5.7.1. Map-Server Processing in Proxy mode
If the Map-Server is in proxy mode, it generates a Map-Reply, as If the Map-Server is in proxy mode, it generates a Map-Reply, as
specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply
includes the Authentication Data that contains the EID-AD, computed includes the Authentication Data that contains the EID-AD, computed
as specified in Section 5.6, as well as the PKT-AD computed as as specified in Section 5.7, as well as the PKT-AD computed as
specified in Section 5.7. specified in Section 5.8.
5.7. ETR Processing 5.8. ETR Processing
Upon receiving an encapsulated Map-Request with the S-bit set, the Upon receiving an encapsulated Map-Request with the S-bit set, the
ETR decapsulates the ECM message. The OTK field, if encrypted, is ETR decapsulates the ECM message. The OTK field, if encrypted, is
decrypted as specified in Section 5.4 to obtain the unencrypted MS- decrypted as specified in Section 5.5 to obtain the unencrypted MS-
OTK. OTK.
The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp] The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp]
and includes an Authentication Data that contains the EID-AD, as and includes an Authentication Data that contains the EID-AD, as
received in the encapsulated Map-Request, as well as the PKT-AD. received in the encapsulated Map-Request, as well as the PKT-AD.
The EID-AD is copied from the Authentication Data of the received The EID-AD is copied from the Authentication Data of the received
encapsulated Map-Request. encapsulated Map-Request.
The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed
skipping to change at page 19, line 35 skipping to change at page 20, line 4
Email: fmaino@cisco.com Email: fmaino@cisco.com
Vina Ermagan Vina Ermagan
Cisco Systems Cisco Systems
170 Tasman Drive 170 Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Email: vermagan@cisco.com Email: vermagan@cisco.com
Albert Cabellos Albert Cabellos
Technical University of Catalonia Technical University of Catalonia
c/ Jordi Girona s/n c/ Jordi Girona s/n
Barcelona, 08034 Barcelona, 08034
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
Damien Saucez Damien Saucez
Universite catholique de Louvain INRIA
Place St. Barbe 2 2004 route des Lucioles - BP 93
Louvain-la-Neuve, Sophia Antipolis,
Belgium France
Email: damien.saucez@uclouvain.be Email: damien.saucez@inria.fr
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,
Belgium Belgium
Email: olivier.bonaventure@uclouvain.be Email: olivier.bonaventure@uclouvain.be
 End of changes. 36 change blocks. 
45 lines changed or deleted 54 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/