[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE must have no Heirs
First, all the world is not VPN.
Second, there are alternate keying protocols (KINK, for example)
Third, trying to move IKE to IP_PROTO 50 would not only be WRONG,
it would also be HARD
Fourth, moving IKE to IP_PROTO 50 would make NAT traversal EVEN HARDER
than it already is.
You clearly don't understand the problems.
-derek
"Horn, Mike" <mhorn@virtela.net> writes:
> 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
> >
--
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
References: