[Mip6-firewall] New versions of firewall drafts -- vendor draft
Suresh Krishnan
suresh.krishnan at ericsson.com
Wed Nov 14 10:50:05 EST 2007
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
More information about the Mip6-firewall
mailing list