[Mip6-firewall] New versions of firewall drafts : UPDATE

Yaron Sheffer yaronf at checkpoint.com
Tue Nov 13 11:29:21 EST 2007


Hi Niklas,


Virtually all machines are MNs. In a modern enterprise, 90% of the 
desktops may be laptops, i.e. mobile machines.


I certainly agree to: "With a static pre-configuration solution it is 
too insecure to install a pinhole which allow this kind of data traffic 
to pass through the firewall."


Thanks,

    Yaron


Niklas Steinleitner wrote:

> Gabor,
>>  
>>
>> ------------------------------------------------------------------------
>> *From:* mip6-firewall-bounces at zeke.ecotroph.net 
>> [mailto:mip6-firewall-bounces at zeke.ecotroph.net] *On Behalf Of *ext 
>> Niklas Steinleitner
>> *Sent:* Tuesday, November 13, 2007 6:30 AM
>> *To:* Suresh Krishnan
>> *Cc:* mip6-firewall at zeke.ecotroph.net
>> *Subject:* Re: [Mip6-firewall] New versions of firewall drafts : UPDATE
>>
>>     * Section 4.4:
>>
>> as Gabor already mention, this pinhole doesn't allow the data 
>> traffic. Gabors pinhole includes th dynamic MN CoAddress, therefore 
>> is propose to use the following pinhole as it can be manually 
>> pre-configured:
>>
>>     * Destination address: CN Address
>>
>>     * Next Header: 60 (IPv6 Destination Options Header)
>>     * (Not the best and secured solution, at least better than allow
>>       every kind of traffic to the CN.)  
>>
>> This is not secure at all. The FW admin does not know in advance 
>> which nodes will become CNs, so it will need to open a pinhole saying 
>> that all packets destined to inside network with next header 60 to 
>> pass. You can't be serious about this.
> In the draft we wrote:
> "This section presents the recommendations for configuring a firewall 
> *if a node behind it should be able to act as Mobile IPv6 CN*."
> Therefore, we can assume that the FW admin known in advance which 
> node(s) could become an CN and allow only packets with next header 60 
> for this addresses.
>
> However, i understand your provisos as i have the same. But as we 
> already have several kind of insecurities within the draft, so it only 
> one more which can be also marked as "NOT RECOMMENDED".
> Isn't that the reason why we are looking for a better solution? Or do 
> you prefer to write something like:
> "With a static pre-configuration solution it is too insecure to 
> install a pinhole which allow this kind of data traffic to pass 
> through the firewall."
>
> Niklas
>>  
>> It should be acknowledged that a static pinhole which preserves the 
>> desired security of the network and the nodes behind the FW can not 
>> be installed for this case. Thus move this section to the other doc 
>> and make it dynamic pinhole, which includes the MN CoA.
>>  
>> - gabor
>
>
>
>
> 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/b11d021b/attachment.html 


More information about the Mip6-firewall mailing list