1. Slide title In CAPITALS 50 pt Slide subtitle 32 pt Guidelines for Firewall Vendors Mobile IPv6 Suresh Krishnan, Yaron Sheffer, Niklas Steinleitner, Gabor Bajko mext@IETF70

2. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt Suresh KrishnanMobile IPv6 Firewall Vendor Recommendations2007-12-042 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. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt Suresh KrishnanMobile IPv6 Firewall Vendor Recommendations2007-12-043 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. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt Suresh KrishnanMobile IPv6 Firewall Vendor Recommendations2007-12-044 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. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt Suresh KrishnanMobile IPv6 Firewall Vendor Recommendations2007-12-045 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. Top right corner for field-mark, customer or partner logotypes. See Best practice for example. Slide title 40 pt Slide subtitle 24 pt Text 24 pt Bullets level 2-5 20 pt Suresh KrishnanMobile IPv6 Firewall Vendor Recommendations2007-12-046 Further steps  Questions?  Comments?  Adoption as WG document?