[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Simplifying IKE
At 8:35 AM +0100 8/16/01, Chris Trobridge wrote:
> > -----Original Message-----
>> From: Stephen Kent [mailto:kent@bbn.com]
>>
>> 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.
>
>I was assuming you take all these things together. If tunnel SAs are
>treated as interfaces by the firewall then it can enforce the IPSEC
>constraints.
yes, it can, so long as the SA tagging is maintained on received
packets after they exit IPsec processing.
> > >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.
>
>I think this might be one of the reasons why IPSEC hasn't taken off so
>widely. I wouldn't know how to create a socket with a particular IPSEC
>policy.
>
>SSL managed to fit much better into applications and is widely used - even
>if some of the fundamentals are not as strong (which also helped it...).
>
SSL is implemented above TCP, and thus outside the OS, and that makes
it easier for applications to link in and use it. The prominent use
of SSL, from a deployment standpoint, also arises because it comes
for free in the two main browsers that are available in essentially
all user computers. Finally, web access that is SSL protected is a
tiny fraction of all web access, and the encryption (and one-way
authentication) it provides are often more for show than for
substance. You cite the lack of an IPsec API as a hindrance, but
what's the API provided by SSL for applications?
Steve
References: