[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
At 5:55 PM +0100 8/15/01, Chris Trobridge wrote:
>I think the extreme position is that what IPSEC does best is:
>
>i) Establishing keys between two known entities (IKE).
>ii) Allowing those entities to pass datagram payloads securely between them
>by providing encryption, authentication and anti-replay defenses.
>
>It also provides some tunnelling (VPN) and firewall services that are
>inferior to the free-standing implementations. IPSEC does not facilitate
>resilient routing and you're still likely to need a firewall in addition to
>IPSEC.
we disagree. firewalls typically make access control decisions based
on unauthenticated data from packet headers. IPsec makes these
decisions based on authenticated identities and mutually enforced
constraints on these packet headers. in that regard, the access
control services are far superior to what is provided by freestanding
firewalls.
>People have suggested and, I think, implemented stacks where the IPSEC
>tunnels are treated as interfaces and hence can be accomodated by routing
>protocols. This also allow a firewall (integrated in the same stack) to
>make decisions based on the IPSEC tunnel.
one might do this, and so long as the selector features mandated in
2401 are supported, this is a compliant IPsec implementation approach.
>
>This would allow the IPSEC, routing protocols and firewalls to concentrate
>on what they do best.
since we disagree on what each does best, we obviously don't agree on
your conclusion of what constitutes an appropriate allocation of
tasks :-)
>
>Of course, there would be still a problem of configuring all this securely.
>
>This has been discussed here before but, as usual, the discussion flared up
>and died away without any sort of concensus.
>
>As an aside, is there a 'standard' way for an application to request a
>specific IPSEC policy for its traffic?
No. APIs for IPsec have not been standardized.
Steve
References: