[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
On Thu, 24 Apr 2003, John Shriver wrote:
> 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.
OK, thanks for educating me on this point. I assumed that the
DOI-specific message types pertained to the IPsec DOI of ISAKMP
(rather than IKE) partly because of the following words in the
DESCRIPTION clause of the IkeNotifyMessageType TC:
This textual convention is a merge of values
defined by ISAKMP with the additional values
defined in the IPsec DOI.
On this point I'll most certainly defer to those who actually know
what goes on in these protocols.
> 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.
That was understood.
> > (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?
Yes :)
> This part of why IKEv2 is being documented in one
> document, to simplify ensuring internal consistency.
OK. Thanks for the education.
> 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.
What _is_ relevant is what to put in the TC DESCRIPTION clause with
respect to the use to which various ranges in the number space are
put. I guess that at this point the "de-facto" standard is the
usage in RFC 2407, since the registry agrees with it.
> 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.)
If the IPsec assigned number registries remain intact, it is
possible to write the MIB module in a way that is immune from such
changes. Details appear below.
> > 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.
I agree that those two approaches could be made to work.
> > 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.
Right, because of the update-in-two-places problem.
[ ... remainder snipped ... ]
> > 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...
I don't agree with that. The SnmpSecurityModel TC in RFC 3411
(which is an Internet Standard) provides an alternate model that
avoids the maintenance problems. An example modelled after it is
provided below.
> > 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.
Those alternatives can indeed be made to work. Both impose some
extra administrative burden on the IANA. #1 does so once up front,
#2 does so on an ongoing basis.
> 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.
Again, I don't agree with that. Using IpsecDoiSecProtocolId
as an example, here is how one could re-write the TCs in the
IPSEC-ISAKMP-IKE-DOI-TC module so as to avoid the need to
track updates to the registry. This is modelled after the
SnmpSecurityModel TC in RFC 3411, but incorporates the
suggestion from Dave Perkins to include a pointer to the
registry where assignments can be found. It also incorporates
the suggestion from Wes Hardaker to recommend that "private
use" values be documented in an AGENT-CAPABILITIES statement
if they are used.
IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "Objects of this type represent IPsec DOI values
for the IP Security Protocol Identifier (Protocol
ID) field in an ISAKMP Proposal Payload, and in
all Notification Payloads. They may also represent
values of the Protocol ID field in the Notification
Payload and the Delete Payload.
The value zero does not identify any particular
security protocol. It MAY be used in MIB objects
to indicate that the security protocol is unknown
or that none applies. Any such use MUST be
documented in the MIB object's DESCRIPTION clause.
Values between 1 and 248, inclusive, are managed by
the Internet Assigned Numbers Authority (IANA).
Assigned values are recorded in the IPSEC Security
Protocol Identifiers section of the IANA Internet
Security Association and Key Management Protocol
(ISAKMP) Identifiers registry (a URL for which is
http://www.iana.org/assignments/isakmp-registry).
The values 249-255 are reserved for private use
amongst cooperating systems. It is RECOMMENDED
that implementations document the usage of such
values in an AGENT-CAPABILITIES statement."
REFERENCE "RFC 2407 sections 4.4.1 and 6.2"
SYNTAX Unsigned32 (0..255)
Some wordsmithing may of course be necessary or desirable.
Changes (if any) as the MIB module advances on the standards track
could include updates to the STATUS clause (a TC might be deprecated
if it became obsolete, or if it was not used in defining objects
contained in two implementations), to the DESCRIPTION clause (e.g.,
if the URL of the registry changes -- one hopes not, those things
need to be stable), or the REFERENCE clause (if new documents are
issued). But new number assignments would not have any effect, and
so would not hinder advancement on the standards track.
The disadvantage of this approach (as we all know by now) is the
loss of some machine readable information. The advantages are that
it does not conflict with the formal requirements of the SMI and
that it does not impose any administrative burden on the IANA.
Does anyone else (other than John Shriver, Wes Hardaker, or
myself) care to express an opinion on these matters?
//cmh