RE: [NSIS] new draft about security threats for the NAT/firewall NSLP

["Hancock, Robert" <robert.hancock at roke.co.uk>]

hi martin,

> | i'll check if i understand correctly by asking
> |
> | Is this actually a generic threat which applies to
> | any firewall configuration method where the network 'behind'
> | the firewall uses any mechanism for dynamic address
> | assignment (which could cause addresses to be
> | re-assigned)?
> 
> Yes indeed it applies. For instance, with the use of MIDCOM 
> between a SIP 
> proxy and a middlebox in a mobile network, pinholes might be 
> still open 
> after the mobile node has moved and has been replace by another one.
> 
> The question in my mind with this type of scenarios: Is it not badly 
> engineered when state remains in the network when a mobile 
> node moves?  At 
> least in the MIDCOM scenario the SIP proxy should now that 
> the node has 
> moved and close the pinholes immediately.
> 
> |
> | If so, we should document it (in that form). It may
> | not be specific to the NATFW NSLP; however, there
> | may be deployment considerations related to it which
> | could usefully be captured somewhere (in this case,
> | I think it would be that there should be some
> | interdependency between the soft-state lifetime of
> | the address assignment mechanism and of the NATFW
> | NSLP state management.)
> 
> The security risk should in fact be document and probably is 
> already in the 
> threats NATFW NSLP document (needs some refines though).

I checked draft-fessi-nsis-natfw-threats-00, and I don't think
I see it there. The key aspect is the assignment of the old
address of the DR to a new node, without cleaning up state
associated with that old address.

As a general point, I don't think this problem is specific to
the mobile case (it may become more severe in the mobile case,
but address re-assignment can take place all the time for many
reasons). What I think is needed is some mechanism in the NAT/FW
which is aware of the address lifetime and reallocation mechanism,
and which can either 
a) limit the lifetime of the installed state to the lifetime
of the address, or
b) do state cleanup if the address is reallocated.

Superficially the problem seems soluble (and without necessarily
protocol changes but with security considerations applying to
the deployment), but I suspect there are tricky cases. Especially
in the v6 case where stateless autoconf or 3041 addresses are
being used ...

r.

> 
>   Martin 
> 
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis