Mobile IPv6 - NSIS Interaction for Firewall traversal draft-thiruvengadam-nsis-mip6-fw-04 S. Thiruvengadam Hannes Tschofenig Franck Le Niklas Steinleitner Xiaoming Fu
Overview Problems of MIPv6 and Firewalls NSIS as Solution Draft Updates Open Issues Next Steps
Problem of MIPv6 and Firewalls Firewalls can cause several deployment problems –different based on FW placements Problem statement in RFC 4478 Additionally: draft-bajko-nsis-fw-reqs-04.txt
Overview of the Problems Binding Updates packets are IPsec protected Packets can be tunneled (or reverse tunneling) or not tunneled (route optimization) Several address are used Incoming packets does not match existing states in the FWs, because of different addresses (BU, CoTI, HoTI) Unsolved packets are dropped Some packets might be dropped, preventing MIPv6 to perform well in presence of FWs
Why NSIS? Mobile IPv6 maintains entries for moving packets from a host to another host (in roaming scenarios) The endpoints are the only entities that –Have knowledge of the HoA, Home Agent address, CoA –Know the mode being used, and format of packets –Know the characteristics of the required pinholes The NAT/FW NSLP allow endpoints to configure FWs –Allow data receiver to initiate the signaling (REA) –Allow to create several states per request –Support the required filter parameter
NSIS as Solution The draft-thiruvengadam-nsis-mip6-fw-04 “Mobile IPv6 - NSIS Interaction for Firewall traversal” show how NSIS could solve the problems
Draft Updates Adapt draft to current version of NAT/FW NSLP draft and supported features Simplified protocol operation Reduce request latency
Necessity of detecting of the FW presence? Many states need to be created in the firewalls –Route Optimization –Reverse Tunneling –Home Test Init messages –Care of Test Init messages –Binding Updates –IPsec traffic between MN and HA Enabling a detection feature would –Allow several states to be created per request –Reduce the time delay: reduce MIP6/NSIS interaction –Reduce the overhead, especially for cellular networks
NATFW NSLP with MIP6 MN CN HA Example in a FW in MN’s access network (BT case): MN uses CREATE to allow: - binding update messages (src: CoA, dst: HA) {BU} - HoTI messages (src: CoA, dst: HA) {RO} - if uplink firewall, for data traffic from MN (src: MN, dst: *) MN uses REA to allow: - HoT messages (src: HA dst: CoA) {RO} - if CN is DS * for data traffic from HA to MN (src: HA, dst: CoA) {BT} * for data traffic from HA to MN (src: HA, dst: CoA) {TR} * for data traffic from CN to MN (src: CN, dst: CoA, SP: data application port, DP: data application port) {RO}
Open Issues Multiple rules for different patterns in single signaling messages possible? Detailed interaction with MIPv6 Authorization and authentication issues –May rely on an AAA infrastructure Triangle Routing case useful?
Next Steps Detailed interaction with MIPv6 operations Authorization using AAA Inputs, comments and suggestions appreciated!