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

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

hi

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

This is a possible approach, but I would suspect that it needs
to be *very* clearly documented. Essentially what I think you 
are saying is that to deploy the NATFW NSLP safely, you have to
do so in conjunction with deploying some external management
entity which is responsible for cleaning up state in particular
circumstances. But at the moment, the NATFW document doesn't even
mention the requirement for such an entity (let alone discuss
the interactions with it), which I think would be necessary.

(what do other people think? it's obviously a complex subject.)

r.

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