[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on VPN framework document
From: Stephen Waters <Stephen.Waters@digital.com>
Date: Mon, 12 Oct 1998 20:01:08 +0100
There may be no reason why IPSEC/IP can't be treated as a virtual
interface, but that is not the model defined in the IPSEC
architecture where everything is driven from a security policy
databases that are applied to data ON an interface, and a policy
within a given SPD calling for tunnel-mode protection does not
constitute an interface or anything that is managable as such.
This seems to be a common misconception. The model defined in the IPSEC
architecture is an abstract architecture; it describes the processing
which is needed in order for us to achieve interoperability. Using the
abstract model as an physical model results in an example implementation
which is provably complaint to the architecture, but it is certainly not
the only way you have to implement a compliant implementation. You may
have other implementation issues which will require a different
implementation strategy. The requirement is that the processing
decisions made by your implementation have to comply with the
architecture, for interoperability's sake. But the details of the
implementation, and whether you have a viritual interface or not, is an
implementation issue, not an architecture issue.
For example, the elements of the SPD can be spread across multiple OS
tables --- one of which might be your routing table which controls which
virtual interface is selected for your outging traffic. Just remember,
though, that by making the routing table part of the abstract SPD, the
routing table now contains security sensitive data, and changes to the
routing table will need to be protected appropriately, since changes
will now have security impliciations. (This would be especially true
for MLS systems, for example.) The moral of the story is that while you
do have the freedom to implement different ways of approaching the IPSEC
architecture, careful design and thought would be... ah..... strongly
advised.
- Ted
References: