RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt
Tero Kivinen <kivinen@ssh.fi> Fri, 08 September 2000 01:59 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA01841; Thu, 7 Sep 2000 18:59:25 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA19024 Thu, 7 Sep 2000 20:31:11 -0400 (EDT)
Date: Fri, 08 Sep 2000 03:41:51 +0300
Message-Id: <200009080041.DAA27125@torni.hel.fi.ssh.com>
X-Authentication-Warning: torni.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@ssh.fi>
To: Claudio Lordello <claudio.lordello@innovation.siemens.ca>
Cc: "'Ballou, Ken'" <kballou@quarrytech.com>, ipsec@lists.tislabs.com
Subject: RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt
In-Reply-To: <53D69AD06EFAD311842300A0C99B4F0865658F@ticsmtp2.innovation.siemens.ca>
References: <53D69AD06EFAD311842300A0C99B4F0865658F@ticsmtp2.innovation.siemens.ca>
X-Mailer: VM 6.34 under Emacs 19.34.2
Organization: SSH Communications Security Oy
X-Edit-Time: 9 min
X-Total-Time: 15 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Claudio Lordello writes: > > But, I'm a little surprised to see that you're defining an entirely new > > DOI, rather than extending the IPsec DOI. Is that because there is no > > provision for a DOI version number? There is no need to DOI version number. Most of the items in the DOI are allocated from the IANA, and there is no need to allocate new DOI number if you do just additive change to DOI, i.e if you just add some new numbers. If you modify the payload formats (ID, SA etc) then you MUST allocate new DOI number, but version number would not help in that case, because the old implementation would not understand SA etc payloads at all. > There is no DOI version number but there is a DOI number. I believe you are > differentiating DOI version numbers from DOI numbers by implying that a > higher version automattically supports all extensions defined in lower > versions while that's not automatically assumed with DOI numbers. Well, > that's why the VPN DOI inherits the existing DOI: to be just like a version > 2. If you just define some new numbers from the IANA, there is no need to define new DOI number. Just allocate the numbers from the IANA and create the rfc that will update the current IPsec DOI. If implementations will receive your newly allocated numbers, they will send notification back saying that they didn't understand them, and you can fall back to version which does not use them. >From my draft-ietf-ipsec-ike-ext-meth-03.txt (expired): ---------------------------------------------------------------------- ... 14. Identity Type The identity type is used to specify the interpretation of the identity payload contents. The identity type is specified in the DOI document, but the generic structure is defined in the ISAKMP document. This generic structure contains this identity type value. When a new identity type is specified, the minor version number or the phase 1 transform identifier SHOULD NOT be incremented. If an old version receives an unknown identity type, it MUST fail the negotiation, and it SHOULD send the INVALID-ID-INFORMATION notification back. A new version MAY always start with the new identity type and fall back to a previous more standard identity type separately each time, or it MAY cache this information for some time, or it MAY manually configure the identity type to be used. ... 17. Domain of Interpretation Each SA payload (and some others like notify and delete payloads) specifies the domain of interpretation for the exchange. There is no version numbers in the DOI, so if a new version of DOI is incompatible with the previous version, a new DOI number MUST be allocated. In the normal case, there is no need to have a version number in the DOI, and additions to it may be done without updating the DOI number. ... > Regarding extending the existing IPsec DOI, there are many implementations > out there which are using the existing DOI and changing it would cause a > major impact and I don't think is feasible. A new DOI is OK because ISAKMP > dictates what to do with negotiations that request a DOI which you do not > support. We are going to change IPsec DOI anyways, when we want to add for example the AES ciphers etc. If some implementation will break because of that, then they need to fix their implementation. There is a defined notification INVALID-ID-INFORMATION that can be used to notify the other end that I don't support that new ID type (from the draft-ietf-ipsec-notifymsg-03.txt): ---------------------------------------------------------------------- ... 3.18 INVALID-ID-INFORMATION The INVALID-ID-INFORMATION error message may be used to communicate that the identification type of the ID payload is not supported. Phase: 1 or 2 Differentiator: Cookies, message ID, SPI, ID payload Payloads: ID When present, the Notification Payload MUST have the following format: o Payload Length - set to length of payload + size of data o DOI - set to DOI of received packet o Protocol ID - set to selected Protocol ID from subject SA if phase 2, else set to protocol PROTO_ISAKMP o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) o Notify Message Type - set to INVALID-ID-INFORMATION o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; otherwise, contains SPI associated with Protocol ID if applicable, or nothing. o Notification Data - SHOULD contain the offending payload, the error position offset, and the message ID of the offending negotiation. It MAY contain error text describing the problem. ... -- kivinen@ssh.fi Work : +358 303 9870 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
- I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Internet-Drafts
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Claudio Lordello
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Claudio Lordello
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Markku Savela
- Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Daniel Fox
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Claudio Lordello
- Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Daniel Fox
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Ballou, Ken
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Claudio Lordello
- RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Tero Kivinen
- Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Claudio Lordello
- Re: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt Tero Kivinen