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

RE: IKE must have no Heirs



First, my only goal for being involved in this thread is that I think from
an operational standpoint the current state of IKE/IPsec is broken.  There
are a LOT of features that have been added by various vendors in a
proprietary fashion to address these shortcomings.  I think that the whole
VPN user community would benefit if the WG could come to some agreement and
produce a protocol (or set of protocols) to address the VPN user communities
needs.

That being said, I thought there was general consensus that AH has not
proven to be useful, so I didn't include it in my original email.  If you
know of _any_ service provider that is using AH for customer VPN's I would
be interested to hear who.  Again, I'm simply stating that IF IKE is
replaced by something else, the WG should consider using the IPsec ESP
protocol number.

I agree Jan's point that all IPsec requires is keys.  Right now, the only
thing to my knowledge that is standardized for automated key exchange for
use by IPsec is IKE.  If that is not fixable to meet the communities stated
requirements, then something new needs to be developed to fill this gap.

I think that the lack of standardization for things like user
authentication, has definitely impacted the  user community's acceptance of
IPsec.

Mike Horn

  

 > -----Original Message-----
 > From: Derek Atkins [mailto:warlord@MIT.EDU]
 > Sent: Tuesday, August 07, 2001 4:31 PM
 > To: Horn, Mike
 > Cc: ipsec@lists.tislabs.com
 > Subject: Re: IKE must have no Heirs
 > 
 > 
 > Note the 'ipsec' has TWO protocol numbers... One for ESP and one for
 > AH.  What do _YOU_ mean?
 > 
 > -derek
 > 
 > "Horn, Mike" <mhorn@virtela.net> writes:
 > 
 > > Again speaking from service provider experience, manual 
 > keys are not a
 > > scalable option.  Some sort of key exchange protocol is 
 > definitely required,
 > > right now that means IKE.  As for using a single IP 
 > protocol number for both
 > > IKE and IPsec, I was merely stating this would reduce the number of
 > > ports/protocols I have to request firewall administrators 
 > to allow.  From an
 > > operational perspective, dealing with IPsec devices behind 
 > firewalls can be
 > > very painful.  I will let this thread die, since the IPSEC 
 > and IPSRA working
 > > groups face much bigger challenges then determining if IKE 
 > and IPsec should
 > > share a protocol number.
 > > 
 > > Mike Horn
 > > 
 > > > -----Original Message-----
 > > > From: Derek Atkins [mailto:warlord@MIT.EDU]
 > > > Sent: Tuesday, August 07, 2001 3:30 PM
 > > > To: Horn, Mike
 > > > Cc: 'Alex Alten'; Chris Trobridge; ipsec@lists.tislabs.com
 > > > Subject: Re: IKE must have no Heirs
 > > > 
 > > > 
 > > > There is no IPsec (ESP/AH) dependency on IKE.  You can 
 > key manually
 > > > (which does not use IKE).  There is the KINK work, is 
 > different than
 > > > IKE.
 > > > 
 > > > There is no reason to turn IKE into it's own IP Protocol.  Using
 > > > UDP/500 works just fine, and making it's own protocol 
 > wont accomplish
 > > > anything.
 > > > 
 > > > -derek
 > > > 
 > > > "Horn, Mike" <mhorn@virtela.net> writes:
 > > > 
 > > > > Actually that is a poor example, there is no built-in 
 > > > protocol dependency
 > > > > for BGP to use OSPF.  And BGP does use TCP (port 179) for 
 > > > communication vs.
 > > > > OSPF using a protocol number (89).  IPsec currently has a 
 > > > strong dependency
 > > > > on IKE.  I do agree that from a network administration 
 > and debugging
 > > > > standpoint it would be nice if both IPsec and IKE shared a 
 > > > common protocol
 > > > > number.  This would help to simplify firewall 
 > configurations, etc.
 > > > > 
 > > > > Mike Horn 
 > > > > 
 > > > >  > -----Original Message-----
 > > > >  > From: Alex Alten [mailto:Alten@home.com]
 > > > >  > Sent: Tuesday, August 07, 2001 3:06 AM
 > > > >  > To: Chris Trobridge
 > > > >  > Cc: ipsec@lists.tislabs.com
 > > > >  > Subject: RE: IKE must have no Heirs
 > > > >  > 
 > > > >  > 
 > > > >  > Think about it.  Do you do OSPF over IP and then BGP 
 > over UDP?
 > > > >  > The same applies to IPSEC and key management.
 > > > >  > 
 > > > >  > - Alex
 > > > >  > 
 > > > >  > At 09:22 AM 8/7/2001 +0100, Chris Trobridge wrote:
 > > > >  > >
 > > > >  > >
 > > > >  > >> -----Original Message-----
 > > > >  > >> From: Alex Alten [mailto:Alten@home.com]
 > > > >  > >> Sent: 07 August 2001 08:28
 > > > >  > >> To: Kory Hamzeh; Hallam-Baker, Phillip
 > > > >  > >> Cc: 'mcnelson@mindspring.com'; ipsec@lists.tislabs.com
 > > > >  > >> Subject: Re: IKE must have no Heirs
 > > > >  > >> 
 > > > >  > >> 
 > > > >  > >> 
 > > > >  > >> I second the motion. And also propose no port 
 > number (i.e. 
 > > > >  > do the new
 > > > >  > >> one over raw IP).
 > > > >  > >> 
 > > > >  > >> - Alex
 > > > >  > >
 > > > >  > >What would that achieve? (communicating over raw IP)
 > > > >  > >
 > > > >  > >Chris
 > > > >  > >
 > > > >  > >
 > > > >  > 
 > >-------------------------------------------------------------
 > > > >  > --------------
 > > > >  > --------------------------------------
 > > > >  > >The information contained in this message is confidential 
 > > > >  > and is intended 
 > > > >  > >for the addressee(s) only.  If you have received this 
 > > > >  > message in error or 
 > > > >  > >there are any problems please notify the originator 
 > > > >  > immediately.  The 
 > > > >  > >unauthorized use, disclosure, copying or alteration of this 
 > > > >  > message is 
 > > > >  > >strictly forbidden. Baltimore Technologies plc will not 
 > > > be liable for
 > > > >  > direct, 
 > > > >  > >special, indirect or consequential damages arising from 
 > > > >  > alteration of the 
 > > > >  > >contents of this message by a third party or as a result of 
 > > > >  > any virus being 
 > > > >  > >passed on.
 > > > >  > >
 > > > >  > >In addition, certain Marketing collateral may be added from 
 > > > >  > time to time to 
 > > > >  > >promote Baltimore Technologies products, services, Global 
 > > > >  > e-Security or 
 > > > >  > >appearance at trade shows and conferences.
 > > > >  > > 
 > > > >  > >This footnote confirms that this email message has been 
 > > > swept by 
 > > > >  > >Baltimore MIMEsweeper for Content Security threats, 
 > including
 > > > >  > >computer viruses.
 > > > >  > >
 > > > >  > >
 > > > >  > --
 > > > >  > 
 > > > >  > Alex Alten
 > > > >  > 
 > > > >  > Alten@Home.Com
 > > > >  > 
 > > > >  > 
 > > > > 
 > > > 
 > > > -- 
 > > >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
 > > >        Member, MIT Student Information Processing Board  (SIPB)
 > > >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
 > > >        warlord@MIT.EDU                        PGP key available
 > > > 
 > 
 > -- 
 >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
 >        Member, MIT Student Information Processing Board  (SIPB)
 >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
 >        warlord@MIT.EDU                        PGP key available
 > 



Follow-Ups: