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