[Mip6-firewall] New versions of firewall drafts -- vendor draft
Yaron Sheffer
yaronf at checkpoint.com
Wed Nov 14 11:36:35 EST 2007
Please see my comments below.
Thanks,
Yaron
QIU Ying wrote:
> Hi, Suresh and Yaron
[deleted]
> >>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).
Which protocol should be used to send this notice? On the other hand,
the maximum period is indeed 420 sec., so the FW can remove the entry
after this (reasonable) period.
>
>
> 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.
BU is only authenticated (see Suresh's response), so it could in
principle be inspected by the FW. But I expect the HA to have the smarts
to parse mobility packets correctly - and to protect itself.
>
> >>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.
OK.
>
>
> >>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.
OK, but my comment is still relevant for those messages that are
ESP-protected.
>
>
> 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
>
>
>
> Scanned by Check Point VPN-1 UTM NGX R65 with Messaging Security
>
> ------------ 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.--------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071114/b0bc3e35/attachment-0001.html
More information about the Mip6-firewall
mailing list