[Mip6-firewall] New versions of firewall drafts -- vendor draft
Yaron Sheffer
yaronf at checkpoint.com
Wed Nov 14 11:15:51 EST 2007
Hi Suresh, Ying,
this seems to be more of an oral tradition... It is not very clear from
RFC 3775. The companion document RFC 3776 is a little clearer, it states
(Sec. 4.3):
o When securing Binding Updates, Binding Acknowledgements, and
prefix discovery, both the mobile nodes and the home agents MUST
support and SHOULD use the Encapsulating Security Payload (ESP) [3]
header in transport mode and *MUST use a non-null payload
authentication algorithm* to provide data origin authentication,
connectionless integrity and optional anti-replay protection.
Mandatory support for encryption and integrity protection algorithms
is as defined in RFC 2401 [2], RFC 2402 [8], and RFC 2406 [3]. Care
is needed when selecting suitable encryption algorithms for ESP,
however. Currently available integrity protection algorithms are in
general considered to be secure. The encryption algorithm, DES,
mandated by the current IPsec standards is not, however. This is
particularly problematic when IPsec security associations are
configured manually, as the same key is used for a long time.
o Tunnel mode IPsec ESP MUST be supported and SHOULD be used for
the protection of packets belonging to the return routability
procedure. A *non-null encryption transform and a non-null
authentication algorithm* MUST be applied.
So: encryption for return routability, authentication only for BU/BA.
But note that the RFC does not stop you from encrypting BU/BA if you
want to.
Yaron
Suresh Krishnan wrote:
> Hi Ying,
> I thought so too and that is why in v01 of the combined draft I did
> not have this, but after another through reading of RFC3775 I
> determined that the IPSec ESP is used only for authentication and not
> for encryption. Hence the new text.
>
> Cheers
> Suresh
>
> QIU Ying wrote:
>> Hi, Suresh and Yaron
>>
>> Regarding the pattern in section 4, if I am not wrong, the mobility
>> header is encrypted by ESP. So a firewall is not able to detect the
>> mobility header in the BU/BA messages as well as in the HoTI/HoT
>> messages between MN and HA. The proposed rule here does not work. Due
>> to the limited of BCP, I do not think that a firewall could
>> distinguish the IPSec packets with mobility header from normal IPSec
>> packets. Therefore we might just suggest HA to protect itself.
>>
>>
>> I also support Yaron's viewpoints:
>>
>> >>1. Sec. 3.1: why is deep packet inspection "of arbitrary depth"
>> required? This requirement could result in a number of security
>> vulnerabilities around DOS and fragmentation. And all we really
>> require is inspection of the mobility headers!
>>
>> The words of "arbitrary depth" is too aggressive. How deep do you
>> want? For our purpose, the sentence "inspection of the mobility
>> headers" is enough.
>>
>>
>> >>2. Sec. 4: in fact, perhaps we should break up this section into
>> two: "protecting the HA" and "protecting the MN". We have different
>> assumptions about their ability to secure themselves, and can
>> possibly provide different solutions.
>>
>> Yes, it is better to describe the different scenarios in different
>> sections in order to easily understand, such as we done in admin
>> draft. I guess the focus of current section 4 is more on protected HA
>> while section 5 is on protected CN.
>>
>>
>> >>3. Sec. 5: For security reasons, state should only be established
>> by the return packet, i.e. based on BA, not BU.
>>
>> Right, using BA is better since BA is from inner.
>>
>>
>> >>4. Sec. 5: When does the FW remove this filter? Actually the same
>> question is valid for the filters defined in Sec. 4.
>>
>> I think that the protected node (HA, CN, or MN) can send a notice to
>> its firewall to remove the related rules when the entry in binding
>> cache is expired (<= 420 seconds).
>>
>> But following statements need more clarify.
>>
>> >>1. Sec. 4: The level of detail in this section is redundant, and
>> actually requires the firewall to provide unnecessary protections.
>> Once we allow any BU from the outside into the HA, we might as well
>> allow *any* mobility header into the HA, and leave it to the HA to
>> manage its mobility state (active sessions).
>>
>> Please note that BU to HA is encrypted by IPSec. The FW can not
>> detect whether a packet is BU message or not.
>>
>>
>> >>2. General: We should at least RECOMMEND that the FW drops all
>> unprotected (non-ESP) mobility messages going to hosts.
>>
>> Why need this RECOMMEND? In fact, most of mobility messages are
>> non-ESP, such as, for HA: HoT from CN; for MN, CoTI/COT and BU/BA
>> to/from CN; for CN all of messages.
>>
>>
>> >>3. Sec. 5: This section assumes that the mobility signaling is
>> protected by ESP-null, i.e. is unencrypted. Please make it explicit
>> in Sec. 4 that the FW MUST enforce this condition (by parsing the
>> inner packet of the BU/BA messages).
>>
>> BU to HA is protected by ESP, but BU to CN is non-ESP.
>>
>>
>> Regards
>> QIu Ying
>>
>>
>>
>>
>>
>> ----- Original Message -----
>> *From:* Yaron Sheffer <mailto:yaronf at checkpoint.com>
>> *To:* Niklas Steinleitner <mailto:steinleitner at cs.uni-goettingen.de>
>> *Cc:* mip6-firewall at zeke.ecotroph.net
>> <mailto:mip6-firewall at zeke.ecotroph.net>
>> *Sent:* Tuesday, November 13, 2007 7:43 PM
>> *Subject:* Re: [Mip6-firewall] New versions of firewall drafts
>>
>> Hi Suresh,
>>
>>
>> here are a few more comments to the vendor draft:
>>
>> * Abstract: typo "messags".
>> * Sec. 3.1: why is deep packet inspection "of arbitrary depth"
>> required? This requirement could result in a number of
>> security vulnerabilities around DOS and fragmentation. And all
>> we really require is inspection of the mobility headers!
>> * Sec. 3.2: typo "og"
>> * General: I think we need a section about architecture, or what
>> are our working assumptions. For example, HA is in the
>> protected network, HoA or MN or both are outside the protected
>> network; Route optimization is required; HA can protect
>> itself. Are we covering all 4 scenarios of RFC 4487, Sec. 5?
>> * General: aren't we being too positive :-) ? At least the
>> security considerations should talk about what types of
>> mobility headers should be allowed to non-HA hosts. Do we
>> assume that *all* hosts can protect themselves as well as the
>> HA? We should at least RECOMMEND that the FW drops all
>> unprotected (non-ESP) mobility messages going to hosts.
>> * Sec. 4: The level of detail in this section is redundant, and
>> actually requires the firewall to provide unnecessary
>> protections. Once we allow any BU from the outside into the
>> HA, we might as well allow *any* mobility header into the HA,
>> and leave it to the HA to manage its mobility state (active
>> sessions).
>> * Sec. 4: in fact, perhaps we should break up this section into
>> two: "protecting the HA" and "protecting the MN". We have
>> different assumptions about their ability to secure
>> themselves, and can possibly provide different solutions. For
>> example, we can allow BU into the MN only when it is preceded
>> by the HOT/COT sequence.
>> * Sec. 5: This section assumes that the mobility signaling is
>> protected by ESP-null, i.e. is unencrypted. Please make it
>> explicit in Sec. 4 that the FW MUST enforce this condition (by
>> parsing the inner packet of the BU/BA messages).
>> * Sec. 5: For security reasons, state should only be established
>> by the return packet, i.e. based on BA, not BU.
>> * Sec. 5: When does the FW remove this filter? Actually the same
>> question is valid for the filters defined in Sec. 4.
>> * Security considerations: please add "In addition, allowing
>> arbitrary mobility traffic into firewall-protected nodes
>> allows attackers to exploit security vulnerabilities that may
>> exist on these nodes."
>> I'll be happy to be listed as coauthor.
>>
>>
>> Thanks,
>>
>> Yaron
>>
>>
>> Niklas Steinleitner wrote:
>>
>>> Hi Suresh, all,
>>>> Hi Folks,
>>>> I have managed to write up some new text for the vendor
>>>> document and removed some stuff from the admin document (the
>>>> dynamic part). Can you please go over the documents and let me
>>>> know if you have any comments.
>>> some comments to the vendor draft:
>>>
>>> Section 3.2:
>>> ... type og signaling ... = type *of *signaling
>>>
>>> Section 4:
>>> - in the table you swap CoT and CoTI!
>>> right would be:
>>>
>>> +---------------------------------+---------------------------------+
>>> | Passing packet MH Type | Setup return filter with
>>> MH |
>>> | |
>>> Type |
>>>
>>> +---------------------------------+---------------------------------+
>>> | Mobility Header Type:1(HoTI) | Mobility Header
>>> Type:3(HoT) |
>>> |
>>> | |
>>> | Mobility Header Type:2(CoTI) | Mobility Header
>>> Type:4(CoT) |
>>> |
>>> | |
>>> | Mobility Header Type:5(BU) | Mobility Header
>>> Type:6(BA) |
>>>
>>> +---------------------------------+---------------------------------+
>>> - There is a needless blank line within the second pinhole
>>> format ;-)
>>>
>>> Section 5:
>>> This section only specifies how to install a pinhole for the data
>>> traffic from the CN to the MN to pass through.
>>> A second pinhole installed at the event of receiving a BU would
>>> also allow the data traffic from the MN to the CN to traverse the
>>> firewall.
>>>
>>> My proposal:
>>>
>>> ...
>>> Additionally, the firewall adds a second rule in order to let
>>> the data traffic from the MN to the CN pass through.
>>>
>>> Source Address: Source Address of the packet (MN CoA)
>>> Destination Address: Destination Address of packet (CN)
>>> Next Header: IPv6 Destination Options Header(60)
>>> Destination Address in Dest. Opts. Header: HoA
>>> This pattern allows all route optimized traffic coming from the
>>> MN to the CN to pass through.
>>>
>>> Regards,
>>> Niklas
>>>>
>>>> If you want to be included in the author list of the vendor
>>>> document, please let me know.
>>>>
>>>> Thanks
>>>> Suresh
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> _______________________________________________
>>>> Mip6-firewall mailing list
>>>> Mip6-firewall at zeke.ecotroph.net
>>>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>>
>>> -- Niklas Steinleitner Tel: +49 551 3913583
>>> Institute for Informatics steinleitner at cs.uni-goettingen.de
>>> University of Göttingen
>>> http://www.tmg.informatik.uni-goettingen.de
>>> Lotzestrasse 16-18
>>> D-37083 Göttingen, Germany
>>>
>>>
>>> Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Mip6-firewall mailing list
>>> Mip6-firewall at zeke.ecotroph.net
>>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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.--------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Mip6-firewall mailing list
>> Mip6-firewall at zeke.ecotroph.net
>> https://zeke.ecotroph.net/mailman/listinfo/mip6-firewall
>
>
> Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071114/4beb0a5b/attachment-0001.html
More information about the Mip6-firewall
mailing list