[IPsec] [IANA #111200] [old message] Possible update to isakmp-registry

[Tero Kivinen <[e-mail]>]

[I CCed the [e-mail] list, as this changes the registration
policies, and we have already had some discussion about this earlier
on the list and other people there might also have their opinion about
the matter.]

Pearl Liang via RT writes:
> 1) What are the registration procedures for these sub-registries 
> listed in http://www.iana.org/assignments/ipsec-registry:
> 
> - Exchange Type
> - Additional Exchanges Defined-- XCHG values
> - Next Payload Types
> - Notify Message Types 
>   - Notify Messages - Error Types (1-8191)
>   - Notify Messages - Status Types (16384-24575)
> 
> ?  I would like to update "Not defined" if possible.

For most of those it is not defined... I.e the original RFC does not
specify any registration procedures for them (or for some other
registries we have there).

I would most likely think it would be best to put them as
"Specification required" or "RFC required".

Actually I think we should go through the RFC2407-2409 and see from
there for which registries they do specify any registration policies,
and use those values for only those registries and put everything else
as "Specification required" or "RFC Required".

----------------------------------------------------------------------

Registry Name: Attribute Classes
Current: Standards-track RFC
RFC2409: 11.1 Attribute Classes

   Attributes negotiated in this protocol are identified by their class.
   Requests for assignment of new classes must be accompanied by a
   standards-track RFC which describes the use of this attribute.

-> Standards-track RFC, already OK

----------------------------------------------------------------------

Registry Name:  Encryption Algorithm Class Values (Value 1)
Current: Standards-track or Informational RFC
RFC2409: 11.2 Encryption Algorithm Class

   Values of the Encryption Algorithm Class define an encryption
   algorithm to use when called for in this document. Requests for
   assignment of new encryption algorithm values must be accompanied by
   a reference to a standards-track or Informational RFC or a reference
   to published cryptographic literature which describes this algorithm.

-> Specification required, currently this is Standards-track or
   Informational RFC, but I think Specification required is closer to
   what the RFC says about "a reference to published cryptographic
   literature". 

----------------------------------------------------------------------

Registry Name: Hash Algorithm (Value 2)
Current: Standards-track or Informational RFC
RFC2409: 11.3 Hash Algorithm

   Values of the Hash Algorithm Class define a hash algorithm to use
   when called for in this document. Requests for assignment of new hash
   algorithm values must be accompanied by a reference to a standards-
   track or Informational RFC or a reference to published cryptographic
   literature which describes this algorithm. Due to the key derivation
   and key expansion uses of HMAC forms of hash algorithms in IKE,
   requests for assignment of new hash algorithm values must take into
   account the cryptographic properties-- e.g it's resistance to
   collision-- of the hash algorithm itself.

-> Specification required, see above.

----------------------------------------------------------------------

Registry Name: IPSEC Authentication Methods (Value 3)
Current: Standards-track RFC

There is nothing about this in the RFC2409, so I would say either "RFC
required" or "Specification required" would be ok. There is draft
http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already
proposing this change. 

----------------------------------------------------------------------

Registry Name: Group Description (Value 4)
Current: Standards-track or Informational RFC
Registry Name: Group Type (Value 5)
Current: Standards-track or Informational RFC
RFC2409: 11.4 Group Description and Group Type

   Values of the Group Description Class identify a group to use in a
   Diffie-Hellman exchange. Values of the Group Type Class define the
   type of group. Requests for assignment of new groups must be
   accompanied by a reference to a standards-track or Informational RFC
   which describes this group. Requests for assignment of new group
   types must be accompanied by a reference to a standards-track or
   Informational RFC or by a reference to published cryptographic or
   mathmatical literature which describes the new type.

Group Description (Value 4) -> RFC required
Group Type (Value 5) -> Specification required

----------------------------------------------------------------------

Registry Name: Life Type (Value 11)
Current: Specification Required
RFC2409: 11.5 Life Type

   Values of the Life Type Class define a type of lifetime to which the
   ISAKMP Security Association applies. Requests for assignment of new
   life types must be accompanied by a detailed description of the units
   of this type and its expiry.

-> Hmm... this is vague, I would expect it means "Specification
   required", so ok already.

----------------------------------------------------------------------

Registry Name: PRF (Value 13)
Current: Standards-track or Informational RFC

