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

ipsec error codes

At the Minneapolis IETF, a few of us agreed to work on the ipsec error
codes draft Bob Moskowitz has been calling for. Bob's initial suggestion
was to take a look at the smtp response codes as an example. This is
probably a good starting point for the discussion, and I'd like to
solicit general input before producing a draft.

I believe the smtp response codes are derived from the ftp response
codes, and essentially consist of a 3 digit number followed by human
readable text. Typically, the text is standardized, and in some cases
contains fields which are inserted by the sender such as domain, path,
etc. Each digit has a semantic meaning, i.e. the first digit indicates
the status (complete, incomplete, or failed), the second digit encodes
an error type, and the third digit further refines the second digit.

I think an important point is that reply codes for ftp/smtp are just
that: *reply* codes. That is, they are sent in response to commands, and
are meant to facilitate state machine processing. From RFC 959,

      Replies to File Transfer Protocol commands are devised to ensure
      the synchronization of requests and actions in the process of file
      transfer, and to guarantee that the user process always knows the
      state of the Server.  Every command must generate at least one
      reply, although there may be more than one; in the latter case,
      the multiple replies must be easily distinguished.  In addition,
      some commands occur in sequential groups, such as USER, PASS and
      ACCT, or RNFR and RNTO.  The replies show the existence of an
      intermediate state if all preceding commands have been successful.
      A failure at any point in the sequence necessitates the repetition
      of the entire sequence from the beginning.

The important point here is that they are defined with particular
semantic goals, which may or may not encompass the requirements of our
situation. This brings us to a question: what, exactly, are our
requirements?

As a first cut, I'd say our requirements are these:

   1) a standard message format, as opposed to simply numeric codes;
      this format would include the items listed below.

        o numeric codes which encode the following:
            - standard event codes; note that event codes are 
              different than reply codes sometimes.
            - priority (perhaps like syslog)
            - originating element (e.g. isakmp, SPD, SAD, esp, ah, etc)

        o relative timestamp

        o standardized text portion containing variable fields which are
          filled in during message construction, e.g. ip address,
spi,etc.

I'd like some input on this before attempting to write up something more
substantial. Are there additional requirements? Are the ones specified
here correct?

Scott
Follow-Ups: References: