[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

notify message payloads



Hi Kivinen and Tamir,

Last December you had a discussion regarding what should be in the data
portion of notification messages, and what was suggested was an
attribute list. Below is an extract from the relevant message:

Tero Kivenen wrote:
> I would like to see that the notification data is always list of
> attributes. This way we can easily add stuff later when we want to add
> more things. Currently the RESPONDER-LIFETIME already uses that. In
> that case we could have new attribute type numbers like:
> 
>         Failing SA proposal                             256
>         Error message text (default: UTF-8, english)    257
>         ...
> 
> And then I can include list of two attributes to the notification,
> one containing the failing SA proposal, and the second onme includes
> the error message text, saying something like "Phase I proposal
> rejected because of policy required 3DES encryption, and no proposal
> matching that was found". 

I have a couple of questions. First, what prompted the selection of the
attribute numbers? I can't find any defined attribute types in the
isakmp doc, and all it says about them is 

    o  Attribute Type (2 octets) - Unique identifier for each type of
       attribute.  These attributes are defined as part of the DOI-
       specific information.

In the DOI doc, the only attributes defined are SA attrs. As I see it,
there are two issues here. First, there are (apparently) no attributes
defined for DOI zero (0), though some of our notify messages clearly
could be outside of the ipsec doi. Second, the attributes defined for
the ipsec doi aren't yet segregated into attribute classes. I guess you
could argue that they *are* since there is currently only one class :-)
but on the other hand, there is no mechanism defined for adding new
attributes in a manner which insures adequate contiguous number space
for existing attr class expansion, etc.

The IKE document says

   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.

but I did a quick search at IANA and didn't find any attribute classes
defined (not even for the ipsec doi). I guess I could have missed
something, in which case someone can correct me, but otherwise, we need
to figure out what to do about this.

Scott