There is nothing about this in the RFC2409, so I would say either "RFC
required" or "Specification required" would be ok. 

----------------------------------------------------------------------

Registry Name: Exchange Type
Current: Not defined

There is nothing in RFC2409/RFC2408. There has not been additions to
this, and I do not expect there to be one (as all new stuff should be
done on the protocol which obsoleted this one). I would say "Standards
Action" would most likely be best for this.

----------------------------------------------------------------------

Registry Name: Additional Exchanges Defined-- XCHG values
Current: Not defined

There is nothing in RFC2409/RFC2408. Same as above -> "Standards
Action". 

----------------------------------------------------------------------

Registry Name: ISAKMP Domain of Interpretation (DOI)
Current: Standards-track RFC
RFC2408: Domain of Interpretation

   The Domain of Interpretation (DOI) is a 32-bit field which identifies
   the domain under which the security association negotiation is taking
   place.  Requests for assignments of new DOIs must be accompanied by a
   standards-track RFC which describes the specific domain.

-> "Standards action" (i.e. Standards-track RFC)

----------------------------------------------------------------------

Registry Name: Next Payload Types
Current: Internet Draft

There is nothing in RFC2409/RFC2408. There has been more of these, so
"RFC required", I think Internet Draft is bit too low, and not
matching the RFC5226 usages.

----------------------------------------------------------------------

Registry Name: Notify Message Types
Current: Not defined
Sub-registry: Notify Messages - Error Types (1-8191)
Current: Not defined
Sub-Registry: Notify Messages - Status Types (16384-24575)
Current: Not defined

No additions to these registries, but these are large registries, so
perhaps "RFC required".

----------------------------------------------------------------------

There is a problem in the "IPSEC Authentication Methods (Value 3)" as
there is 3 values which do not have any real specification, i.e.

6             Encryption with El-Gamal	
7             Revised encryption with El-Gamal	
8             ECDSA signatures                        [Fahn]

As there is no reference to any document or anything, I have no idea
how anybody could actually implement those in interoperable manner. I
would suggest changing those to:

6             Reserved (was Encryption with El-Gamal)
7             Reserved (was Revised encryption with El-Gamal)
8             Reserved (was ECDSA signatures)

so it is clear that nobody knows how those should be implemented...

----------------------------------------------------------------------

> 2) I've added the draft ietf-ipsec-ike-ecc-groups to ipsec-registry.
> I then noticed that the document also requests the following values
> as described in Table 2 in the IANA Considerations section:
> 
> 6 EC2NGF163Random2
> 7 EC2NGF163Koblitz
> 8 EC2NGF283Random
> 9 EC2NGF283Koblitz
> 10 EC2NGF409Random
> 11 EC2NGF409Koblitz
> 12 EC2NGF571Random
> 13 EC2NGF571Koblitz

These are from the
http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version,
i.e. the registry was updated at some point in 2002 even when the
registry had registration policy of "RFC Required" and the document
was still draft (and was never published as RFC).

I think you should remove "Panjwani" and "Blake-Wilson" and put
"ipsec-ike-ecc-groups" for all of them, and put some down a footnote
saying that the registry was updated too early and the draft never
made it to the RFC, but as these values might be used by some
implementations they are left there in the registry, but new
implementations should not use them. Also the reference could point
out that the values in the registry match the -04 version of the
document.

> 22 ECPRGF192Random
> 23 EC2NGF163Random
> 24 ECPRGF224Random
> 25 EC2NGF233Random
> 26 EC2NGF233Koblitz

These overlap with the already allocated other groups, so those should
not be added to the registry. 

> Question: are these, specifically 10-13 & 22-26, no longer required
> by ietf-ipsec-ike-ecc-groups?  If we should leave them untouched,
> please let me know.

The draft-ietf-ipsec-ike-ecc-groups document will most likely not be
going forward so adding the footnotes and comments to references might
be best. 

I did not yet check the isakmp-registry, I will do that later. 

