[Mip6-firewall] New versions of firewall drafts

[Yaron Sheffer]

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
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071113/5075ed22/attachment.html