HIP Reject

1
HIP Reject

• Tom Henderson
• IETF-59, March 3, 2004

2
Background

• Lots of places where HIP drops packets silently
  if there is a problem
• Can we balance?
• need to avoid DoS attacks
• benefit of informing a peer that something went
  wrong in the exchange, and why?

3
Proposal HIP Error message

• New packet type, with an Error Code TLV
• might want to wrap a bad parameter a la ICMP
• Should be signed, to prevent spoofing
• One example (suggested by Julien) RSIP-style
  error reporting (RFC 3103)
• type codes for different error types (bad
  parameter, etc.)

4
Examples

• Error response to I1 message none
• Error response to R1 messages
• cookie not solved
• malformed Host ID
• Error response to R2 messages
• cookie solution didnt validate
• couldnt decrypt your HI
• dont support Anonymous HIs
• Various field values not supported

5
Things not to respond to

• failed signatures
• I1 to the wrong HIT
• may trigger Destination Unreachable instead
• R1s that arrive out of the blue
• possible replays
• things that might be an unsupported
  (non-critical) extension
• things that might be a result of lost packets