[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IANA administrative issues with draft-ietf-ipsec-doi-tc-mib-07.txt
On Fri, 18 Apr 2003, C. M. Heard wrote:
> On Thu, 17 Apr 2003, Wes Hardaker wrote:
> > On Thu, 17 Apr 2003, C. M. Heard wrote:
> > C> The extra burden on IANA is a very real concern, and when I
> > C> started the review of this MIB module most of the comments
> > C> I wrote were related to changes that I thought would be
> > C> necessary in order to make that tractable.
> >
> > If that is the reason you want to oppose the use of enums, then
> > it is a more understandable argument from my eyes at least.
> > Unfortunately, there is still functionality lost if this is the
> > case. Does it mean we should never create enums in MIBs when it
> > is supposed to match another standards document? We should
> > always use references and no real values (in enums, description
> > clauses or comments) in that case?
> >
> > I would argue that the administrative burden isn't as big a
> > problem either.
>
> You might not think so when you've seen the details that apply
> to this case. Unfortunately, [ ... ] I will have to defer the
> details of that discussion [ ... ] until next week.
Here is the promised discussion. iana@iana.org have been bcc:'d
and are invited to weigh in with their opinions.
The reason why I forsee a significant adminstrative burden if the
MIB module in <draft-ietf-ipsec-doi-tc-mib-07.txt> is turned over
to the IANA for maintenance is that the number assignments captured
by the enumerated INTEGER TCs in that module overlap those recorded
in two existing IANA registries, namely the IANA Internet Security
Association and Key Management Protocol (ISAKMP) Identifiers
registry (http://www.iana.org/assignments/isakmp-registry) and
the IANA Internet Key Exchange (IKE) Attributes registry
(http://www.iana.org/assignments/ipsec-registry). The implication
is that the IANA would have to maintain the assignments in two
places, or else would have to reorganize those registries so that
the proposed MIB module was the registry of record for the
parameters it covers. The draft proposes the latter course of
action, but it should be noted that the existing registries would
not be eliminated, because the proposed MIB module does not cover
all of the parameters and attributes recorded in the registries.
It might be useful to make a side-by-side comparison of which
parameters and attributes are covered both in the MIB module and
the existing IANA registries, which ones appear in a registry
file (or one of the IPsec RFCs) but not in the MIB module, and
which ones appear in the MIB module but not in the registry files.
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
captured by some textual convention in the draft are as follows:
Parameter/Attribute Name Textual Convention
IPSEC Situation Definition IpsecDoiSituation
IPSEC Security Protocol Identifiers IpsecDoiSecProtocolId
IPSEC ISAKMP Transform Identifiers IpsecDoiTransformIdent
IPSEC AH Transform Identifiers IpsecDoiAhTransform
IPSEC ESP Transform Identifiers IpsecDoiEspTransform
IPSEC IPCOMP Transform Identifiers IpsecDoiIpcompTransform
IPSEC Security Association Attributes
Encapsulation Mode IpsecDoiEncapsulationMode
Authentication Algorithm IpsecDoiAuthAlgorithm
IPSEC Identification Type IpsecDoiIdentType
IPSEC Notify Message Types IkeNotifyMessageType
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.
(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.
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
Notes:
(a) SA Life Duration, Compression Dictionary Size, and
Compression Private Algorithm are such that management of values by
the IANA is not required; however, Compression Dictionary Size and
Compression Private Algorithm are mentioned in the registry, 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).
(b) There is a section in the IANA ISAKMP registry for Group
Description attribute values but that attribute is not mentioned
here since its values are identical with those for the IKE Group
Description attribute, which are listed in the IANA IKE Attributes
registry discussed below.
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).
(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.
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).
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.
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.
Mike Heard