[Mip6-firewall] New versions of firewall drafts -- vendor draft

Wed Nov 14 01:32:44 EST 2007

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 
  To: Niklas Steinleitner 
  Cc: 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:

    a.. Abstract: typo "messags". 
    b.. 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! 
    c.. Sec. 3.2: typo "og" 
    d.. 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? 
    e.. 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. 
    f.. 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). 
    g.. 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. 
    h.. 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). 
    i.. Sec. 5: For security reasons, state should only be established by the return packet, i.e. based on BA, not BU. 
    j.. Sec. 5: When does the FW remove this filter? Actually the same question is valid for the filters defined in Sec. 4.

    k.. 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: HoAThis 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.--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://zeke.ecotroph.net/pipermail/mip6-firewall/attachments/20071114/e668bfb9/attachment-0001.html 