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

[Martin Stiemerling <stiemerling at netlab.nec.de>]

|>
|> |
|> | 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.

I have checked again and you are right, this section needs a new subsection 
describing this attack.

|
| 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 ...

I agree that there are countermeasures needed, but I don't see a solution 
how the NATFW NSLP can help avoiding this situation. We will document it.

As said before, the network might be badly engineered when state is left 
within the network when nodes move or they get renumbered.  For any 
network, independent whether it uses NSIS or MIDCOM, some entity should 
take care about removing state from network nodes upon nodes move or change 
their address due to any other reason.  For MIDCOM the SIP proxy should now 
and remove the policy rules from the middlebox, and for NSIS the AAA entity 
or another policy decision point should do so.

 Martin


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