RE: comments on ...isakmp-mode-cfg-02
Roy Pereira <rpereira@TimeStep.com> Mon, 16 March 1998 16:23 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA06978 for ipsec-outgoing; Mon, 16 Mar 1998 11:23:20 -0500 (EST)
Message-ID: <c=US%a=_%p=TimeStep_Corpora%l=TSNTSRV2-980316162927Z-308@tsntsrv2.timestep.com>
From: Roy Pereira <rpereira@TimeStep.com>
To: "'Scott G. Kelly'" <skelly@redcreek.com>, "'ipsec@tis.com'" <ipsec@tis.com>
Subject: RE: comments on ...isakmp-mode-cfg-02
Date: Mon, 16 Mar 1998 11:29:27 -0500
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Your points are very convincing. The original draft (-00) actually had a Configuration payload specified. This was changed to a NOTIFY payload for the second revision of the draft because of interoperability issues. Most, if not all, ISAKMP implementations would send back an INVALID-PAYLOAD-TYPE error message when encountering an unknown payload type. Since ISAKMP-Cfg is not part of the base ISAKMP spec (nor should it be) not all ISAKMP implementations will support it. Thus we had to come up with a way of not breaking existing implementations. This same converstaion has gone on for a couple of weeks off the mailing list as well, so I'd like to propose the following: 1) A separate Config payload is defined. 2) Support for ISAKMP-Cfg is denoted by a ISAKMP version of 1.1 or higher. Support does not mean you actually use it, just that it does not break your implementation. Comments? >-----Original Message----- >From: Scott G. Kelly [SMTP:skelly@redcreek.com] >Sent: Friday, March 13, 1998 4:05 PM >To: ipsec@tis.com >Subject: comments on ...isakmp-mode-cfg-02 > >I have a few comments on draft-ietf-ipsec-isakmp-mode-cfg-02.txt. I am >not prepared to comment regarding the usefulness of the proposed >functionality. Rather, I'll confine my comments to the mechanism >proposed for adding the suggested functionality, i.e. piggy-backing >'configuration' messages onto the notify payload. > >While such configuration messages might be useful, this is *not* the >best way to add them, and in fact, it looks like a hack. The notify >messages have been defined for one-way communication of status >information, while the configuration exchange being proposed is actually >a 2-way negotiation. Why not suggest a new payload type for this? > >I won't go into all the specific and obvious arguments against the >suggested payload overloading, as I believe these are self-evident. I >will, however, point out that the ISAKMP-09 draft contains the following >text on page 70: > >'Because the Informational Exchange with a Notification payload is a >unidirectional message a retransmission will not be performed...' > >It appears that the design intent is for one-way (unidirectional) usage, >while the configuration mode suggested clearly requires bidirectional >communication... > >Scott >
- comments on ...isakmp-mode-cfg-02 Scott G. Kelly
- RE: comments on ...isakmp-mode-cfg-02 Roy Pereira
- RE: comments on ...isakmp-mode-cfg-02 Shawn Mamros
- Re: comments on ...isakmp-mode-cfg-02 Scott G. Kelly
- Re: comments on ...isakmp-mode-cfg-02 Michael C. Richardson
- RE: comments on ...isakmp-mode-cfg-02 Roy Pereira
- Re: comments on ...isakmp-mode-cfg-02 Scott G. Kelly
- Re: comments on ...isakmp-mode-cfg-02 Tero Kivinen