[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A few thoughts on IPSP
(Forgive an interloper sticking in my twopence worth, but I couldn't stay silent any
longer...)
I have just reviewed swIPe - both the Internet Draft and accompanying paper on security
under Unix. First, as an aside, it seems to give ISO's Network Layer Security Protocol
(NLSP) a pretty bad press, and I don't fully understand the criticisms. ("... NLSP implicitly
imposes a specific model of trust and policy; this manifests itself in the form of unwieldy
features and a multiplicity of options." These sentences seem contradictory: it is NLSP's
attempt to *avoid* being policy specific which results in such a wide range of options and
features).
That said, having just implemented NLSP with other people here, I feel there are a few nice
features in it which may be useful in trying to define an IP security protocol. As a general
statement, the IPSP should, like NLSP, be made `future-proof' where possible: an eye
should be firmly kept on accommodating possible changes to TCP and/or IP, and also sup-
porting new security environments in end systems/LANs (e.g. MLS systems, better firewalls
between users, evolvement of methods for signalling security services between the Network
Layer and the application). More specifically (I'm not trying to endorse NLSP here, but
pointing out a few features which may be useful in defining an IPSP):
1) The IPSP should (like NLSP) be completely independent of the underlying network pro-
tocols, routing, and other network specifics. The advantage of this is that it is not reliant on
a datagram arriving on a specific port or address to determine how to process it; this means
that network topology and network addresses can change and the Security Association can
stay intact. (The Security Association ID in the NLSP header gives the reference to the ap-
propriate information.) The swIPe draft, (forgive me if I've misunderstood it) seems to use
the IP addresses below it to determine how to process datagrams.
2) The IPSP should (like NLSP) provide SAs with a choice of security services to its `us-
ers' at a finer level of granularity than simple source/dest IP addresses below it; swIPe (ditto
previous caveat) seems not to do this. This is important for two reasons. Firstly, when it is
operating as a gateway to a protected network, different users may require different security
services for their traffic. Secondly, (probably more importantly), security management -
key management and access control management - almost certainly will require different
services to `normal' user traffic. E.g. a key management application may do its own encryp-
tion and require a complete bypass of network security functions; or it may require a
`higher' level of protection (e.g. `stronger' crypto-algorithm) than normal user traffic; the
important point is that the security layer should be flexible and not place constraints on its
users which will be hard to fix in the future.
3) I've not been following the SAID space discussions too closely, but does the NLSP way
of doing things help at all... (maybe this is already what's been agreed?) In NLSP the SAID
is different for each direction of communication: each side tells its peer on SA setup what
value it requires for communication with it. That way, each host can manage its SAID
space efficiently and can (for example) allocate the next SAID in sequence for the next host
which wishes to communicate with it. Schemes where SAIDs are agreed bilaterally seem to
waste half the bits.
Hope these few thoughts help a bit.
Tim Dean
Rm L110, DRA-Malvern
Open Distributed Systems St Andrew's Road
Software Engineering and CIS Technology Dept Malvern
Defence Research Agency Worcestershire
UK Tel: +44-684-894239
Fax: +44-684-896113
E-mail: Dean@hydra.dra.hmg.gb