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

[Niklas Steinleitner]

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