Guidelines for Firewall Vendors Mobile IPv6

1
Guidelines for Firewall Vendors Mobile IPv6

• Suresh Krishnan, Yaron Sheffer,
• Niklas Steinleitner, Gabor Bajko
• mext_at_IETF70

2
Introduction

• Firewalls are not aware of MIPv6 protocol details
• Hence they will interfere with the smooth
  operation of the protocol
• Problems are documented in RFC4487
• This document provides recommendations to
  firewall vendors regarding MIPv6 signaling and
  traffic
• Describes how to implement stateful packet
  filtering based on MIPv6 signaling
• Allows signaling responses to pass through
• Allows data packets to pass through based on a
  pinhole created by signaling

3
Assumptions

• The firewalls are capable of deep packet
  inspection at least until (and including) the
  mobility header.
• The firewalls are capable of creating filters
  based on arbitrary fields based on the contents
  of a signaling packet.
• Firewalls need to be able to at least understand
  the contents of the MH Type field that describes
  the type of signaling message carried.
• The Mobility Header can carry additional
  information in the form of mobility options. Some
  of these mobility options need to be understood
  for proper creation of state on the firewalls.
  Hence firewalls must be able to parse these.

4
Classification of recommendations

• Allow signaling response packets
• An allowed HoTI sets up a pinhole for a HoT to
  return in the opposite direction
• An allowed CoTI sets up a pinhole for a CoT to
  return in the opposite direction
• An allowed BU sets up a pinhole for a BA to
  return in the opposite direction
• Timed out in 420 seconds (lifetime of BCE)
• Allow data packets once signaling has completed
• Examine the contents of the BU to create the
  specification for the pinhole
• Wait for the BA to pass in the reverse direction
  before enabling the pinhole

5
Security

• Whether or not nodes in a network may receive
  unsolicited traffic is an administrative decision
  that is independent of MIPv6
• Allowing an incoming CoTI message is no more
  dangerous than allowing say a SIP invite
• Firewalls need to check for malformed and
  malicious packets matching these filters
• The firewalls MAY need to rate limit some of
  these traffic types to avoid DoS attacks
• This document only covers allowing signaling
  response and data packets. Signaling request
  packets (HoTI,CoTI and BU) MUST be allowed by
  static rules.

6
Further steps

• Questions?
• Comments?
• Adoption as WG document?