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