[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-07.txt
C. M. Heard wrote:
> Notes:
> (a) In the case of IkeNotifyMessageType, only those
> enumerated values within the DOI-specific ranges 8192-16383 and
> 24576-32767 are recorded in the registry. The IkeNotifyMessageType
> TC also includes the DOI-independent values that are defined in RFC
> 2408 Section 3.14.1 (and captured by the IsakmpNotifyMessageType
> TC). Since the DOI-specific enumerations associated with the
> IkeNotifyMessageType TC are defined in RFC 2407 rather than RFC
> 2409, it seems that it is mis-named and should probably have been
> called IpsecDoiNotifyMessageType.
While these numbers may be defined in RFC 2407, they are not generic
ISAKMP numbers, they are specific to the use of IKE over ISAKMP.
The TC-MIB was sectioned in what was believed to be a rational way,
based on the real layering of the protocols. (The same applied to the
MIBs that were developed along with it, one was pure IPsec, the next was
ISAKMP, the next was IKE.) The partitioning was not artifically
"adjusted" to match odd partitioning of the protocols between the RFCs,
and instead reflects the real layering.
Ironically, IKEv2 removes some of this layering.
As for the duplication of values between IsakmpNotifyMessageType and
IkeNotifyMessageType, that is necessary because the SMI doesn't allow a
syntax for an object that is the "union" of several enumerations or TC's.
> (b) The registry specifies that values in the range
> 8192-16383 are error codes allocated for "private use within a
> DOI". This agrees with RFC 2407 but apparently disagrees with RFC
> 2408, which states that values in this range are for private use
> (but also states that values in the private use range are expected
> to be DOI-specific values). The registry (and RFC 2407) also
> specify that status codes in the range 32001-32767 are reserved
> for private use among consenting systems; however, while RFC 2408
> does allocates status codes in the range 24576-32767 for
> DOI-specific use, it also allocates status codes in the range
> 32768-40959 for private use. This confusion needs to be fixed.
Are you complaining about RFC 2407 and RFC 2408 being inconsistent and
disagreeing? This part of why IKEv2 is being documented in one
document, to simplify ensuring internal consistency.
An ISAKMP DOI is apparently rather free to redefine what ISAKMP itself
doesn't define.
I don't think that this issue is worth much concern, because ISAKMP will
be irrelevant when IKEv2 is baked.
Interestingly, IKEv2 deprecates a group of these values, and defines a
good dozen new ones. (If someone wants to argue that the TC-MIB should
be "collapsed" a bit in anticipation of IKEv2, that's not that bad an
idea, although it would break other MIBs that depend on it.)
(IKEv2 was one of the reasons that I figured this MIB project was
lingering, IKEv1 isn't going to reach Full Standard.)
>
> The parameters and attributes from the IANA Internet Security
> Association and Key Management Protocol (ISAKMP) Identifiers
> registry (http://www.iana.org/assignments/isakmp-registry) that are
> NOT captured by any textual convention in the draft are as follows:
>
> IPSEC Security Association Attribute Class
> SA Life Type
> SA Life Duration
> Group Description
> Key Length
> Key Rounds
> Compression Dictionary Size
> Compression Private Algorithm
> ECN Tunnel
> IPSEC Labeled Domain Identifier
>
This is a possible argument for not making the TC-MIB the definitive
reference on the IANA assignments.
Another approach would be to refactor the assignments, those that are in
the TC-MIB move there, and the rest stay in the plain text files.
>
> The attributes from the IANA Internet Key Exchange (IKE) Attributes
> registry (http://www.iana.org/assignments/ipsec-registry) that are
> captured by some textual convention in the draft are as follows:
>
> Attribute Name Textual Convention
>
> Encryption Algorithm IkeEncryptionAlgorithm
> Hash Algorithm IkeHashAlgorithm
> IPSEC Authentication Methods IkeAuthMethod
> Group Description IkeGroupDescription
> Group Type IkeGroupType
> PRF IkePrf
> Additional Exchanges (XCHG values) IkeExchangeType
>
> Notes:
> (a) In the case of IkeExchangeType, only those enumerated
> values within the DOI-specific range 32-239 are recorded in the
> registry. The IkeExchangeType TC also includes the DOI-independent
> values that are defined in RFC 2408 Section 3.1 (and captured by
> the IsakmpExchangeType TC).
Yes, I see that the supersetting/nesting of the TC's makes it awkward to
use this TC-MIB as the definitive IANA reference for these values.
> (b) No PRF values are currently registered, and IkePrf is
> a subranged Unsigned32 type, not an enumerated INTEGER type.
> Since Unsigned32 and INTEGER have different over-the-wire
> representations and Unsigned32 does not admit enumerations, the
> base type would need to be changed to INTEGER in order for future
> registered values to be represented as enumerations.
No problem changing this to INTEGER, since it's got enough precision to
handle 0-65535. On the other hand, if we're not doing enumerations
(except in DESCRIPTION), it's moot, and the real protocol number is an
"Unsigned16", which is more like Unsigned32 than it is like INTEGER.
>
> The attributes from the IANA Internet Key Exchange (IKE) Attributes
> registry (http://www.iana.org/assignments/ipsec-registry) and/or
> RFC 2409 that are NOT captured by any textual convention in the
> draft are as follows:
>
> Attribute Class
> Group Prime/Irreducible Polynomial
> Group Generator One
> Group Generator Two
> Group Curve A
> Group Curve B
> Life Type
> Life Duration
> Key Length
> Field Size
> Group Order
>
> Note: Group Prime/Irreducible Polynomial, Group Generator One,
> Group Generator Two, Group Curve A, Group Curve B, and Life
> Duration are such that management of values by the IANA is not
> required, and their values are not listed in the IKE Attributes
> registry; however, they are defined in RFC 2409 and TCs to
> represent them might be useful (although they might best be
> located in a MIB module that is not maintained by the IANA).
Since there were no magic values, these group numbers were not TC'd.
The IKE Monitoring MIB did have tables with them in them (OCTET STRING
(SIZE (0..511)), however I think that some of the latest groups probably
have generators larger than 511 bytes (or the next generation will).
>
> Certain of the textual conventions in the proposed MIB module
> capture parameters and attributes which are not recorded in either
> of the above-mentioned IANA registries, but which are mentioned in
> the IPsec RFCs and in a a registry update proposal (accessible
> on-line at http://www.vpnc.org/iana-ipsec/current-propsal.txt)
> that was recently discussed on the ipsec@lists.tislabs.com mailing
> list. Here is the list of the "missing in action" TCs and where
> the corresponding parameter or attribute is mentioned:
>
> Textual Convention Where param or attrib is mentioned
>
> IsakmpDOI RFC 2407 Section 4.1,
> RFC 2408 Appendix A
> (see proposal item #16)
>
> IsakmpCertificateEncoding RFC 2408 Section 3.9
> (see proposal item #13)
>
> IsakmpExchangeType RFC 2408 Section 3.1
> (see proposal item #12, but
> note that it includes both
> the DOI-independent stuff in
> RFC 2408 Section 3.1 and
> the the stuff discussed in
> RFC 2409 appendix A that
> is specific to IKE, and so
> corresponds more precisely
> to the IkeExchangeType TC)
>
> IsakmpNotifyMessageType RFC 2408 Section 3.14.1
> (see proposal item #10, but
> note that it includes both
> the DOI-independent stuff in
> RFC 2408 Section 3.14.1 and
> the the stuff discussed in
> RFC 2407 Section 4.6.3 that
> is specific to the IPsec
> DOI, and so corresponds
> more precisely to the
> IkeNotifyMessageType TC)
>
> I hope that this comparison serves to shed some light on the
> amount of work that would be necessary if the MIB module in
> <draft-ietf-ipsec-doi-tc-mib-07.txt> is turned over to the IANA for
> maintenance. If the IPsec-related registry files remain structured
> as they are presently, there will be a need to update at least one
> TC (and in some cases two TCs) when a new value is registered for
> most IPsec parameters. If the TCs in the MIB module become
> authoritative and duplication is eliminated, then there will be a
> lot of restructuring work needed. In either case the administrative
> burden is non-trivial, and I think that is a reason for concern.
> None of this would be necessary if the base types of the TCs were
> changed to subranged Unsigned32 (like IkePrf) with a pointer where
> appropriate to the existing IANA registry.
Changing from enumerations to Unsigned32 does not solve the maintenance
problem. We still want to keep the descriptions up to date. If we
don't keep the descriptions up to date, we might as well not have a
TC-MIB. Cut & paste will do in that case...
>
> So the question (leaving aside for the moment the questions of
> legality under SMI rules) is whether the benefits of having the
> enumeration labels are worth the administrative burden. Remember
> the burden will be borne not only by the IANA but also by document
> authors who have to generate the instructions to add new things to
> the registries.
On the other hand, the number of assignments has been small. Most have
been efforts to work around the limitations of ISAKMP/IKEv1. With IKEv2
being far more feature-rich (requirements based), I suspect that there
will be even less change.
I can fully see either of two alternatives:
1. IANA refactors the IPsec registries to eliminate overlap with the
TC-MIB, and the TC-MIB is authoritative on what it covers.
2. IANA maintains the TC-MIB separately, keeping it in sync with the
registries.
I do not see the alternative of maintaining the TC-MIB under the RFC
process as useful, since that will prevent anything using it as a
normative reference from ever reaching Full Standard.
>
> Mike Heard
John Shriver