NAT and Firewall Traversal for HIP

1. <draft-tschofenig-hiprg-hip-natfw-traversal-00.txt> Hannes Tschofenig, Aarthi Nagarajan, Vesa Torvinen, Jukka Ylitalo, Jochen Grimminger NAT and Firewall Traversal for HIP

2. Assumptions, Requirements and Goals • Assumption of this work: Middlebox is HIP aware • HIP aware NAT/FWs needs to: • Intercept HIP messages • Base exchange • Readdressing messages • Establish soft state to • Build a packet filter • Establish a NAT binding • Authorize the requesting HIP nodes before creating a NAT binding or FW pinhole • Possibly authenticate requesting HIP nodes • DoS attack resistance for signaling to the middlebox

3. Interception at NAT • Nice property of the NAT: All HIP messages flow through it. • Interception of SPI in I2 and R2: Construct FlowID with IP and SPI • Needs to work for base exchange and also for re-addressing exchange • State changes at NAT need to be secure to prevent DoS attacks • Promising approach: • Use HIP end-to-end security to establish state at intermediate NAT • Authorization is important: "Sender Invariance" I1 I1 Initiator Responder NAT Intercept HIT,IP R1 R1 I2 with SPI(I) I2 Intercept SPI R2 with SPI(R) R2

4. Authorization at NAT • Non-identity based authorization would be convenient. • Reasons: • The Host Identity might change regularly • Host Identities might be ephemeral • Authentication is not sufficient - further authorization is required to allow Firewall hole punching. • Approaches: • SPKI certificates • Easily included into CER packet of HIP • Security Assertion Markup Language (SAML) • Provides a solution for fetching Assertions • Artifact and Assertion (by-reference/by-value messaging style)

5. Registering at a Middlebox • Initiator REGISTERS with NAT using E2M messages • NAT creates a binding • Initiator sends base exchange messages

6. Registration ProcedureReusing existing HIP mechanisms HIP Initiator Middlebox I1 or R1 or I1’: Trigger exchange R1’: [Puzzle {D-H(R), HI(R), ESP Transform, HIP Transform]SIG I2’: {Solution, SPI(I), D-H(I), ESP Transform, HIP Transform, {H(I)}keymat }SIG CER: (SPKI CERT)SIG R2’: {SPI(R), HMAC}SIG • No need to establish an IPsec SA - we want the HIP SA • Security properties need to be re-evaluated (e.g., replay attack properties)

7. Registration ProcedureProperties • Middlebox discovery (along the path between the data sender and a data receiver) • Denial of service protected protocol exchange between the end host and the middlebox (using client puzzle concept) • Reusing HIP based signaling messages (including REA messages for re-addressing) • provide mobility handling for rendezvous server and • provide mobility handling if data receiver are behind a NAT • Authorization of end host to Firewall (and vice versa) • Establishment of a security association between the end host and the middlebox • Integrity and replay protection of signaling messages

8. Problem with Firewalls (and other middleboxes) • Asymmetric paths • Interception, as previously described, is not possible: • Firewall(I) needs to know SPI(I) • Firewall(R) needs to know SPI(R)

9. Interception at Firewall Possible Solution? • Hosts signal firewalls about their SPI. • Can be done once base exchange is complete. • Assumes that • Initiator and Responder learn about their Firewalls • Information can be securely exchanged (→ Registration Protocol?)

10. Next Steps • Identify separable issues: • Registration Protocol • Authorization (SPKI, SAML) • Requirements, Threats, Scenarios, desired security properties • Brainstorm on solution for more generic case • Details need to be worked out! • Gain implementation experience • Interworking with Hi3 • Verifying security properties (e.g., using formal methods) • Reveal relationship to other working groups (e.g., NSIS, ...) • Please send us your feedback!