[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKE must have no Heirs
Derek,
Want to keep this friendly, but obviously I don't agree with your points.
You have a vested interest in KINK, I have a vested interest in IPsec VPNs.
This influences both of our views. I noticed you didn't respond to my
question about AH...
>
> First, all the world is not VPN.
see above.
> Second, there are alternate keying protocols (KINK, for example)
Has KINK produced any _standards_ other than the requirements (RFC 3129)?
How many IPsec vendors currently offer production support for KINK?
> Third, trying to move IKE to IP_PROTO 50 would not only be WRONG,
> it would also be HARD
I am not saying that IKE should be moved to IP_PROTO 50. If you read my
email, "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
that moving existing implementations of IKE to 50 would be HARD (you don't
explain why it would be wrong).
> Fourth, moving IKE to IP_PROTO 50 would make NAT traversal EVEN HARDER
> than it already is.
Need to think about this further. One of the proposed solutions is to use
UDP encapsulation, but this is based on the fact that *currently* IPsec
typically uses IKE on port 500 and ESP on protocol 50. If the IPsec
architecture were changed other solutions might offer themselves. How does
KINK propose to solve NAT traversal?
>
> You clearly don't understand the problems.
Everyone has a right to their own opinions, even the clueless...
>
> -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
>
Follow-Ups: