[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network World article on IPSec


> 
> An 8/24/98 article by Ellen Messmer in Network World titled "The
> remaking of IPSec" claims that IPSec and IKE are not ready for prime
> time, and that productization needs to wait for IPSecond.  This is
> not the impression I have gotten from talking to vendors and from
> following the ipsec mailing list.
> 

I havent looked at the article. But, my comments below based on the items 
you list.

> Can anyone fill me in on details of some of the following claims
> from the article?  Please reply directly to me (aha@East.sun.com),
> and I will summarize the responses to the list.
> 
> 1. "The harder IPSec change will be standardizing on an IPSec remote 
>    client.  The goal of the IETF meeting is to define a client that
>    can support IP address changes automatically."
> 
>    [Anne] To what extent is this a barrier to deployment of the
>    existing IPSec?  Only in NAT environments?

If you make the assumption that Internet owes its current popularity to 
wide deployment of remote access, it is perhaps not unreasonable for 
the editor to state that Statdardizing on IPsec for remote accesss 
clients (in IPsecond) is a big step forward. Below are a couple of 
issues that need to be looked into in IPsecond. 

   A. Use of existing Auth. data bases. IKE needs to support existing
      authentication mechanisms for remote clients. Also, IKE needs to 
      support asymmetrical authentications for edge devices and 
      remote users. 

   B. Ability to support clients (IDs) that change IP addresses.
      A remote access client may have the same ID, but may assume
      a different IP address each time the client connects to the
      network. So, it is important to remove ties between client's
      ID and the IP address it may assume.  (So far as I know, this 
      is an issue only with [PSK + main mode]) 

> 
> 2. "Another difficult item on this week's agenda will be redefining
>    the core IKE protocol.  Security experts recently uncovered a
>    flaw related to the improper exposure of information."
> 
>    [Anne] Is this referring the discussion about exposure of
>    identities during IKE negotiation in Pre-Shared-Key-Auth Main
>    Mode?  Is this really a barrier to deployment?

I am not sure what this is about. I dont believe, it has to do with 
PSK and main mode. [PSK and main mode] exposes the IP address of the 
ID (that is one-to-one tied to); not necessarily the ID itself. Even if 
it did, I dont see that as an issue with exposure of session info.

There could be improper exposure (or unauthorised encryption) of 
information when policies on either end do not exactly match. But, I 
dont know if this is what the author is talking about. Addition of 
policy type payload and removing overloaded semantics of ID payload 
in Quick mode could possibly be conceived as redefining core protococol.

Currently, there isnt a policy type payload defined in IKE. ID payload 
in quick mode is overloaded to imply policy info. Even that couldnt  
pass for a policy  because at best it describe a portion of policy that 
pertains to source side or destination side. Policy has to be a 
combination of both source and destination set of selectors.  I believe, 
IPsecond is expected to address this issue. 

> 
> 3. "And IKE, as it now exists, handles time-expiration of session
>    keys in a way that could cause one gateway not to understand
>    another."
> 
>    [Anne] Is this referring to the use of kbytes-based lifetime
>    payloads versus seconds-based lifetime payloads?  To what extent
>    is this a barrier to deployment?  Does it just cause a delay, or
>    is it a Big Problem?

Lifetime issue is quite relevant to remote access. Remote access clients 
are prone to logging in frequently (as opposed to attached to the net 
all the time). The existing lifetime metrics do not guarantee that an SA 
established for one user does not get deleted when the user terminates 
the connection. Clearly, IKE on either end should clean up SAs when 
network-login is terminated. A new metric like "network-connected-time" 
would be useful for remote access users.

Also, interoperability issues with regard to session rekeying upon 
lifetime expiry should be addressed independent of remote access clients.

> -- 
> Anne Anderson                 Email: aha@east.sun.com
> Sun Microsystems Laboratories    or: aha@acm.org
> 2 Elizabeth Drive, UCHL03-205   Tel: (978) 442-0928
> Chelmsford, MA 01824 USA        Fax: (978) 250-5067
> 
> 
> 

cheers,
suresh
References: