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

RE: New MIB Drafts Submitted

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
>
Follow-Ups: