Notify message types
Michael Richardson <mcr@sandelman.ottawa.on.ca> Thu, 05 March 1998 07:05 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id CAA20049 for ipsec-outgoing; Thu, 5 Mar 1998 02:05:01 -0500 (EST)
Message-Id: <199803050545.AAA10925@morden.sandelman.ottawa.on.ca>
To: ipsec@tis.com
cc: wdm@tycho.ncsc.mil
Subject: Notify message types
Date: Thu, 05 Mar 1998 00:45:19 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE----- There was a brief discussion at the IPsec workshop on end client issues, specifically relating to configuration. One issue that came up was that it is difficult to report errors to the user in a reasonable way. Notifies carry no information text, and do not indicate which payload was at fault. I volunteered to write some text for the DOI that describes the DOI-defined notification data field. I will post my minutes from that meeting. Perhaps someone else will also do that. Questions: 1. why does the notify message space define a DOI specified status types, but no DOI specified error types? 2. ipsec-doi-07.txt reserves one of the private use numbers (8192) as being "RESERVED"... why? Is it historical? A proposal for the upcoming isakmp-09 document: I'd like to suggest that the Notify types be reworked to say: 3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size !A|R|F| Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Yes, Doug, can we *please* number the bits based on their network byte order significance, with the significance of the bits being their 2^x value] A - abort bit, R is registry bit, F tells me which "file" (aka document) to look in. {Abort, Retry, Fail?} It would be *nice* to simplify it to: A = 0 - errors that cause the negotiation to be (A)borted A = 1 - errors that don't cause the negotiation to be (A)borted R = 0 - registered (standards document defined) values R = 1 - private use values F = 0 - ISAKMP defined values F = 1 - DOI defined values This results in: 0b000xxxxxxxxxxxxx 0-8191 - ISAKMP error codes 0b001xxxxxxxxxxxxx 8192-16383 - DOI error codes 0b010xxxxxxxxxxxxx 16384-24575 - private use ISAKMP error codes 0b011xxxxxxxxxxxxx 24576-32767 - private use DOI error codes 0b100xxxxxxxxxxxxx 32768-40959 - ISAKMP status codes 0b101xxxxxxxxxxxxx 40960-49151 - DOI status codes 0b110xxxxxxxxxxxxx 49152-57343 - private use ISAKMP status codes 0b111xxxxxxxxxxxxx 57344-65535 - private use DOI status codes Unfortunately, that results in changes to bits on the wire. Specifically, it moves msg before after CONNECTED 16384 32768 RESPONDER-LIFETIME 24576 40960 REPLAY-STATUS 24577 40961 INITIAL-CONTACT 24578 40962 Note, the DOI's RESERVED moves into the newly created DOI error codes section, but doesn't change value. So, after some thought, I swapped the bits around: 3 2 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size !R|A|F| Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RAF 0b000xxxxxxxxxxxxx 0-8191 - ISAKMP error codes 0b001xxxxxxxxxxxxx 8192-16383 - DOI error codes 0b010xxxxxxxxxxxxx 16384-24575 - ISAKMP status codes 0b011xxxxxxxxxxxxx 24576-32767 - DOI status codes 0b100xxxxxxxxxxxxx 32768-40959 - private use ISAKMP error codes 0b101xxxxxxxxxxxxx 40960-49151 - private use DOI error codes 0b110xxxxxxxxxxxxx 49152-57343 - private use ISAKMP status codes 0b111xxxxxxxxxxxxx 57344-65535 - private use DOI status codes I think that this maintains all the current numbers, moving only the private use values around. Can someone verify my belief? Thus, no bits on the wire change unless someone has already started to use some of the private use error codes. This now tells me what to do with notify types that I don't understand. Status codes one can ignore, errors cause the negotiation to fail. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNP475x4XQavxnHg9AQFXwQH/THjgn5FnAZwT5OvzqHntlZAjqQbgPWw+ 1zdji3NPnz3FCF3qWliAs3Cr4c8+fDDLnx2HAqnElBUg3B829x3y9Q== =2BsN -----END PGP SIGNATURE-----
- Notify message types Michael Richardson
- Re: Notify message types Derrell D. Piper