[Mip6-firewall] [MEXT] Firewall presentation - HA inside firewall and MN and CNoutside firewall

[Niklas Steinleitner]

sorry, typo

     Destination Address: MN HoA, dst-port: xxx



Niklas Steinleitner schrieb:
> Indeed, it is! I would also prefer to remove the reference.
> However, we should mention in the admin-draft that there might be some 
> scenarios were the MN should be able to run some services. In this case 
> the FW-admin can configure a more definite pinhole to allow this kind of 
> traffic. Then the pinhole is not longer:
>
>      Destination Address: MN HoA
>
> it's:
>
>      Destination Address: MN HoA, src-port: xxx
>
>
> Niklas
>
> Gabor.Bajko at nokia.com schrieb:
>   
>> This looks like a valid comment. I believe the remedy is to remove the
>> reference to [mip6vendor] from this  section.
>>
>> - gabor
>>
>> -----Original Message-----
>> From: Ivancic, William D. (GRC-RCN0) [mailto:william.d.ivancic at nasa.gov]
>>
>> Sent: Tuesday, December 04, 2007 10:04 AM
>> To: mext at ietf.org
>> Subject: [MEXT] Firewall presentation - HA inside firewall and MN and
>> CNoutside firewall
>>
>> In Administrator document:
>>
>> "3.3.  Data traffic from and to MN passing through the HA
>>
>>    If a CN tries to initiate traffic to an MN, a stateful firewall would
>>    prevent these connection requests to pass through as there is no
>>    established state on the firewall.  If this is necessary to do, the
>>    pattern to look for is
>>
>>      Destination Address: MN HoA
>>
>>    Allowing this traffic might allow any kind of traffic, including
>>    malicious traffic, to pass through unfiltered to the MN.  This would
>>    expose the MN to any type of possibly malicious traffic, resulting in
>>    a denial of service or exploitation of known security
>>    vulnerabilities.  This practice is NOT RECOMMENDED.  Instead, a
>>    dynamically created pinhole like the one specified in [MIP6FWVENDOR]"
>>
>> The last sentence implies a way to dynamically create a pinhole is
>> specified in the "MIP6FWVENDOR" document.
>>
>> However, upon review of the MIP6FWVENDOR the solution appears to be only
>> for rules where the MN sends a binding update.
>>
>> "5. Allowing data packets based on signaling
>>
>>    Once the MIPv6 signaling completes, the data traffic can begin to
>>    flow.  The traffic filters for the data traffic can be inferred from
>>    the contents of the signaling messages that setup the session.  This
>>    section describes how firewalls can intelligently setup filters for
>>    data traffic based on signaling traffic.The following example
>>    describes how to setup a filter for allowing incoming route optimized
>>    messages from a CN to an MN after the MN sent a BU message to a CN."
>>
>>
>> If this is correct, either the last sentence in 3.3 needs to me removed
>> or modified or some clarification has to be made that a CN either has to
>> be allowed to transition the FW at all times and take the risk or if a
>> CN initiates a conversation with the MN when both are outside the
>> firewall, the communiciation will fail.
>>
>>
>> Will
>>
>> _______________________________________________
>> MEXT mailing list
>> MEXT at ietf.org
>> https://www1.ietf.org/mailman/listinfo/mext
>> _______________________________________________
>> 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