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

RE: IKE must have no Heirs



On Tue, 7 Aug 2001, Horn, Mike wrote:

> 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'm not sure I agree at all. IPSec wants keys. Where it gets these from, it
doesn't really care. There's KINK and manual keying for example. Different
keying protocols can be used (assuming they exist) and different keying
protocols can have different features and security definitions (one's more
secure against DOS/DDOS, another has less messages, another provides Identity
protection at the expense of more messages, etc). I'm not proposing 10 new
protocols, but I DO propose 2-3, as required by the non-overlapping
requirements that have gotten us IKE.

IPSec couldn't care less where it got the keys from.

jan



> 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
>  > 
>  > 
> 

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847



References: