RE: New MIB Drafts Submitted
"Waters, Stephen" <Stephen.Waters@cabletron.com> Fri, 04 June 1999 01:37 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA19264; Thu, 3 Jun 1999 18:37:17 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA09039 Thu, 3 Jun 1999 19:24:14 -0400 (EDT)
Message-ID: <29752A74B6C5D211A4920090273CA3DC4BBC85@new-exc1.ctron.com>
From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
To: Avram Shacham <shacham@cisco.com>
Cc: ipsec@lists.tislabs.com, ippcp@external.cisco.com
Subject: RE: New MIB Drafts Submitted
Date: Fri, 04 Jun 1999 00:33:23 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
I'm not sure I would use the words 'very natural' when describing the negotiation of IPCOMP in IKE, and I would suggest that IKE was not the right wheel to use in the first place, so perhaps invention was required, not reinvention. Cheers, Steve. -----Original Message----- From: Avram Shacham [mailto:shacham@cisco.com] Sent: Thursday, June 03, 1999 11:26 PM To: Waters, Stephen Cc: Subject: RE: New MIB Drafts Submitted At 10:31 PM 6/3/99 +0100, Waters, Stephen wrote: > >I have been thinking of making a suggestion about IPCOMP negotiation for >some time, and this new MIB has prompted me to write it down. > >This MIB has a separate table for IPCOMP Security Associations. It has >always seemed odd to me that IPCOMP is being negotiated with IKE at all. Not odd at all. RFC2393 details three mechanisms to establish IPComp Association (IPCA): manual configuration, IPSec's IKE, and another dynamic negotiation protocol that is yet to be defined. IPComp usage is very natural in IPSec's environment and IPSec's negotiation infrastructure is available. So, the ippcp wg thought that there is no need to reinvent the wheel for the immediate deployment in the IPSec context. Again, the rfc does support negotiations via another protocol, or protocols, if and when such protocol becomes available. avram >It also seems odd that there are other suggestions to extend IKE with IKE-CFG >and IKE-XAUTH. IKE is a very good tool to exchange keys in a secure ways >that are then used to enact data encryption and authentication. Can't we >agree to leave it at that? > >If there is a need to add other IP Peer negotiation, then perhaps it is time >for a generic IP Peer Protocol ('IPPP'). At the moment, there is no way to >negotiate IPCOMP between hosts, other than to use IKE. Perhaps we need >'IPPP' to cover these extensions for IP in general. > >If you think about what these IKE-klingons are adding, it looks very similar >to PPP NCPs - CCP, IPCP, CHAP etc. Perhaps running an IP version of these >protocols following the end of Phase-2 would allow us to leave IKE pure, and >we would not be in the silly position of having IPCOMP SAs. > >I would even go so far as to say that the policy (subnet,range,address) >negotiation could be stripped from phase2 as well. IKE phase2 would then >negotiate just the protocols used to protect data and lifetime/lifedata. Any >restrictions to be applied to packets could then be negotiated/exchanged by >'IPPP' in a 'policy phase'. >In some cases (most, I'd say), no policy needs to be sent - 'send anything'. > >Maybe I go to far, but there does seem to be a need for a protocol to >negotiate peer to peer items for VPNs and non-VPNs that would not be bound >to IPSEC/IKE. > >At the very least, this may allow host peers to negotiate IPCOMP, and allow >the Security Gateways to worry about encryption/authentication enforcement. > >Any votes of support for a draft? >Steve. > > > > > >-----Original Message----- >From: Tim Jenkins [mailto:tjenkins@TimeStep.com] >Sent: Wednesday, June 02, 1999 4:40 PM >To: ipsec@lists.tislabs.com >Cc: John.Shriver@intel.com; John Shriver >Subject: New MIB Drafts Submitted > > >Greetings, > >A new version of IPSec monitoring MIB document is available at ><ftp://206.191.59.148/draft-ietf-ipsec-monitor-mib-01.txt>, >and has been submitted to the internet-drafts registry. > >Also, a new document, also part of the IPSec MIB series of >documents has also been submitted. This document is the >DOI-independent portion of the ISAKMP monitoring MIB, at ><ftp://206.191.59.148/draft-ietf-ipsec-isakmp-di-mon-mib-00.txt>. > >Due to the embedded page control characters, it should be >transferred as BINARY, not text. > >Comments requested. > > >Tim and John > >Note: I have received comments that the FTP server on >the machine above does not respond to all types of FTP >requests. I have tried to get this changed, but have >had no luck yet. If you have trouble, email me and >I will email copies back. > >--- >Tim Jenkins TimeStep Corporation >tjenkins@timestep.com http://www.timestep.com >(613) 599-3610 x4304 Fax: (613) 599-3617 >
- New MIB Drafts Submitted Tim Jenkins
- RE: New MIB Drafts Submitted Waters, Stephen
- RE: New MIB Drafts Submitted Avram Shacham
- RE: New MIB Drafts Submitted Waters, Stephen
- RE: New MIB Drafts Submitted Paul Koning