draft-ietf-mext-firewall-vendor-03.txt   draft-ietf-mext-firewall-vendor-04.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track Y. Sheffer Intended status: Standards Track Y. Sheffer
Expires: December 29, 2010 Check Point Expires: September 15, 2011 Check Point
N. Steinleitner N. Steinleitner
University of Goettingen University of Goettingen
G. Bajko G. Bajko
Nokia Nokia
June 27, 2010 March 14, 2011
Guidelines for firewall vendors regarding MIPv6 traffic Guidelines for firewall vendors regarding MIPv6 traffic
draft-ietf-mext-firewall-vendor-03 draft-ietf-mext-firewall-vendor-04
Abstract Abstract
This document presents some recommendations for firewall vendors to This document presents some recommendations for firewall vendors to
help them implement their firewalls in a way that allows Mobile IPv6 help them implement their firewalls in a way that allows Mobile IPv6
and DSMIPv6 signaling and data messages to pass through. This and DSMIPv6 signaling and data messages to pass through. This
document describes how to implement stateful packet filtering document describes how to implement stateful packet filtering
capability for MIPv6 and DSMIPv6. capability for MIPv6 and DSMIPv6.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2010. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 39 skipping to change at page 3, line 39
allow the use of encryption. If encryption is being used, it is not allow the use of encryption. If encryption is being used, it is not
possible to inspect the contents of the signalling packets. For possible to inspect the contents of the signalling packets. For
these messages to get through, a generic rule needs to be added in these messages to get through, a generic rule needs to be added in
the firewall to let ESP packets through without further inspection. the firewall to let ESP packets through without further inspection.
3. MIPv6 Firewall Primitives 3. MIPv6 Firewall Primitives
3.1. Requirements 3.1. Requirements
This document assumes that the firewalls are capable of deep packet This document assumes that the firewalls are capable of deep packet
inspection at least until the mobility header. It also assumes that inspection at least until the mobility header. This implies that
the firewalls are capable of creating filters based on arbitrary they are capable of parsing ICMPv6 packets and options in addition to
fields based on the contents of a signaling packet. understanding the mobility header. It also assumes that the
firewalls are capable of creating filters based on arbitrary fields
based on the contents of a signaling packet.
3.2. Detecting and parsing the Mobility Header 3.2. Detecting and parsing the Mobility Header
The Mobility Header is the basic primitive in all MIPv6 signaling The Mobility Header is the basic primitive in all MIPv6 signaling
messages. Thus the firewalls need to be able to recognize the messages. Thus the firewalls need to be able to recognize the
presence of the mobility header and be able to parse the contents of presence of the mobility header and be able to parse the contents of
the Mobility Header. The MH is described in section 6.1 of [RFC3775] the Mobility Header. The MH is described in section 6.1 of [RFC3775]
and the format of the same is scribed in section 6.1.1 of [RFC3775]. and the format of the same is described in section 6.1.1 of
Firewalls need to be able to at least understand the contents of the [RFC3775]. Firewalls need to be able to at least understand the
MH Type field that describes the type of signaling message carried. contents of the MH Type field that describes the type of signaling
message carried.
3.3. Parsing Mobility Options 3.3. Parsing Mobility Options
The Mobility Header can carry additional information in the form of The Mobility Header can carry additional information in the form of
mobility options as described in section 6.2 of [RFC3775] and section mobility options as described in section 6.2 of [RFC3775] and section
3 of [RFC5555]. Some of these mobility options need to be understood 3 of [RFC5555]. Some of these mobility options need to be understood
for proper creation of state on the firewalls. Hence firewalls must for proper creation of state on the firewalls. Hence firewalls must
be able to parse the mobility options defined in [RFC3775] and be able to parse the mobility options defined in [RFC3775] and
[RFC5555]. [RFC5555].
skipping to change at page 5, line 23 skipping to change at page 5, line 24
Table 1: Message Pairs in MIPv6 Table 1: Message Pairs in MIPv6
Such dynamic rules can be timed out after a configurable period Such dynamic rules can be timed out after a configurable period
STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages. STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages.
This document recommends that the default value of This document recommends that the default value of
STATEFUL_PINHOLE_LIFETIME be set to 30 seconds. STATEFUL_PINHOLE_LIFETIME be set to 30 seconds.
These dynamic rules MUST be immediately deleted after the return These dynamic rules MUST be immediately deleted after the return
message passes through. e.g. Once a return HoT message for a HoTI message passes through. e.g. Once a return HoT message for a HoTI
passes through, the pinhole must be immediately removed. The loss of passes through, the pinhole must be immediately removed.
the HoT packet after passing the firewall needs to be handled by the
original MN retransmitting the HoTI message.
A DSMIPv6 client [RFC5555] having been configured with only a v4 CoA, A DSMIPv6 client [RFC5555] having been configured with only a v4 CoA,
will tunnel the MIP6 signaling messages to the HA's IPv4 address will tunnel the MIP6 signaling messages to the HA's IPv4 address
using its IPv4 CoA. These messages are either IP-in-IP encapsulated using its IPv4 CoA. These messages are either IP-in-IP encapsulated
(protocol number 4) or UDP&IP encapsulated and sent to the (protocol number 4) or UDP&IP encapsulated and sent to the
destination UDP port number 4191. destination UDP port number 4191.
The firewall SHOULD understand the Binding Update and Biding The firewall SHOULD understand the Binding Update and Binding
Acknowledgement Message Extensions and check the status of the F Acknowledgement Message Extensions and check the status of the F
flag. If the F flag is set to zero in both the BU and the BA, the flag. If the F flag is set to zero in both the BU and the BA, the
firewall MUST set up a dynamic filter for the return packets: firewall MUST set up a dynamic filter for the return packets:
Destination Address: IPv4 CoA of the MN Destination Address: IPv4 CoA of the MN
Protocol: 4 (IP-in-IP) Protocol: 4 (IP-in-IP)
Source Address: IPv4 address of the HA Source Address: IPv4 address of the HA
When the F flag is set to 1 in either the BU and BA, the firewall When the F flag is set to 1 in either the BU and BA, the firewall
does not need to take any special action, as the signaling packets does not need to take any special action, as the signaling packets
skipping to change at page 6, line 46 skipping to change at page 6, line 46
Destination Address: Source Address of the packet (MN HoA) Destination Address: Source Address of the packet (MN HoA)
Source Address: Destination Address of packet (CN) Source Address: Destination Address of packet (CN)
6. Acknowledgements 6. Acknowledgements
The authors would like to thank the following members of the MIPv6 The authors would like to thank the following members of the MIPv6
firewall design team for contributing to this document: Hannes firewall design team for contributing to this document: Hannes
Tschofenig, Hesham Soliman, Qiu Ying, and Vijay Devarapalli. The Tschofenig, Hesham Soliman, Qiu Ying, and Vijay Devarapalli. The
authors would also like to thank William Ivancic, Ryuji Wakikawa, authors would also like to thank William Ivancic, Ryuji Wakikawa,
Jari Arkko, Henrik Levkowetz, Pasi Eronen and Noriaki Takamiya for Jari Arkko, Henrik Levkowetz, Pasi Eronen, Noriaki Takamiya and
their thorough reviews of the document and for providing comments to Arnaud Ebalard for their thorough reviews of the document and for
improve the quality of the document. providing comments to improve the quality of the document.
7. IANA Considerations 7. IANA Considerations
This document does not require any IANA action. This document does not require any IANA action.
8. Security Considerations 8. Security Considerations
This document specifies recommendations for firewall vendors to allow This document specifies recommendations for firewall vendors to allow
Mobile IPv6 traffic to pass through unhindered. This document Mobile IPv6 traffic to pass through unhindered. This document
recommends a liberal setting of firewall rules so that all legitimate recommends a liberal setting of firewall rules so that all legitimate
 End of changes. 10 change blocks. 
18 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/