draft-ietf-lisp-sec-12 F. Maino, V. Ermagan, A. Cabellos, D. Saucez IETF 97, Seoul – November 2016

Agenda Most Significant Changes LISP-SEC Overview Q&A Scope Threat Model LISP-SEC Operations Q&A

Most Significant Changes Section 6 (Security Considerations) Section 6.1 (Mapping System Security) states assumptions on mapping system security Section 6.4 (Deploying LISP-SEC) warns that according to RFC2119 the security implications associated with the LISP-SEC threat model need to be well understood before ignoring each specific “SHOULD” recommendation. Two examples are brought up: allowing transport of unencrypted OTK between xTR and MS/MR allowing ETR/MS to choose HMAC algorithms different than the one specified by the ITR

Most Significant Changes (cont) Section 7 (IANA Considerations) rewritten to be compliant with RFC 5226. Registries have been requested, and provisioned with initial values, for: ECM Authentication Data Type Map-Reply Authentication Data Type LISP-SEC Authentication Data HMAC ID LISP-SEC Authentication Data Key Wrap ID LISP-SEC Authentication Data Key Derivation Function ID

LISP-SEC Overview

Scope Protect the Map-Request/Map-Reply exchange Map-Reply origin authentication, anti-replay and integrity protection Protect from over claiming attacks Prevent the ETR from over claiming EID prefixes

Threat Model Map Resolver Map Server ITR ETR Site Y Site X ITR ETR Mapping System Map Resolver Map Server 1.1.0.0/16 -> {RLOC} D=1.1.0.10, S=2.2.2.5 ITR EID 2.2.2.5 ETR Site Y Site X 1.1.0.0/16 ITR ETR

Threat Model The Mapping System is secure and well functioning, and delivers Map-Requests to their intended destinations as identified by the EID EID prefix authorization is delegated to mapping Server Configuration Mapping Server asserts EID prefix authorization Mapping Server is trusted to do proper RLOC mapping (proxy case) In the case of ALT Mapping System (as an example), GRE tunnels prevent Man-in-the-Middle (MiM) attacks and provide integrity and confidentiality of the information carried over ALT (i.e. the nonce and the OTK) GRE tunnels can be secured with IPsec Since the LISP-MN ETR is authoritative for his own EID prefix, we need to verify how the ETR certificate can be used to assert prefix authorization in RPKI

Threat Model (II) MiM attacks can be mounted outside, and only outside, of the Mapping System infrastructure ETR can mount prefix overclaiming attacks maliciously or unintentionally (e.g. because the ETR is hacked/compromised)

One-Time Keyed HMAC on Map-Request/Reply Mapping System OTK Map Resolver OTK-ETR = HKDF(OTK) Map-Request 1.1.0.10, n, OTK Map Server K 1.1.0.0/16 -> {RLOC} Map-Request 1.1.0.10, n AES_wrap_keyK(OTK) K’ Map-Request 1.1.0.10,n AES_wrap_keyK’(OTK-ETR=HKDF(OTK)) EID-AD: HMACOTK-MS[{EID prfx}] K D=1.1.0.10, S=2.2.2.5 ITR K’ 1.1.0.10: n=nonce, OTK=One Time Key EID 2.2.2.5 OTK-ETR Map-Reply 1.1.0.10, n EID-AD: HMACOTK-MS[{EID prfx}] LOC-AD: HMACOTK-ETR[{Rlocs}] ETR Site Y Site X 1.1.0.0/16 ETR ITR

Thanks!