idnits 2.17.1 draft-ietf-lisp-sec-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 20, 2017) is 2411 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Maino 3 Internet-Draft V. Ermagan 4 Intended status: Experimental Cisco Systems 5 Expires: March 24, 2018 A. Cabellos 6 Universitat Politecnica de Catalunya 7 D. Saucez 8 INRIA 9 September 20, 2017 11 LISP-Security (LISP-SEC) 12 draft-ietf-lisp-sec-13 14 Abstract 16 This memo specifies LISP-SEC, a set of security mechanisms that 17 provides origin authentication, integrity and anti-replay protection 18 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 19 process. LISP-SEC also enables verification of authorization on EID- 20 prefix claims in Map-Reply messages. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 24, 2018. 45 Copyright Notice 47 Copyright (c) 2017 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 64 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 65 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5 66 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 67 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 68 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 69 5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 11 70 5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . 11 71 5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 13 72 5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 14 73 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14 74 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15 75 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 76 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16 77 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17 80 6.2. Random Number Generation . . . . . . . . . . . . . . . . 17 81 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 82 6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17 83 6.5. Provisioning of the shared keys . . . . . . . . . . . . . 18 84 6.6. Reply Attacks . . . . . . . . . . . . . . . . . . . . . . 18 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 86 7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19 87 7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19 88 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19 89 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20 90 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20 91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 92 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 95 1. Introduction 97 The Locator/ID Separation Protocol [RFC6830] is a network-layer-based 98 protocol that enables separation of IP addresses into two new 99 numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators 100 (RLOCs). EID-to-RLOC mappings are stored in a database, the LISP 101 Mapping System, and made available via the Map-Request/Map-Reply 102 lookup process. If these EID-to-RLOC mappings, carried through Map- 103 Reply messages, are transmitted without integrity protection, an 104 adversary can manipulate them and hijack the communication, 105 impersonate the requested EID, or mount Denial of Service or 106 Distributed Denial of Service attacks. Also, if the Map-Reply 107 message is transported unauthenticated, an adversarial LISP entity 108 can overclaim an EID-prefix and maliciously redirect traffic directed 109 to a large number of hosts. The LISP-SEC threat model, described in 110 Section 3, is built on top of the LISP threat model defined in 111 [RFC7835], that includes a detailed description of "overclaiming" 112 attack. 114 This memo specifies LISP-SEC, a set of security mechanisms that 115 provides origin authentication, integrity and anti-replay protection 116 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 117 process. LISP-SEC also enables verification of authorization on EID- 118 prefix claims in Map-Reply messages, ensuring that the sender of a 119 Map-Reply that provides the location for a given EID-prefix is 120 entitled to do so according to the EID prefix registered in the 121 associated Map-Server. Map-Register security, including the right 122 for a LISP entity to register an EID-prefix or to claim presence at 123 an RLOC, is out of the scope of LISP-SEC. Additional security 124 considerations are described in Section 6. 126 2. Definition of Terms 128 One-Time Key (OTK): An ephemeral randomly generated key that must 129 be used for a single Map-Request/Map-Reply exchange. 131 ITR One-Time Key (ITR-OTK): The One-Time Key generated at the ITR. 133 MS One-Time Key (MS-OTK): The One-Time Key generated at the Map- 134 Server. 136 Authentication Data (AD): Metadata that is included either in a 137 LISP Encapsulated Control Message (ECM) header, as defined in 138 Section 6.1.8 of [RFC6830], or in a Map-Reply message to support 139 confidentiality, integrity protection, and verification of EID- 140 prefix authorization. 142 OTK Authentication Data (OTK-AD): The portion of ECM 143 Authentication Data that contains a One-Time Key. 145 EID Authentication Data (EID-AD): The portion of ECM and Map-Reply 146 Authentication Data used for verification of EID-prefix 147 authorization. 149 Packet Authentication Data (PKT-AD): The portion of Map-Reply 150 Authentication Data used to protect the integrity of the Map-Reply 151 message. 153 For definitions of other terms, notably Map-Request, Map-Reply, 154 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server 155 (MS), and Map-Resolver (MR) please consult the LISP specification 156 [RFC6830]. 158 3. LISP-SEC Threat Model 160 LISP-SEC addresses the control plane threats, described in [RFC7835], 161 that target EID-to-RLOC mappings, including manipulations of Map- 162 Request and Map-Reply messages, and malicious ETR EID prefix 163 overclaiming. LISP-SEC makes two main assumptions: (1) the LISP 164 mapping system is expected to deliver a Map-Request message to their 165 intended destination ETR as identified by the EID, and (2) no man-in- 166 the-middle (MITM) attack can be mounted within the LISP Mapping 167 System. How the Mapping System is protected from MITM attacks 168 depends from the particular Mapping Systems used, and is out of the 169 scope of this memo. Furthermore, while LISP-SEC enables detection of 170 EID prefix overclaiming attacks, it assumes that Map-Servers can 171 verify the EID prefix authorization at time of registration. 173 According to the threat model described in [RFC7835] LISP-SEC assumes 174 that any kind of attack, including MITM attacks, can be mounted in 175 the access network, outside of the boundaries of the LISP mapping 176 system. An on-path attacker, outside of the LISP mapping system can, 177 for example, hijack Map-Request and Map-Reply messages, spoofing the 178 identity of a LISP node. Another example of on-path attack, called 179 overclaiming attack, can be mounted by a malicious Egress Tunnel 180 Router (ETR), by overclaiming the EID-prefixes for which it is 181 authoritative. In this way the ETR can maliciously redirect traffic 182 directed to a large number of hosts. 184 4. Protocol Operations 186 The goal of the security mechanisms defined in [RFC6830] is to 187 prevent unauthorized insertion of mapping data by providing origin 188 authentication and integrity protection for the Map-Registration, and 189 by using the nonce to detect unsolicited Map-Reply sent by off-path 190 attackers. 192 LISP-SEC builds on top of the security mechanisms defined in 193 [RFC6830] to address the threats described in Section 3 by leveraging 194 the trust relationships existing among the LISP entities 195 participating to the exchange of the Map-Request/Map-Reply messages. 196 Those trust relationships are used to securely distribute a One-Time 197 Key (OTK) that provides origin authentication, integrity and anti- 198 replay protection to mapping data conveyed via the mapping lookup 199 process, and that effectively prevent overclaiming attacks. The 200 processing of security parameters during the Map-Request/Map-Reply 201 exchange is as follows: 203 o The ITR-OTK is generated and stored at the ITR, and securely 204 transported to the Map-Server. 206 o The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for 207 Message Authentication (HMAC) [RFC2104] that protects the 208 integrity of the mapping data known to the Map-Server to prevent 209 overclaiming attacks. The Map-Server also derives a new OTK, the 210 MS-OTK, that is passed to the ETR, by applying a Key Derivation 211 Function (KDF) to the ITR-OTK. 213 o The ETR uses the MS-OTK to compute an HMAC that protects the 214 integrity of the Map-Reply sent to the ITR. 216 o Finally, the ITR uses the stored ITR-OTK to verify the integrity 217 of the mapping data provided by both the Map-Server and the ETR, 218 and to verify that no overclaiming attacks were mounted along the 219 path between the Map-Server and the ITR. 221 Section 5 provides the detailed description of the LISP-SEC control 222 messages and their processing, while the rest of this section 223 describes the flow of protocol operations at each entity involved in 224 the Map-Request/Map-Reply exchange: 226 o The ITR, upon needing to transmit a Map-Request message, generates 227 and stores an OTK (ITR-OTK). This ITR-OTK is included into the 228 Encapsulated Control Message (ECM) that contains the Map-Request 229 sent to the Map-Resolver. To provide confidentiality to the ITR- 230 OTK over the path between the ITR and its Map-Resolver, the ITR- 231 OTK SHOULD be encrypted using a preconfigured key shared between 232 the ITR and the Map-Resolver, similar to the key shared between 233 the ETR and the Map-Server in order to secure ETR registration 234 [RFC6833]. 236 o The Map-Resolver decapsulates the ECM message, decrypts the ITR- 237 OTK, if needed, and forwards through the Mapping System the 238 received Map-Request and the ITR-OTK, as part of a new ECM 239 message. As described in Section 5.6, the LISP Mapping System 240 delivers the ECM to the appropriate Map-Server, as identified by 241 the EID destination address of the Map-Request. 243 o The Map-Server is configured with the location mappings and policy 244 information for the ETR responsible for the EID destination 245 address. Using this preconfigured information, the Map-Server, 246 after the decapsulation of the ECM message, finds the longest 247 match EID-prefix that covers the requested EID in the received 248 Map-Request. The Map-Server adds this EID-prefix, together with 249 an HMAC computed using the ITR-OTK, to a new Encapsulated Control 250 Message that contains the received Map-Request. 252 o The Map-Server derives a new OTK, the MS-OTK, by applying a Key 253 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included 254 in the Encapsulated Control Message that the Map-Server uses to 255 forward the Map-Request to the ETR. To provide MS-OTK 256 confidentiality over the path between the Map-Server and the ETR, 257 the MS-OTK SHOULD be encrypted using the key shared between the 258 ETR and the Map-Server in order to secure ETR registration 259 [RFC6833]. 261 o If the Map-Server is acting in proxy mode, as specified in 262 [RFC6830], the ETR is not involved in the generation of the Map- 263 Reply. In this case the Map-Server generates the Map-Reply on 264 behalf of the ETR as described below. 266 o The ETR, upon receiving the ECM encapsulated Map-Request from the 267 Map-Server, decrypts the MS-OTK, if needed, and originates a 268 standard Map-Reply that contains the EID-to-RLOC mapping 269 information as specified in [RFC6830]. 271 o The ETR computes an HMAC over this standard Map-Reply, keyed with 272 MS-OTK to protect the integrity of the whole Map-Reply. The ETR 273 also copies the EID-prefix authorization data that the Map-Server 274 included in the ECM encapsulated Map-Request into the Map-Reply 275 message. The ETR then sends this complete Map-Reply message to 276 the requesting ITR. 278 o The ITR, upon receiving the Map-Reply, uses the locally stored 279 ITR-OTK to verify the integrity of the EID-prefix authorization 280 data included in the Map-Reply by the Map-Server. The ITR 281 computes the MS-OTK by applying the same KDF used by the Map- 282 Server, and verifies the integrity of the Map-Reply. If the 283 integrity checks fail, the Map-Reply MUST be discarded. Also, if 284 the EID-prefixes claimed by the ETR in the Map-Reply are not equal 285 or more specific than the EID-prefix authorization data inserted 286 by the Map-Server, the ITR MUST discard the Map-Reply. 288 5. LISP-SEC Control Messages Details 290 LISP-SEC metadata associated with a Map-Request is transported within 291 the Encapsulated Control Message that contains the Map-Request. 293 LISP-SEC metadata associated with the Map-Reply is transported within 294 the Map-Reply itself. 296 5.1. Encapsulated Control Message LISP-SEC Extensions 298 LISP-SEC uses the ECM (Encapsulated Control Message) defined in 299 [RFC6830] with Type set to 8, and S bit set to 1 to indicate that the 300 LISP header includes Authentication Data (AD). The format of the 301 LISP-SEC ECM Authentication Data is defined in the following figure. 302 OTK-AD stands for One-Time Key Authentication Data and EID-AD stands 303 for EID Authentication Data. 305 0 1 2 3 306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | ECM AD Type |V| Reserved | Requested HMAC ID | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 310 | OTK Length | OTK Encryption ID | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 312 | One-Time-Key Preamble ... | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD 314 | ... One-Time-Key Preamble | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 316 ~ One-Time Key (128 bits) ~/ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 318 | EID-AD Length | KDF ID | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 320 | Record Count | Reserved | EID HMAC ID |EID-AD 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 322 | Reserved | EID mask-len | EID-AFI | | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 324 ~ EID-prefix ... ~ | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 326 ~ EID HMAC ~ | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 329 LISP-SEC ECM Authentication Data 331 ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 333 V: Key Version bit. This bit is toggled when the sender switches 334 to a new OTK wrapping key 336 Reserved: Set to 0 on transmission and ignored on receipt. 338 Requested HMAC ID: The HMAC algorithm requested by the ITR. See 339 Section 5.4 for details. 341 OTK Length: The length (in bytes) of the OTK Authentication Data 342 (OTK-AD), that contains the OTK Preamble and the OTK. 344 OTK Encryption ID: The identifier of the key wrapping algorithm 345 used to encrypt the One-Time-Key. When a 128-bit OTK is sent 346 unencrypted by the Map-Resolver, the OTK Encryption ID is set to 347 NULL_KEY_WRAP_128. See Section 5.5 for more details. 349 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 350 the OTK is encrypted, this field MAY carry additional metadata 351 resulting from the key wrapping operation. When a 128-bit OTK is 352 sent unencrypted by Map-Resolver, the OTK Preamble is set to 353 0x0000000000000000 (64 bits). See Section 5.5 for details. 355 One-Time-Key: the OTK encrypted (or not) as specified by OTK 356 Encryption ID. See Section 5.5 for details. 358 EID-AD Length: length (in bytes) of the EID Authentication Data 359 (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only 360 fills the KDF ID field, and all the remaining fields part of the 361 EID-AD are not present. An EID-AD MAY contain multiple EID- 362 records. Each EID-record is 4-byte long plus the length of the 363 AFI-encoded EID-prefix. 365 KDF ID: Identifier of the Key Derivation Function used to derive 366 the MS-OTK. The ITR MAY use this field to indicate the 367 recommended KDF algorithm, according to local policy. The Map- 368 Server can overwrite the KDF ID if it does not support the KDF ID 369 recommended by the ITR. See Section 5.4 for more details. 371 Record Count: The number of records in this Map-Request message. 372 A record is comprised of the portion of the packet that is labeled 373 'Rec' above and occurs the number of times equal to Record Count. 375 Reserved: Set to 0 on transmission and ignored on receipt. 377 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 378 integrity of the EID-AD. This field is filled by Map-Server that 379 computed the EID-prefix HMAC. See Section 5.4 for more details. 381 EID mask-len: Mask length for EID-prefix. 383 EID-AFI: Address family of EID-prefix according to [RFC5226] 385 EID-prefix: The Map-Server uses this field to specify the EID- 386 prefix that the destination ETR is authoritative for, and is the 387 longest match for the requested EID. 389 EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. 390 Before computing the HMAC operation the EID HMAC field MUST be set 391 to 0. The HMAC covers the entire EID-AD. 393 5.2. Map-Reply LISP-SEC Extensions 395 LISP-SEC uses the Map-Reply defined in [RFC6830], with Type set to 2, 396 and S bit set to 1 to indicate that the Map-Reply message includes 397 Authentication Data (AD). The format of the LISP-SEC Map-Reply 398 Authentication Data is defined in the following figure. PKT-AD is 399 the Packet Authentication Data that covers the Map-Reply payload. 401 0 1 2 3 402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | MR AD Type | Reserved | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 406 | EID-AD Length | KDF ID | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 408 | Record Count | Reserved | EID HMAC ID |EID-AD 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 410 | Reserved | EID mask-len | EID-AFI | | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 412 ~ EID-prefix ... ~ | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 414 ~ EID HMAC ~ | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 416 | PKT-AD Length | PKT HMAC ID |\ 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 418 ~ PKT HMAC ~PKT-AD 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 421 LISP-SEC Map-Reply Authentication Data 423 MR AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 425 EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY 426 contain multiple EID-records. Each EID-record is 4-byte long plus 427 the length of the AFI-encoded EID-prefix. 429 KDF ID: Identifier of the Key Derivation Function used to derive 430 MS-OTK. See Section 5.7 for more details. 432 Record Count: The number of records in this Map-Reply message. A 433 record is comprised of the portion of the packet that is labeled 434 'Rec' above and occurs the number of times equal to Record Count. 436 Reserved: Set to 0 on transmission and ignored on receipt. 438 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 439 integrity of the EID-AD. See Section 5.7 for more details. 441 EID mask-len: Mask length for EID-prefix. 443 EID-AFI: Address family of EID-prefix according to [RFC5226]. 445 EID-prefix: This field contains an EID-prefix that the destination 446 ETR is authoritative for, and is the longest match for the 447 requested EID. 449 EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. 450 Before computing the HMAC operation the EID HMAC field MUST be set 451 to 0. The HMAC covers the entire EID-AD. 453 PKT-AD Length: length (in bytes) of the Packet Authentication Data 454 (PKT-AD). 456 PKT HMAC ID: Identifier of the HMAC algorithm used to protect the 457 integrity of the Map-reply. 459 PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- 460 SEC Authentication Data. The scope of the authentication goes 461 from the Map-Reply Type field to the PKT HMAC field included. 462 Before computing the HMAC operation the PKT HMAC field MUST be set 463 to 0. See Section 5.8 for more details. 465 5.3. Map-Register LISP-SEC Extentions 467 This memo is allocating one of the bits marked as Reserved in the 468 Map-Register message defined in Section 6.1.6 of [RFC6830]. More 469 precisely, the second bit after the Type field in a Map-Register 470 message is allocated as the S bit. The S bit indicates to the Map- 471 Server that the registering ETR is LISP-SEC enabled. An ETR that 472 supports LISP-SEC MUST set the S bit in its Map-Register messages. 474 5.4. ITR Processing 476 Upon creating a Map-Request, the ITR generates a random ITR-OTK that 477 is stored locally, together with the nonce generated as specified in 478 [RFC6830]. 480 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 481 1, to indicate the presence of Authentication Data. If the ITR and 482 the Map-Resolver are configured with a shared key, the ITR-OTK 483 confidentiality SHOULD be protected by wrapping the ITR-OTK with the 484 algorithm specified by the OTK Encryption ID field. See Section 5.5 485 for further details on OTK encryption. 487 The Requested HMAC ID field contains the suggested HMAC algorithm to 488 be used by the Map-Server and the ETR to protect the integrity of the 489 ECM Authentication data and of the Map-Reply. 491 The KDF ID field specifies the suggested key derivation function to 492 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE 493 (0), MAY be used to specify that the ITR has no preferred KDF ID. 495 The EID-AD length is set to 4 bytes, since the Authentication Data 496 does not contain EID-prefix Authentication Data, and the EID-AD 497 contains only the KDF ID field. 499 In response to an encapsulated Map-Request that has the S-bit set, an 500 ITR MUST receive a Map-Reply with the S-bit set, that includes an 501 EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the 502 ITR MUST discard it. In response to an encapsulated Map-Request with 503 S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and 504 the ITR SHOULD discard the Map-Reply if the S-bit is set. 506 Upon receiving a Map-Reply, the ITR must verify the integrity of both 507 the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of 508 the integrity checks fails. After processing the Map-Reply, the ITR 509 must discard the pair associated to the Map-Reply 511 The integrity of the EID-AD is verified using the locally stored ITR- 512 OTK to re-compute the HMAC of the EID-AD using the algorithm 513 specified in the EID HMAC ID field. If the EID HMAC ID field does 514 not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply 515 and send, at the first opportunity it needs to, a new Map-Request 516 with a different Requested HMAC ID field, according to ITR's local 517 policy. The scope of the HMAC operation covers the entire EID-AD, 518 from the EID-AD Length field to the EID HMAC field, which must be set 519 to 0 before the computation of the HMAC. 521 ITR MUST set the EID HMAC ID field to 0 before computing the HMAC. 523 To verify the integrity of the PKT-AD, first the MS-OTK is derived 524 from the locally stored ITR-OTK using the algorithm specified in the 525 KDF ID field. This is because the PKT-AD is generated by the ETR 526 using the MS-OTK. If the KDF ID in the Map-Reply does not match the 527 KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- 528 Reply and send, at the first opportunity it needs to, a new Map- 529 Request with a different KDF ID, according to ITR's local policy. 531 The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD 532 using the Algorithm specified in the PKT HMAC ID field. If the PKT 533 HMAC ID field does not match the Requested HMAC ID the ITR SHOULD 534 discard the Map-Reply and send, at the first opportunity it needs to, 535 a new Map-Request with a different Requested HMAC ID according to 536 ITR's local policy or until all HMAC IDs supported by the ITR have 537 been attempted. 539 Each individual Map-Reply EID-record is considered valid only if: (1) 540 both EID-AD and PKT-AD are valid, and (2) the intersection of the 541 EID-prefix in the Map-Reply EID-record with one of the EID-prefixes 542 contained in the EID-AD is not empty. After identifying the Map- 543 Reply record as valid, the ITR sets the EID-prefix in the Map-Reply 544 record to the value of the intersection set computed before, and adds 545 the Map-Reply EID-record to its EID-to-RLOC cache, as described in 546 [RFC6830]. An example of Map-Reply record validation is provided in 547 Section 5.4.1. 549 The ITR SHOULD send SMR triggered Map-Requests over the mapping 550 system in order to receive a secure Map-Reply. If an ITR accepts 551 piggybacked Map-Replies, it SHOULD also send a Map-Request over the 552 mapping system in order to verify the piggybacked Map-Reply with a 553 secure Map-Reply. 555 5.4.1. Map-Reply Record Validation 557 The payload of a Map-Reply may contain multiple EID-records. The 558 whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide 559 integrity protection and origin authentication to the EID-prefix 560 records claimed by the ETR. The Authentication Data field of a Map- 561 Reply may contain multiple EID-records in the EID-AD. The EID-AD is 562 signed by the Map-Server, with the EID HMAC, to provide integrity 563 protection and origin authentication to the EID-prefix records 564 inserted by the Map-Server. 566 Upon receiving a Map-Reply with the S-bit set, the ITR first checks 567 the validity of both the EID HMAC and of the PKT-AD HMAC. If either 568 one of the HMACs is not valid, a log action MUST be taken and the 569 Map-Reply MUST NOT be processed any further. If both HMACs are 570 valid, the ITR proceeds with validating each individual EID-record 571 claimed by the ETR by computing the intersection of each one of the 572 EID-prefix contained in the payload of the Map-Reply with each one of 573 the EID-prefixes contained in the EID-AD. An EID-record is valid 574 only if at least one of the intersections is not the empty set. 576 For instance, the Map-Reply payload contains 3 mapping record EID- 577 prefixes: 579 2001:db8:0102::/48 581 2001:db8:0103::/48 583 2001:db8:0200::/40 585 The EID-AD contains two EID-prefixes: 587 2001:db8:0103::/48 589 2001:db8:0203::/48 591 The EID-record with EID-prefix 2001:db8:0102::/48 is not eligible to 592 be used by the ITR since it is not included in any of the EID-ADs 593 signed by the Map-Server. A log action MUST be taken. 595 The EID-record with EID-prefix 2001:db8:0103::/48 is eligible to be 596 used by the ITR because it matches the second EID-prefix contained in 597 the EID-AD. 599 The EID-record with EID-prefix 2001:db8:0200::/40 is not eligible to 600 be used by the ITR since it is not included in any of the EID-ADs 601 signed by the Map-Server. A log action MUST be taken. In this last 602 example the ETR is trying to over claim the EID-prefix 603 2001:db8:0200::/40, but the Map-Server authorized only 604 2001:db8:0203::/48, hence the EID-record is discarded. 606 5.4.2. PITR Processing 608 The processing performed by a PITR is equivalent to the processing of 609 an ITR. However, if the PITR is directly connected to a Mapping 610 System such as LISP+ALT [RFC6836], the PITR performs the functions of 611 both the ITR and the Map-Resolver forwarding the Map-Request 612 encapsulated in an ECM header that includes the Authentication Data 613 fields as described in Section 5.6. 615 5.5. Encrypting and Decrypting an OTK 617 MS-OTK confidentiality is required in the path between the Map-Server 618 and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured 619 key shared between the Map-Server and the ETR for the purpose of 620 securing ETR registration [RFC6833]. Similarly, if ITR-OTK 621 confidentiality is required in the path between the ITR and the Map- 622 Resolver, the ITR-OTK SHOULD be encrypted with a key shared between 623 the ITR and the Map-Resolver. 625 The OTK is encrypted using the algorithm specified in the OTK 626 Encryption ID field. When the AES Key Wrap algorithm is used to 627 encrypt a 128-bit OTK, according to [RFC3394], the AES Key Wrap 628 Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). 629 The output of the AES Key Wrap operation is 192-bit long. The most 630 significant 64-bit are copied in the One-Time Key Preamble field, 631 while the 128 less significant bits are copied in the One-Time Key 632 field of the LISP-SEC Authentication Data. 634 When decrypting an encrypted OTK the receiver MUST verify that the 635 Initialization Value resulting from the AES Key Wrap decryption 636 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 637 the receiver MUST discard the entire message. 639 When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set 640 to NULL_KEY_WRAP_128, and the OTK Preamble is set to 641 0x0000000000000000 (64 bits). 643 5.6. Map-Resolver Processing 645 Upon receiving an encapsulated Map-Request with the S-bit set, the 646 Map-Resolver decapsulates the ECM message. The ITR-OTK, if 647 encrypted, is decrypted as specified in Section 5.5. 649 Protecting the confidentiality of the ITR-OTK and, in general, the 650 security of how the Map-Request is handed by the Map-Resolver to the 651 Map-Server, is specific to the particular Mapping System used, and 652 outside of the scope of this memo. 654 In Mapping Systems where the Map-Server is compliant with [RFC6833], 655 the Map-Resolver originates a new ECM header with the S-bit set, that 656 contains the unencrypted ITR-OTK, as specified in Section 5.5, and 657 the other data derived from the ECM Authentication Data of the 658 received encapsulated Map-Request. 660 The Map-Resolver then forwards to the Map-Server the received Map- 661 Request, encapsulated in the new ECM header that includes the newly 662 computed Authentication Data fields. 664 5.7. Map-Server Processing 666 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 667 the Map-Server process the Map-Request according to the value of the 668 S-bit contained in the Map-Register sent by the ETR during 669 registration. 671 If the S-bit contained in the Map-Register was clear the Map-Server 672 decapsulates the ECM and generates a new ECM encapsulated Map-Request 673 that does not contain an ECM Authentication Data, as specified in 674 [RFC6830]. The Map-Server does not perform any further LISP-SEC 675 processing, and the Map-Reply will not be protected. 677 If the S-bit contained in the Map-Register was set the Map-Server 678 decapsulates the ECM and generates a new ECM Authentication Data. 679 The Authentication Data includes the OTK-AD and the EID-AD, that 680 contains EID-prefix authorization information, that are ultimately 681 sent to the requesting ITR. 683 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from 684 the ITR-OTK received with the Map-Request. MS-OTK is derived 685 applying the key derivation function specified in the KDF ID field. 686 If the algorithm specified in the KDF ID field is not supported, the 687 Map-Server uses a different algorithm to derive the key and updates 688 the KDF ID field accordingly. 690 The Map-Server and the ETR MUST be configured with a shared key for 691 mapping registration according to [RFC6833]. If MS-OTK 692 confidentiality is required, then the MS-OTK SHOULD be encrypted, by 693 wrapping the MS-OTK with the algorithm specified by the OTK 694 Encryption ID field as specified in Section 5.5. 696 The Map-Server includes in the EID-AD the longest match registered 697 EID-prefix for the destination EID, and an HMAC of this EID-prefix. 698 The HMAC is keyed with the ITR-OTK contained in the received ECM 699 Authentication Data, and the HMAC algorithm is chosen according to 700 the Requested HMAC ID field. If The Map-Server does not support this 701 algorithm, the Map-Server uses a different algorithm and specifies it 702 in the EID HMAC ID field. The scope of the HMAC operation covers the 703 entire EID-AD, from the EID-AD Length field to the EID HMAC field, 704 which must be set to 0 before the computation. 706 The Map-Server then forwards the updated ECM encapsulated Map- 707 Request, that contains the OTK-AD, the EID-AD, and the received Map- 708 Request to an authoritative ETR as specified in [RFC6830]. 710 5.7.1. Map-Server Processing in Proxy mode 712 If the Map-Server is in proxy mode, it generates a Map-Reply, as 713 specified in [RFC6830], with the S-bit set to 1. The Map-Reply 714 includes the Authentication Data that contains the EID-AD, computed 715 as specified in Section 5.7, as well as the PKT-AD computed as 716 specified in Section 5.8. 718 5.8. ETR Processing 720 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 721 the ETR decapsulates the ECM message. The OTK field, if encrypted, 722 is decrypted as specified in Section 5.5 to obtain the unencrypted 723 MS-OTK. 725 The ETR then generates a Map-Reply as specified in [RFC6830] and 726 includes the Authentication Data that contains the EID-AD, as 727 received in the encapsulated Map-Request, as well as the PKT-AD. 729 The EID-AD is copied from the Authentication Data of the received 730 encapsulated Map-Request. 732 The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed 733 with the MS-OTK and computed using the HMAC algorithm specified in 734 the Requested HMAC ID field of the received encapsulated Map-Request. 736 If the ETR does not support the Requested HMAC ID, it uses a 737 different algorithm and updates the PKT HMAC ID field accordingly. 738 The scope of the HMAC operation covers the entire PKT-AD, from the 739 Map-Reply Type field to the PKT HMAC field, which must be set to 0 740 before the computation. 742 Finally the ETR sends the Map-Reply to the requesting ITR as 743 specified in [RFC6830]. 745 6. Security Considerations 747 6.1. Mapping System Security 749 The LISP-SEC threat model described in Section 3, assumes that the 750 LISP Mapping System is working properly and eventually delivers Map- 751 Request messages to a Map-Server that is authoritative for the 752 requested EID. 754 It is assumed that the Mapping System ensures the confidentiality of 755 the OTK, and the integrity of the Map-Reply data. However, how the 756 LISP Mapping System is secured is out of the scope of this document. 758 Similarly, Map-Register security, including the right for a LISP 759 entity to register an EID-prefix or to claim presence at an RLOC, is 760 out of the scope of LISP-SEC. 762 6.2. Random Number Generation 764 The ITR-OTK MUST be generated by a properly seeded pseudo-random (or 765 strong random) source. See [RFC4086] for advice on generating 766 security-sensitive random data 768 6.3. Map-Server and ETR Colocation 770 If the Map-Server and the ETR are colocated, LISP-SEC does not 771 provide protection from overclaiming attacks mounted by the ETR. 772 However, in this particular case, since the ETR is within the trust 773 boundaries of the Map-Server, ETR's overclaiming attacks are not 774 included in the threat model. 776 6.4. Deploying LISP-SEC 778 This memo is written according to [RFC2119]. Specifically, the use 779 of the key word SHOULD "or the adjective 'RECOMMENDED', mean that 780 there may exist valid reasons in particular circumstances to ignore a 781 particular item, but the full implications must be understood and 782 carefully weighed before choosing a different course". 784 Those deploying LISP-SEC according to this memo, should carefully 785 weight how the LISP-SEC threat model applies to their particular use 786 case or deployment. If they decide to ignore a particular 787 recommendation, they should make sure the risk associated with the 788 corresponding threats is well understood. 790 As an example, in certain closed and controlled deployments, it is 791 possible that the threat associated with a MiTM between the xTR and 792 the Mapping System is very low, and after carfeul consideration it 793 may be decided to allow a NULL key wrapping algorithm while carrying 794 the OTKs between the xTR and the Mapping System. 796 As an example at the other end of the spectrum, in certain other 797 deployments, attackers may be very sophisticated, and force the 798 deployers to enforce very strict policies in term of HMAC algorithms 799 accepted by an ITR. 801 Similar considerations apply to the entire LISP-SEC threat model, and 802 should guide the deployers and implementors whenever they encounter 803 the key word SHOULD across this memo. 805 6.5. Provisioning of the shared keys 807 Provisioning of the shared keys between the ITR and the Map-Resolver 808 as well as between the ETR and the Map-Server should be performed via 809 an orchestration infrastructure and it is out of the scope of this 810 draft. It is recommended that both shared keys are refreshed at 811 periodical intervals to address key aging or attackers gaining 812 unauthorized access to the shared keys. Shared keys should be 813 unpredictable random values. 815 6.6. Reply Attacks 817 An attacker can capture a valid Map-Request and/or Map-Reply and 818 reply it, however once the ITR receives the original Map-Reply the 819 pair stored at the ITR will be discarded. If a 820 replayed Map-Reply arrives at the ITR, there is no 821 that matches the incoming Map-Reply and will be discarded. 823 In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR 824 will have to do a LISP-SEC computation. This is equivalent to a 825 valid LISP-SEC computation and an attacker does not obtain any 826 benefit. 828 7. IANA Considerations 830 7.1. ECM AD Type Registry 832 IANA is requested to create the "ECM Authentication Data Type" 833 registry with values 0-255, for use in the ECM LISP-SEC Extensions 834 Section 5.1. The registry MUST be initially populated with the 835 following values: 837 Name Value Defined In 838 ------------------------------------------------- 839 Reserved 0 This memo 840 LISP-SEC-ECM-EXT 1 This memo 842 HMAC Functions 844 Values 2-255 are unassigned. They are to be assigned according to 845 the "Specification Required" policy defined in [RFC5226]. 847 7.2. Map-Reply AD Type Registry 849 IANA is requested to create the "Map-Reply Authentication Data Type" 850 registry with values 0-255, for use in the Map-Reply LISP-SEC 851 Extensions Section 5.2. The registry MUST be initially populated 852 with the following values: 854 Name Value Defined In 855 ------------------------------------------------- 856 Reserved 0 This memo 857 LISP-SEC-MR-EXT 1 This memo 859 HMAC Functions 861 Values 2-255 are unassigned. They are to be assigned according to 862 the "Specification Required" policy defined in [RFC5226]. 864 7.3. HMAC Functions 866 IANA is requested to create the "LISP-SEC Authentication Data HMAC 867 ID" registry with values 0-65535 for use as Requested HMAC ID, EID 868 HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data: 870 Name Number Defined In 871 ------------------------------------------------- 872 NONE 0 This memo 873 AUTH-HMAC-SHA-1-96 1 [RFC2104] 874 AUTH-HMAC-SHA-256-128 2 [RFC6234] 876 HMAC Functions 878 Values 3-65535 are unassigned. They are to be assigned according to 879 the "Specification Required" policy defined in [RFC5226]. 881 AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be 882 supported. 884 7.4. Key Wrap Functions 886 IANA is requested to create the "LISP-SEC Authentication Data Key 887 Wrap ID" registry with values 0-65535 for use as OTK key wrap 888 algorithms ID in the LISP-SEC Authentication Data: 890 Name Number Defined In 891 ------------------------------------------------- 892 Reserved 0 This memo 893 NULL-KEY-WRAP-128 1 This memo 894 AES-KEY-WRAP-128 2 [RFC3394] 896 Key Wrap Functions 898 Values 3-65535 are unassigned. They are to be assigned according to 899 the "Specification Required" policy defined in [RFC5226]. 901 NULL-KEY-WRAP-128, and AES-KEY-WRAP-128 MUST be supported. 903 NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 904 64-bit preamble set to 0x0000000000000000 (64 bits). 906 7.5. Key Derivation Functions 908 IANA is requested to create the "LISP-SEC Authentication Data Key 909 Derivation Function ID" registry with values 0-65535 for use as KDF 910 ID in the LISP-SEC Authentication Data: 912 Name Number Defined In 913 ------------------------------------------------- 914 NONE 0 This memo 915 HKDF-SHA1-128 1 [RFC5869] 917 Key Derivation Functions 919 Values 2-65535 are unassigned. They are to be assigned according to 920 the "Specification Required" policy defined in [RFC5226]. 922 HKDF-SHA1-128 MUST be supported 924 8. Acknowledgements 926 The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino 927 Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt 928 Noll for their valuable suggestions provided during the preparation 929 of this document. 931 9. Normative References 933 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 934 Hashing for Message Authentication", RFC 2104, 935 DOI 10.17487/RFC2104, February 1997, 936 . 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, 940 DOI 10.17487/RFC2119, March 1997, 941 . 943 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 944 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 945 September 2002, . 947 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 948 "Randomness Requirements for Security", BCP 106, RFC 4086, 949 DOI 10.17487/RFC4086, June 2005, 950 . 952 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 953 IANA Considerations Section in RFCs", RFC 5226, 954 DOI 10.17487/RFC5226, May 2008, 955 . 957 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 958 Key Derivation Function (HKDF)", RFC 5869, 959 DOI 10.17487/RFC5869, May 2010, 960 . 962 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 963 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 964 DOI 10.17487/RFC6234, May 2011, 965 . 967 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 968 Locator/ID Separation Protocol (LISP)", RFC 6830, 969 DOI 10.17487/RFC6830, January 2013, 970 . 972 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 973 Protocol (LISP) Map-Server Interface", RFC 6833, 974 DOI 10.17487/RFC6833, January 2013, 975 . 977 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 978 "Locator/ID Separation Protocol Alternative Logical 979 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 980 January 2013, . 982 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 983 Separation Protocol (LISP) Threat Analysis", RFC 7835, 984 DOI 10.17487/RFC7835, April 2016, 985 . 987 Authors' Addresses 989 Fabio Maino 990 Cisco Systems 991 170 Tasman Drive 992 San Jose, California 95134 993 USA 995 Email: fmaino@cisco.com 997 Vina Ermagan 998 Cisco Systems 999 170 Tasman Drive 1000 San Jose, California 95134 1001 USA 1003 Email: vermagan@cisco.com 1004 Albert Cabellos 1005 Universitat Politecnica de Catalunya 1006 c/ Jordi Girona s/n 1007 Barcelona 08034 1008 Spain 1010 Email: acabello@ac.upc.edu 1012 Damien Saucez 1013 INRIA 1014 2004 route des Lucioles - BP 93 1015 Sophia Antipolis 1016 France 1018 Email: damien.saucez@inria.fr