> On Tue Nov 15 02:30:58 2011, [e-mail] wrote:
> > Pearl Liang via RT writes:
> > > Resending this...
> > 
> > Some of the earlier ones had ended my spam folder, so didn't notice
> > them...
> > 
> > > On Wed Oct 12 11:34:48 2011, pearl.liang wrote:
> > > > Hi, Tero,
> > > >
> > > > I've updated the registry. Please see:
> > > >
> > > > http://www.iana.org/assignments/sigtran-adapt
> > 
> > I assume you mean
> > 
> > http://www.iana.org/assignments/isakmp-registry
> > 
> > and
> > 
> > http://www.iana.org/assignments/ipsec-registry
> > 
> > I do not think that sigtran-adapt registry has anything for me...
> > 
> > > > Updates include:
> > > >
> > > > - added a pointer to the ipsec-registry for Group Description
> > (Value 3)
> > > > - updated the Registration Procedures for Sub-registry:
> > Compression
> > > > Private Algorithm (Value 9)
> > 
> > These seem to be ok.
> > 
> > > > There were some remaining questions prefixed with [pl] below for
> > > > the following registries Paul proposed:
> > > >
> > > > - Exchange Type -- RFC 2408, section 3.1
> > > > - Certificate Encoding -- RFC 2408, section 3.9
> > > > - Notify Message Types -- RFC 2408, section 3.14.1 (subregistries:
> > Error
> > > > Types and Status Types) (Note: this is different from IPSEC Notify
> > Message
> > > > Types)
> > 
> > See my comments later for these.
> > 
> > > >
> > > > Please let us know what we can do.
> > > >
> > > > Thank you,
> > > > ~pearl
> > > >
> > > >
> > > > On Tue Sep 27 14:35:47 2011, pearl.liang wrote:
> > > > > Hi, Tero,
> > > > >
> > > > > i too apologize not responding earlier.  Thank you though for
> > > > > your helpful comments below about the variations between
> > > > > the two registries, isakmp-registry and ipsec-registry.  :(
> > > > > My comments with the prefix [pl] are inline to make sure i
> > understand
> > > > > the changes that need to be made to the registry.  If not,
> > please
> > > > > correct me.
> > > > >
> > > > > On Tue Sep 06 07:20:30 2011, [e-mail] wrote:
> > > > > > Pearl Liang via RT writes:
> > > > > > > resending this...(sorry).  Please advise what changes we can
> > make
> > > > > > > to the registry.  Questions are included in the below
> > message.
> > > > > >
> > > > > > Sorry, I have been bit busy...
> > > > > >
> > > > > > > > > > > On Fri Jul 15 13:42:20 2011, pearl.liang wrote:
> > > > > > > > > > >> Hello Tero, Sean and Stephen,
> > > > > > > > > > >>
> > > > > > > > > > >> We are working some old tickets.  We received some
> > edits
> > > > > > from Paul
> > > > > > > > > > Hoffman
> > > > > > > > > > >> for the registry ISAKMP registry at
> > > > > > > > > > >> http://www.iana.org/assignments/isakmp-registry.
> > > > > > > > > > >> We are contacting you as the expert/ADs for this
> > > > > parameter.
> > > > > > > > > > Apologies in
> > > > > > > > > > >> advance...this is a long message.
> > > > > > > > > > >>
> > > > > > > > > > >> Paul Hoffman's proposed changes are included in the
> > below
> > > > > > original
> > > > > > > > > > >> message.  Before we include his proposed changes,
> > can you
> > > > > > help to
> > > > > > > > > > clarify
> > > > > > > > > > >> the below questions and whether these changes are
> > okay
> > > > > and
> > > > > > should
> > > > > > > > > > be added
> > > > > > > > > > >> to the registry.  Any assistance you can provide is
> > much
> > > > > > > > > > appreciated.
> > > > > > > > > > >>
> > > > > > > > > > >> QUESTIONS:
> > > > > > > > > > >>
> > > > > >
> > > > > > > > > > >> Issue 1: RFCs 2407, 2408, and 2409 were all
> > obsoleted by
> > > > > > > > > > >> 4306, which defines Internet Key Exchange Version 2
> > > > > (IKEv2)
> > > > > > > > > > >> Parameters.
> > > > > > > > > > >>
> > > > > > > > > > >> Question: should the registry be updated to 4306
> > for all
> > > > > > > > > > >> references of 2407, 2408, and 2409?
> > > > > >
> > > > > > No. The IKEv1 and IKEv2 has completely separate registries,
> > and
> > > > > > RFC4306 created completely new set of registries and even when
> > it
> > > > > did
> > > > > > copy quite a lot of values from the existing IKEv1 registries,
> > new
> > > > > > allocations needs to be done separately in both registries if
> > > > > needed.
> > > > > >
> > > > > > Also note, that there is two sets of registries for IKEv1. The
> > > > > > isakmp-registry and the ipsec-registry (also called Internet
> > Key
> > > > > > Exchange (IKE) attributes).
> > > > > >
> > > > > > The difference between those two registries is bit messy. The
> > > > > > ipsec-registry is meant for parameters used for the IKE Phase
> > 1
> > > > > > negotiation when you do not want to use the IPsec DOI (domain
> > of
> > > > > > interpretation). The isakmp-registry is used when using IPsec
> > DOI
> > > > > > (rfc2407).
> > > > > >
> > > > > > So in general the ipsec-registry is used for the IKEv1 phase 1
> > (i.e.
> > > > > > when negotiating the IKE SA), and the isakmp-registry is used
> > for
> > > > > the
> > > > > > IKEv2 Phase 2 (i.e. when negotiating Child SA or ESP/AH SA).
> > > > > >
> > > > >
> > > > > [pl] OK, i'll not make any updates to that.
> > > > >
> > > > > > > > > > >> Issue 2: Paul proposed the following registration
> > for
> > > > > Group
> > > > > > > > > > >> Description (Value 3) under IPSEC Security
> > Association
> > > > > > > > > > >> Attributes:
> > > > > > > > > > >>
> > > > > > > > > > >> Sub-registry: Group Description (Value 3)
> > > > > > > > > > >> Reference: [RFC2407]??
> > > > > > > > > > >> Registration Procedures: ???
> > > > > > > > > > >>
> > > > > > > > > > >> Name Value Reference
> > > > > > > > > > >> ---- ----- ---------
> > > > > > > > > > >> First Oakley Group 1 [RFC2409]
> > > > > > > > > > >> Second Oakley Group 2 [RFC2409]
> > > > > > > > > > >> Third Oakley Group 3 [RFC2409]
> > > > > > > > > > >> Fourth Oakley Group 4 [RFC2409]
> > > > > > > > > > >> Fifth Oakley Group 5 [RFC2409]
> > > > > > > > > > >>
> > > > > > > > > > >> It appears that the Attribute Class 'Group
> > Description'
> > > > > was
> > > > > > > > > > >> defined as value #4 in RFC 2409. Also, I cannot
> > locate
> > > > > > > > > > >> Fifth Oakley Group in RFC
> > > > > > > > > > >> 2409.
> > > > > >
> > > > > > The RFC2409 refers to the ipsec-registry where it has value of
> > 3.
> > > > > The
> > > > > > isakmp-registry defines same parameter (but with value of 3)
> > and
> > > > > > refers to the RFC2409 for the values:
> > > > > >
> > > > > >
> > > > >
> > ----------------------------------------------------------------------
> > > > > >          Group Description
> > > > > >
> > > > > >            Specifies the Oakley Group to be used in a PFS QM
> > > > > >            negotiation.  For a list of supported values, see
> > > > > Appendix
> > > > > > A
> > > > > >            of [IKE].
> > > > > >
> > > > >
> > ----------------------------------------------------------------------
> > > > > >
> > > > > > Most of the implementations I know actually assume that the
> > this
> > > > > Group
> > > > > > Description (Value 3) registry in isakmp-registry is sharing
> > same
> > > > > > values than the Group Description (Value 4) registry in the
> > > > > > ipsec-registry.
> > > > > >
> > > > > > The ipsec-registry has much more values than what is mentioned
> > in
> > > > > > Paul's message.
> > > > > >
> > > > > > The 5th group (1536 bit MODP group) was originally described
> > as
> > > > > email
> > > > > > message to the ipsec list and implementors added it to their
> > code
> > > > > way
> > > > > > before it was officially documented. This oversigth was fixed
> > when
> > > > > > RFC3526 was published. The RFC3526 documented the existing
> > 1536
> > > > > group
> > > > > > and added several others.
> > > > > >
> > > > > > > > > > >> Question: Should we add the above to the registry?
> > And if
> > > > > > > > > > >> so, what should we put in the registration
> > procedures?
> > > > > >
> > > > > > I think it would be better to add pointer to the Group
> > Description
> > > > > > (Value 4) of the ipsec-registry instead as this is what
> > > > > > implementations currently do.
> > > > > >
> > > > >
> > > > > [pl] i can add a pointer to the ipsec-registry in the isakmp-
> > registry.
> > > > > Specifically, I can add the pointer to the Group Description
> > (Value 4)
> > > > > of the ipsec-registry when the registry is being converted to a
> > source
> > > > > of XML later.
> > > > >
> > > > > > > > > > >> Issue 3: It appears that new values of a sub-
> > registry
> > > > > > > > > > >> Compression Private Algorithm will be defined and
> > > > > assigned
> > > > > > > > > > >> by IEEE as noted in RFC 2407:
> > > > > > > > > > >>
> > > > > > > > > > >> Sub-registry: Compression Private Algorithm (Value
> > 9)
> > > > > > > > > > >> Reference: [RFC2407]
> > > > > > > > > > >> Registration Procedures: ???
> > > > > > > > > > >> Note:
> > > > > > > > > > >> Specifies a private vendor compression algorithm.
> > The
> > > > > > first
> > > > > > > > > > >> three (3) octets must be an IEEE assigned
> > company_id
> > > > > (OUI).
> > > > > > > > > > >> The next octet may be a vendor specific compression
> > > > > > subtype,
> > > > > > > > > > >> followed by zero or more octets of vendor data.
> > > > > > > > > > >>
> > > > > > > > > > >> Registry:
> > > > > > > > > > >> Value  Description       Reference
> > > > > > > > > > >> -----  ----------------  ---------
> > > > > > > > > > >> There are no registrations at this time
> > > > > > > > > > >>
> > > > > > > > > > >> Question: does the above look correct? And if so,
> > what
> > > > > > > > > > >> should we put in the registration procedures field?
> > > > > >
> > > > > > As this is private vendor specific numbers and it is already
> > using
> > > > > > IEEE assigned company_id to make sure there are no overlaps, I
> > think
> > > > > > the best would be to say that "IANA does not assign" in the
> > > > > > Registration Procedures.
> > > > > >
> > > > >
> > > > > [pl] will do.
> > > > >
> > > > > > > > > > >> Issue 4: The following registries Paul proposed (in
> > his
> > > > > > > > > > >> message) that are not currently listed in
> > > > > > > > > > >> http://www.iana.org/assignments/isakmp-registry:
> > > > > > > > > > >>
> > > > > > > > > > >> - Exchange Type -- RFC 2408, section 3.1
> > > > > >
> > > > > > As exchange types are not strictly part of the DOI I think
> > those
> > > > > > should be in the ipsec-registry, and there is already registry
> > for
> > > > > > those in there:
> > > > > >
> > > > > >
> > > > >
> > ----------------------------------------------------------------------
> > > > > > Registry Name: Additional Exchanges Defined-- XCHG values
> > > > > > Reference: [RFC2409]
> > > > > > Registration Procedures: Not defined
> > > > > >
> > > > > > Value   Phase            Reference
> > > > > > ------  ---------------  ---------
> > > > > > 32      Quick Mode       [RFC2409]
> > > > > > 33      New Group Mode   [RFC2409]
> > > > > >
> > > > >
> > ----------------------------------------------------------------------
> > > > > >
> > > > > > It does not have values of the original exchange types defined
> > in
> > > > > the
> > > > > > RFC2408. The RFC2408 defines those as:
> > > > > >
> > > > > >
> > > > >
> > ----------------------------------------------------------------------
> > > > > >     o  Exchange Type (1 octet) - indicates the type of
> > exchange
> > > > > being
> > > > > >        used.  This dictates the message and payload orderings
> > in the
> > > > > >        ISAKMP exchanges.
> > > > > >
> > > > > >
> > > > > >                             Exchange Type      Value
> > > > > >                          NONE                    0
> > > > > >                          Base                    1
> > > > > >                          Identity Protection     2
> > > > > >                          Authentication Only     3
> > > > > >                          Aggressive              4
> > > > > >                          Informational           5
> > > > > >                          ISAKMP Future Use     6 - 31
> > > > > >                          DOI Specific Use     32 - 239
> > > > > >                          Private Use         240 - 255
> > > > > >
> > > > >
> > ----------------------------------------------------------------------
> > > > > >
> > > > > > I.e. those new values are allocated from the DOI specific use
> > range,
> > > > > > even when they are not really DOI specific as there is no DOI
> > field
> > > > > in
> > > > > > the message where they are used, so I do not know how overlaps
> > with
> > > > > > DOI specific use numbers should be handled.
> > > > > >
> > > > > > One option is to assume that as they are allocated in the DOI
> > > > > specific
> > > > > > use range, the current registry from ipsec-registry should be
> > moved
> > > > > to
> > > > > > the isakmp-registry, but as I think it more logically belongs
> > to the
> > > > > > ipsec-registry, I would keep it there.
> > > > > >
> > > > >
> > > > > [pl] OK, no action is required in the isakmp-registry.  As for
> > ipsec-
> > > > > registry,
> > > > > should we update the existing registry 'Additional Exchanges
> > Defined--
> > > > > XCHG
> > > > > values' to include the above defined range (0-255)?
> > > > > What is the registration procedure?
> > 
> > No, I think it requres new registry and the additional exchanges is
> > part of that, i.e. it is that DOI Specific Use 32-239 in the Exchange
> > Type registry.
> > 
> > This new registry should be:
> > 
> > ----------------------------------------------------------------------
> > Registry Name: Exchange Type
> > Reference: [RFC2408]
> > 
> > Value   Exchange Type	     Reference
> > -----	------------------   ---------
> > 0       NONE		     [RFC2408]
> > 1	Base                 [RFC2408]
> > 2	Identity Protection  [RFC2408]
> > 3	Authentication Only  [RFC2408]
> > 4	Aggressive           [RFC2408]
> > 5	Informational        [RFC2408]
> > 
> > ----------------------------------------------------------------------
> > 
> > Registration procedure depends on the values:
> > 
> > ISAKMP Future Use     6 - 31
> > DOI Specific Use     32 - 239
> > Private Use         240 - 255
> > 
> > That DOI Specific use is the Additional Exchanges Defined registry
> > already in the ipsec-registry.
> > 
> > > > > > > > > > >> - Certificate Encoding -- RFC 2408, section 3.9
> > > > > >
> > > > > > This again would be better part of the ipsec-registry not
> > > > > > isakmp-registry as again this is phase 1 concept not phase 2
> > (or
> > > > > IPsec
> > > > > > SA related) concept.
> > > > > >
> > > > > > Actually I think all RFC2408 related stuff belongs to the
> > > > > > ipsec-registry, not isakmp-registry.
> > > > > >
> > > > > > This include already some registries which are now in the
> > > > > > isakmp-registry, i.e. ISAKMP Domain of Interpretation (DOI)
> > > > > > and Next Payload Types. Those should really be moved to the
> > > > > > ipsec-registry (i.e. phase 1 or IKE registry) from the isakmp-
> > > > > registry
> > > > > > (the phase 2 or Child SA for IPsec registry).
> > > > > >
> > > > >
> > > > > [pl] so, we should move both ISAKMP Domain of Interpretation
> > (DOI)
> > > > > and Next Payload Types to the ipsec-registry.  Correct?  And, is
> > 
> > Yes, and add that certificate encoding registry.
> > 
> > > > > 65535 the max value for ISAKMP Domain of Interpretation (DOI)?
> > 
> > No, it is 32-bit value, i.e. max value is 4294967295.
> > 
> > > > > > > > > > >> - Notify Message Types -- RFC 2408, section 3.14.1
> > > > > > > > > > >>   (subregistries: Error Types and Status Types)
> > (Note:
> > > > > this
> > > > > > > > > > >>   is different from IPSEC Notify Message Types)
> > > > > >
> > > > > > This base registry should be in the ipsec-registry not in the
> > > > > > isakmp-registry. The values already in the IPSEC Notify
> > Message
> > > > > Types
> > > > > > in the isakmp-registry should stay there, as they are Child SA
> > > > > > specific (i.e. from RFC2407), but the base notify registry
> > should be
> > > > > > in the phase 1 registry.
> > > > > >
> > > > >
> > > > > [pl] How about add a pointer to the sub-registry 'IPSEC Notify
> > Message
> > > > > Types' of the isakmp-registry to the ipsec-registry?
> > 
> > There is need to add the base registry to the ipsec-registry, and that
> > includes numbers between 0-8191 and 16384-24575.
> > 
> > Registry would be:
> > ----------------------------------------------------------------------
> > Registry Name: Notify Message Types
> > Reference: [RFC2408]
> > 
> > Subregistries procedures are:
> > 
> > 31 - 8191      Error types RESERVED (Future Use)
> > 8192 - 16383   Doi-Specific Error types
> > 16385 - 24575  Status types RESERVED (Future Use)
> > 24576 - 32767  DOI-specific Status codes
> > 32768 - 40959  Private Use
> > 40960 - 65535  RESERVED (Future Use)
> > 
> > Sub-Registry: Notify Messages - Error Types
> > 
> > Value Notify Messages - Error Types    Reference
> > ----- -----------------------------    ---------
> > 1     INVALID-PAYLOAD-TYPE             [RFC2408]
> > 2     DOI-NOT-SUPPORTED                [RFC2408]
> > 3     SITUATION-NOT-SUPPORTED          [RFC2408]
> > 4     INVALID-COOKIE                   [RFC2408]
> > 5     INVALID-MAJOR-VERSION            [RFC2408]
> > 6     INVALID-MINOR-VERSION            [RFC2408]
> > 7     INVALID-EXCHANGE-TYPE            [RFC2408]
> > 8     INVALID-FLAGS                    [RFC2408]
> > 9     INVALID-MESSAGE-ID               [RFC2408]
> > 10    INVALID-PROTOCOL-ID              [RFC2408]
> > 11    INVALID-SPI                      [RFC2408]
> > 12    INVALID-TRANSFORM-ID             [RFC2408]
> > 13    ATTRIBUTES-NOT-SUPPORTED         [RFC2408]
> > 14    NO-PROPOSAL-CHOSEN               [RFC2408]
> > 15    BAD-PROPOSAL-SYNTAX              [RFC2408]
> > 16    PAYLOAD-MALFORMED                [RFC2408]
> > 17    INVALID-KEY-INFORMATION          [RFC2408]
> > 18    INVALID-ID-INFORMATION           [RFC2408]
> > 19    INVALID-CERT-ENCODING            [RFC2408]
> > 20    INVALID-CERTIFICATE              [RFC2408]
> > 21    CERT-TYPE-UNSUPPORTED            [RFC2408]
> > 22    INVALID-CERT-AUTHORITY           [RFC2408]
> > 23    INVALID-HASH-INFORMATION         [RFC2408]
> > 24    AUTHENTICATION-FAILED            [RFC2408]
> > 25    INVALID-SIGNATURE                [RFC2408]
> > 26    ADDRESS-NOTIFICATION             [RFC2408]
> > 27    NOTIFY-SA-LIFETIME               [RFC2408]
> > 28    CERTIFICATE-UNAVAILABLE          [RFC2408]
> > 29    UNSUPPORTED-EXCHANGE-TYPE        [RFC2408]
> > 30    UNEQUAL-PAYLOAD-LENGTHS          [RFC2408]
> > 
> > 
> > Sub-Registry: Notify Messages - Status Types
> > 
> > Value Notify Messages - Status Types    Reference
> > ----- ------------------------------    ---------
> > 16384 CONNECTED                         [RFC2408]
> > 
> > ----------------------------------------------------------------------
> > 
> > > > > > > > > > >> - ISAKMP Security Association Attributes -- RFC
> > 2408,
> > > > > > > > > > >>   Appendix A  (This isn't really a registry; this
> > is a
> > > > > > note)
> > > > > >
> > > > > > This does not belong to the isakmp-registry. It does not
> > really
> > > > > belong
> > > > > > to the ipsec-registry either. I would ignore this completely.
> > As far
> > > > > > as I know nobody uses the values defined in that appendix.
> > > > > >
> > > > >
> > > > > [pl] OK.
> > > > >
> > > > > > > > > > >> Question: should we add them?
> > > > > >
> > > > > > I would not add them to isakmp-registry, but add them (when
> > needed)
> > > > > to
> > > > > > the isakmp-registry.
> > > > > >
> > > > > > > > > > >>> -------- Original Message --------
> > > > > > > > > > >>> Subject: 	Proposed changes to the ISAKMP registry
> > > > > > > > > > >>> Date: 	Wed, 6 Mar 2002 20:00:54 -0800
> > > > > > 				   ^^^^
> > > > > >
> > > > > > Wow, this is old. And I though I am slow to respond... :-)
> > > > > >
> 
-- 
[e-mail]