[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-lordello-ipsec-vpn-doi-00.txt
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/
References: