NAT and Firewall Traversal for HIP

1
NAT and Firewall Traversal for HIP

• ltdraft-tschofenig-hiprg-hip-natfw-traversal-00.txt
  gt
• Hannes Tschofenig, Aarthi Nagarajan, Vesa
  Torvinen,
• Jukka Ylitalo, Jochen Grimminger

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
R2 with SPI(R)
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
TransformSIG
I2 Solution, SPI(I), D-H(I), ESP Transform,
HIP Transform, H(I)keymat SIG
CER (SPKI CERT)SIG
R2 SPI(R), HMACSIG

• 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!