Re: comments on ...isakmp-mode-cfg-02
"Michael C. Richardson" <mcr@sandelman.ottawa.on.ca> Wed, 18 March 1998 00:22 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id TAA21310 for ipsec-outgoing; Tue, 17 Mar 1998 19:22:54 -0500 (EST)
Message-Id: <199803180036.TAA03135@istari.sandelman.ottawa.on.ca>
To: ipsec@tis.com
Subject: Re: comments on ...isakmp-mode-cfg-02
In-reply-to: Your message of "Tue, 17 Mar 1998 09:30:50 PST." <350EB34A.E9C1604D@redcreek.com>
Date: Tue, 17 Mar 1998 19:36:15 -0500
From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes: Scott> The fact of the matter is that if the IPsec suite is to continue Scott> to grow and improve, implementations will be (temporarily) broken Scott> now and then. You might be able to make an argument for hacking Yes, I agree. My proposed vendor ID allows a single vendor to deploy any number of extensions without having to break interoperability with other vendors. I propose that when it comes to writing up new drafts, we will be writing up ISAKMP v1.1. It isn't clear to me what to do when a responder receives a packet with a minor version that is *greater* than its own. I think that one should turn around and initiate with a packet containing major/minor that one can work with. I.e. the initiator's packet is just "lost", but an ISAKMP SA is setup. [hmm. WAIT: o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations *** based on previous versions of ISAKMP Internet-Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with *** a minor version number larger than its own, given the major version numbers are identical. Isn't the 0/1 minor numbers reversed? Previous == 1, current = 0?] Scott> something in temporarily, but when you start going to the trouble Scott> of writing drafts, why not design it right? I think we are pretty close. :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON Michael Richardson |Network and security consulting and contract programming Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available. Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBNQ8W+9iXVu0RiA21AQGKeQL9E6FqTNCM80GOc1KUEgtWDK+B9bzZwkOc jqZf2rc+kp5po7QAW2Waf7eD5XesZJm5GWgDgrl4bxiFd0S7SG9UY+TwZ2NbO4sG Xn9tMMgznmSAHC47gT5/o+jKd1zcupBV =C6xe -----END PGP SIGNATURE-----
- 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