[Mip6-firewall] HA Firewall BCP draft v01
Hannes Tschofenig
Hannes.Tschofenig at gmx.net
Fri Jul 6 16:14:51 EDT 2007
I fully agree with this. This is not the last document we will be
working on.
There are two more items we need to work on:
* Traversal of MIPv6 agnostic devices
* Traversal of devices that understand some form of signaling protocol
I would argue that we are not yet there to cover these two cases
sufficiently well.
Ciao
Hannes
Yaron Sheffer wrote:
> Hi Hannes,
>
>
> If the only way you can get reasonable security is by using advanced
> FW capabilities, then why not do it. This is the case for VoIP, for
> example: you need protocol inspection to open pinholes for RTP.
>
>
> Thanks,
>
> Yaron
>
>
> Hannes Tschofenig wrote:
>
>> Hi Yaron,
>>
>> it is true that firewalls add rules dynamically based on bypassing
>> data and signaling packets.
>>
>> However, the purpose of THIS draft was something different.
>>
>> Ciao
>> Hannes
>>
>> Qiu Ying wrote:
>>> Hi, Yaron
>>>
>>> Thanks for your comments.
>>> The BU there is to correspondent node, which is not encrypted.
>>>
>>> Regards
>>> Qiu Ying
>>>
>>> ________________________________
>>>
>>> From: Yaron Sheffer [mailto:yaronf at checkpoint.com]
>>> Sent: Sat 7/7/2007 12:49 AM
>>> To: Qiu Ying
>>> Cc: Hannes Tschofenig; mip6-firewall at zeke.ecotroph.net
>>> Subject: Re: [Mip6-firewall] HA Firewall BCP draft v01
>>>
>>>
>>>
>>> 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>
>>> <mailto:suresh.krishnan at ericsson.com> To:
>>> <mip6-firewall at zeke.ecotroph.net>
>>> <mailto: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
>>>
>>> ------------ Institute For Infocomm Research - Disclaimer
>>> -------------This email is confidential and may be privileged. If
>>> you are not the intended recipient, please delete it and notify us
>>> immediately. Please do not copy or use it for any purpose, or
>>> disclose its contents to any other person. Thank
>>> you.--------------------------------------------------------
>>>
>>
>
More information about the Mip6-firewall
mailing list