[Mip6-firewall] HA Firewall BCP draft v01
Yaron Sheffer
yaronf at checkpoint.com
Fri Jul 6 12:49:26 EDT 2007
Actually, firewalls do allow to dynamically add rules based on observed
traffic. Or at least to add new instances of rule templates. So I would
say 5.4 is in scope.
But isn't the BU encrypted? Can the firewall actually see the HoA?
Thanks,
Yaron
Qiu Ying wrote:
> OK. omit 5.4.
>
>
> ________________________________
>
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig at gmx.net]
> Sent: Fri 7/6/2007 7:18 PM
> To: Qiu Ying
> Cc: Suresh Krishnan; mip6-firewall at zeke.ecotroph.net
> Subject: Re: [Mip6-firewall] HA Firewall BCP draft v01
>
>
>
> Maybe I got the purpose of the document wrong but I thought that this
> document will concentrate on the best current practice for configuring
> firewall.
> The document does not describe ways to dynamically establish rules based
> on processing some signaling messages.
>
> Hence, I would suggest to omit Section 5.4 from your text proposal.
>
>
> QIU Ying wrote:
>
>> Hi, Suresh
>>
>> The MN part was re-wrote according to your template. Please review and
>> attached.
>>
>> BTW, in section 3.1, the first paragraph, the third sentence,
>> duplicated "either"s are displayed.
>> In section 4.3, rule pattern: why use "IPv6 Destination Options
>> Header", should be " Mobility Header Type: 5"?
>>
>> Regards and Thanks
>> Qiu Ying
>>
>>
>> ----- Original Message ----- From: "Suresh Krishnan"
>> <suresh.krishnan at ericsson.com>
>> To: <mip6-firewall at zeke.ecotroph.net>
>> Sent: Friday, July 06, 2007 6:34 AM
>> Subject: [Mip6-firewall] HA Firewall BCP draft v01
>>
>>
>>
>>> Hi Folks,
>>> Here is v01 of the draft. Since I have not heard back from Qiu Ying
>>> regarding my comments, I have not included the MN part yet. I will try
>>> to wait until Sunday to submit this in case there are any comments.
>>>
>>> Cheers
>>> Suresh
>>>
>>>
>> --------------------------------------------------------------------------------
>>
>>
>>
>>
>>>
>>> Network Working Group S. Krishnan
>>> Internet-Draft Ericsson
>>> Intended status: Informational N. Steinleitner
>>> Expires: December 30, 2007 University of Goettingen
>>> Q. Ying
>>> Institute for Infocomm Research
>>> June 28, 2007
>>>
>>>
>>> Firewall Recommendations for MIPv6
>>> draft-krishnan-mip6-firewall-01
>>>
>>> Status of this Memo
>>>
>>> By submitting this Internet-Draft, each author represents that any
>>> applicable patent or other IPR claims of which he or she is aware
>>> have been or will be disclosed, and any of which he or she becomes
>>> aware will be disclosed, in accordance with Section 6 of BCP 79.
>>>
>>> Internet-Drafts are working documents of the Internet Engineering
>>> Task Force (IETF), its areas, and its working groups. Note that
>>> other groups may also distribute working documents as Internet-
>>> Drafts.
>>>
>>> Internet-Drafts are draft documents valid for a maximum of six months
>>> and may be updated, replaced, or obsoleted by other documents at any
>>> time. It is inappropriate to use Internet-Drafts as reference
>>> material or to cite them other than as "work in progress."
>>>
>>> The list of current Internet-Drafts can be accessed at
>>> http://www.ietf.org/ietf/1id-abstracts.txt.
>>>
>>> The list of Internet-Draft Shadow Directories can be accessed at
>>> http://www.ietf.org/shadow.html.
>>>
>>> This Internet-Draft will expire on December 30, 2007.
>>>
>>> Copyright Notice
>>>
>>> Copyright (C) The IETF Trust (2007).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 1]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> Abstract
>>>
>>> This document presents some recommendations for firewall
>>> administrators to help them configure their firewalls in a way that
>>> allows Mobile IPv6 signaling and data messags to pass through. This
>>> document assumes that the firewalls in question include some kind of
>>> stateful packet filtering capability.
>>>
>>>
>>> Table of Contents
>>>
>>> 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
>>> 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
>>> 3. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 5
>>> 3.1. Signaling between the MN and the HA . . . . . . . . . . . 5
>>> 3.2. Route optimization signaling between MN and CN through
>>> HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
>>> 3.3. IKEv2 signaling between MN and HA for establishing SAs . . 6
>>> 3.4. Data traffic from and to MN passing through the HA . . . . 6
>>> 4. Correspondent Node behind a firewall . . . . . . . . . . . . . 7
>>> 4.1. RRT signaling between MN and CN through HA . . . . . . . . 7
>>> 4.2. Route optimization signaling between MN and CN . . . . . . 7
>>> 4.3. Binding Update from MN to CN . . . . . . . . . . . . . . . 8
>>> 4.4. Route Optimization data traffic from MN . . . . . . . . . 8
>>> 4.5. Bi-directional tunnelled data traffic from the MN to
>>> the CN through HA . . . . . . . . . . . . . . . . . . . . 8
>>> 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
>>> 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
>>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
>>> 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13
>>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
>>> Intellectual Property and Copyright Statements . . . . . . . . . . 15
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 2]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 1. Requirements notation
>>>
>>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>> document are to be interpreted as described in [RFC2119].
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 3]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 2. Introduction
>>>
>>> Network elements such as firewalls are an integral aspect of a
>>> majority of IP networks today, given the state of security in the
>>> Internet, threats, and vulnerabilities to data networks. MIPv6
>>> [RFC3775] defines mobility support for IPv6 nodes. Since firewalls
>>> are not aware of MIPv6 protocol details, they will probably interfere
>>> with the smooth operation of the protocol. The problems caused by
>>> firewalls to Mobile IPv6 are documented in [RFC4487]
>>>
>>> This document presents some recommendations for firewall
>>> administrators to help them configure their firewalls in a way that
>>> allows Mobile IPv6 signaling and data messags to pass through. This
>>> document assumes that the firewalls in question include some kind of
>>> stateful packet filtering capability.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 4]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 3. Home Agent behind a firewall
>>>
>>> This section presents the recommendations for configuring a firewall
>>> that is protects a home agent. For each type of traffic that needs
>>> to pass through this firewall, recommendations are presented on how
>>> to identify that traffic. The following types of traffic are
>>> considered
>>>
>>> o Signaling between the MN and the HA
>>>
>>> o Route optimization signaling between MN and CN through HA
>>>
>>> o IKEv2 signaling between MN and HA for establishing SAs
>>>
>>> o Data traffic from and to MN passing through the HA
>>>
>>> 3.1. Signaling between the MN and the HA
>>>
>>> The signaling between the MN and HA is protected using IPSec ESP.
>>> These messages are encrypted and hence are not inspectable by
>>> firewalls. So the firewall either has to either permit all these
>>> messages or discard all of them. But if these messages are
>>> discarded, Mobile IPv6 as specified today will cease to work. In
>>> order to permit these messages through, the firewall has to detect
>>> the messages using the following pattern.
>>>
>>> Destination Address: Address of HA
>>> IP payload protocol number: 50 (ESP)
>>>
>>> This pattern will allow the BU messages from MNs to HA and BA
>>> messages from the HA to the MNs to pass through. It will also allow
>>> the HoTI and HoT messages (related to route optimization) between the
>>> MN and the HA to pass through.
>>>
>>> 3.2. Route optimization signaling between MN and CN through HA
>>>
>>> Route Optimization allows direct communication of data packets
>>> between the MN and a CN without tunneling it back through the HA. In
>>> order for route optimization to work, part of the initial signaling
>>> has to pass through the HA. The following pattern will allow these
>>> messages to pass through.
>>>
>>> Destination Address: HoA of MN
>>> Mobility Header Type: 3
>>>
>>> This pattern allows the HoT message from the CN to the MN's HoA to
>>> pass through the firewall. The HoTI message from the MN to the CN
>>> through the HA usually passes through the firewall without any
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 5]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> problems. Hence no specific pattern is recommended.
>>>
>>> 3.3. IKEv2 signaling between MN and HA for establishing SAs
>>>
>>> The MN and HA exchange IKEv2 signaling in order to establish the
>>> security associations. The security associations so established will
>>> later be used for securing the mobility signaling messages. Hence
>>> these messages need to be permitted to pass through the firewalls.
>>> The following pattern will detect these messages.
>>>
>>> Destination Address: Address of HA
>>> Transport Protocol: UDP
>>> Destination UDP Port: 500
>>>
>>>
>>> 3.4. Data traffic from and to MN passing through the HA
>>>
>>> If a CN tries to initiate traffic to an MN, a stateful firewall would
>>> prevent these connection requests to pass through as there is no
>>> established state on the firewall. Since MNs do not usually provide
>>> services, this is not usually a problem. But if this is necessary to
>>> do, the pattern to look for is
>>>
>>> Destination Address: MN HoA
>>>
>>> Allowing this traffic might allow any kind of traffic, including
>>> malicious traffic, to pass through unfiltered to the MN. This might
>>> cause a Denial of Service at the MN.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 6]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 4. Correspondent Node behind a firewall
>>>
>>> This section presents the recommendations for configuring a firewall
>>> if a node behind it should be able to act as Mobile IPv6 CN. For
>>> each type of traffic that needs to pass through this firewall,
>>> recommendations are presented on how to identify that traffic. The
>>> following types of traffic are considered
>>>
>>> o RRT signaling between MN and CN through HA
>>>
>>> o Route optimization signaling between MN and CN
>>>
>>> o Binding Update from MN to CN
>>>
>>> o Route Optimization data traffic from MN
>>>
>>> o Bi-directional tunnelled data traffic from the MN to the CN
>>> through HA
>>>
>>> 4.1. RRT signaling between MN and CN through HA
>>>
>>> Parts of the initial RRT signaling has to pass through the HA, namely
>>> the HoTI and the HoT messages. Without assistance, the HoTI message
>>> from the HA to the CN is not able to traverse the firewall. The
>>> following pattern will allow these messages to traverse.
>>>
>>> Destination Address: CN Address
>>>
>>> Mobility Header Type: 1
>>>
>>> This pinhole allows the HoTI message from the HA to the CN to
>>> traverse the firewall. The HoT message from the CN to the MN through
>>> the HA can traverse the firewall without any assistance. Hence no
>>> pinhole is required.
>>>
>>> 4.2. Route optimization signaling between MN and CN
>>>
>>> Route Optimization allows direct communication of data packets
>>> between the MN and a CN without tunnelling it back through the HA.
>>> To get route optimization work, the MN has to send a CoTI message
>>> directly to the CN, which response with a CoT message. However, a
>>> stateful firewall would prevent the CoTI message to pass through as
>>> there is no established state on the firewall. The following pinhole
>>> will allow the CoTI message to traverse.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 7]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> Destination Address: CN Address
>>>
>>> Mobility Header Type: 2
>>>
>>> The CoT message from the CN to the MN can traverse the firewall
>>> without any assistance. Hence no pinhole is required.
>>>
>>> 4.3. Binding Update from MN to CN
>>>
>>> After successfully performing the RRT, the MN sends the BU to the CN
>>> and expects the BA. Since this BU does not match any previous
>>> installed pinhole rules, an additional pinhole with the following
>>> format is required.
>>>
>>> Destination Address: CN Address
>>>
>>> IPv6 Destination Options Header
>>>
>>> This allows the BU to traverse the firewall and the BA can pass the
>>> firewall without any assistance. Therefore, the Binding Update
>>> sequence can be performed successfully.
>>>
>>> 4.4. Route Optimization data traffic from MN
>>>
>>> Also the Route Optimization data traffic from MN directly to the CN
>>> can not traverse the firewall without assistance. But as we have
>>> configured the firewall to allow the BU message from MN to the CN to
>>> traverse the firewall, the Route Optimization data traffic is able to
>>> pass through as it also matches the pinhole installed for the BU.
>>>
>>> Therefore, no additional pinhole rules are required.
>>>
>>> 4.5. Bi-directional tunnelled data traffic from the MN to the CN
>>> through HA
>>>
>>> If a MN tries to initiate traffic to a CN through the HA using bi-
>>> directional tunnelling, a stateful firewall would prevent these
>>> connection requests to pass through as there is no established state
>>> on the firewall. This is usually a problem as CNs often provide
>>> services. A solution is to static configure the firewall to let this
>>> traffic pass through. However, this is only an acceptable option if
>>> it is not necessary to open an all-embracing pinhole, e.g. if the
>>> destination ports are well-known. In this case, the pinhole has to
>>> look like
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 8]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> Destination Address: CN Address
>>>
>>> Destination Port: Application Ports
>>>
>>> If the ports are unknown, it is necessary to install a pinhole with
>>> only the Destination Address as pattern. Allowing this traffic might
>>> allow any kind of traffic, including malicious traffic, to traverse
>>> to the CN. This might cause a Denial of Service at the CN.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 9]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 5. Contributors
>>>
>>> This document is one of the deliverables of the MIPv6 firewall
>>> design. The following members of the team were involved in the
>>> creation of this document.
>>>
>>> Hannes Tschofenig Hannes.Tschofenig at gmx.net
>>>
>>> Gabor Bajko Gabor.Bajko at nokia.com
>>>
>>> Suresh Krishnan suresh.krishnan at ericsson.com
>>>
>>> Hesham Soliman solimanhs at gmail.com
>>>
>>> Yaron Sheffer yaronf at checkpoint.com
>>>
>>> Qiu Ying qiuying at i2r.a-star.edu.sg
>>>
>>> Ram Vishnu vishnu at motorola.com
>>>
>>> Niklas Steinleitner steinleitner at cs.uni-goettingen.de
>>>
>>> Vijay Devarapalli vijay.devarapalli at AzaireNet.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 10]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 6. IANA Considerations
>>>
>>> This document does not require any IANA action.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Krishnan, et al. Expires December 30, 2007 [Page 11]
>>>
>>> Internet-Draft MIPv6 Firewall BCP June 2007
>>>
>>>
>>> 7. Security Considerations
>>>
>>> This document specifies recommendations for firewall administrators
>>> to allow Mobile IPv6 traffic to pass through unhindered. Since some
>>> of this traffic is encrypted it is not possible for firewalls to
>>> discern whether it is safe or not. This document recommends a
>>> liberal setting so that all legitimate traffic can pass. This means
>>> that some malicious traffic may be permitted by these rules. These
>>> rules may allow the initiation of Denial of Service attacks against
>>> Mobile IPv6 capable nodes such as a home agent
>>>
> _______________________________________________
> Mip6-firewall mailing list
> Mip6-firewall at zeke.ecotroph.net
> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20070706/b3374cb2/attachment-0001.html
More information about the Mip6-firewall
mailing list