[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-notifymsg-00.txt (long again)
I managed to check this out only now. I would really like to see all
the notification data fields to have data attribute list instead of
fixed fields. That would solve quite a lot of problems. We could add
attributes like:
type value da type
-------------------------------------------------------------------
Type of Offending Payload 1 B
Offending Payload Data 2 V
Error Position Offset 3 B
Error Text Describing the Problem 4 V
Error Text Language 5 V
Message Id of the Offending Negotiation 6 V
Exchange Type of Negotiation 7 B
Invalid Flag Bits 8 B
-------------------------------------------------------------------
Type of Offending Payload
Payload type of the offending payload encoded as 16 bit
interger.
Offending Payload Data
Offeding payload data included the generic header. Note that
next payload type points to the next payload, it does not
specify the type of this payload. If the payload type is not
unique inside the error code the type of offending payload
must be given separately.
Error Position Offset
Byte offset of the error position from the beginning of the
offending payload (must be given also).
Error Text Describing the Problem
Text describing the problem. (ISO-10646 UTF-8 encoding).
Error Text Language
Error text language tag (as defined in RFC 1766).
Message Id of the Offending Negotiation
Message id of the offending negotiation encoded has 4 byte
value.
Exchange Type of Negotiation
Exchange type of the offeding negotiation. Encoded as 16 bit
integer.
Invalid Flag Bits
Invalid flags (valid flags are masked out) Encoded as 16 bit
integer.
That would make processing of the notifications identical for all
cases, and we don't have to have special code to handle all different
kind of notifications. Also in that case vendors can add special stuff
in the notification data without breaking other implementations (we
should say that all unknown data attribute types must simply be
ignored).
Also extending the format later is quite easy, and offers backward
compatibility. Also implementations are allowed to just leave out the
whole data part if they don't want to fill it in.
> 2.1 INVALID-PAYLOAD-TYPE
> When present, the Notification Payload MUST have the following
> format:
>
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to the current DOI for this negotiation
We might not have DOI yet. SA payload might not yet be parsed, or
there might not be SA payload (transactional, information exchange). I
would say we should ALWAYS use ISAKMP_DOI (0) here.
> o Protocol ID - set to selected Protocol ID from chosen SA
Same here, we might not have protocol ID from the SA yet. I would
suggest that we always reserve value 0 to be specify error in the
isakmp protocol, in which case the SPI will always be the ISAKMP
cookies of the offending packet.
Note, they might be different from the ones stored in the header. For
example if we have ISAKMP SA up and running and we start rekey, which
fails, we might send the error message back using the old ISAKMP SA to
get protection for the notification, so we must identify the ISAKMP SA
somewhere.
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
I would suggest this 0 or 16. The value 0 means that the ISAKMP
cookies can be seen from the header (== we are using same ISAKMP SA to
send notification back than what cause the problem).
> o Notify Message Type - set to INVALID-PAYLOAD-TYPE
> o SPI - set to empty or to the sender's inbound
> IPSEC SPI
So this should be the isakmp cookies (== spi of the ISAKMP SA) or
empty.
> o Notification Data - contains the subject payload
Notification data SHOULD contain the type of offending payload, and it
MAY contain offending payload data, error text describing the problem
and message id of the offending negotiation.
> 2.2 DOI-NOT-SUPPORTED
> o DOI - set to the subject (unsupported) DOI
I think this should again be ISAKMP DOI.
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI)
> o Notify Message Type - set to DOI-NOT-SUPPORTED
> o SPI - set to empty or to the sender's inbound IPSEC SPI
If the DOI is unsupported, we cannot parse the SA payload, because we
do not know the length and format of the situation field. So we cannot
fill in the Protocol id, spi size, and spi from the SA payload. I
would suggest we fill them similarly than in INVALID-PAYLOAD-TYPE case
above.
> o Notification Data - empty
This SHOULD contain offending payload data, and message id of the
offending negotiation, and it MAY contain error position offset, and
error text describing the problem.
> 2.3 SITUATION-NOT-SUPPORTED
> o Payload Length - set to length of payload + size of data (4)
> o DOI - set to DOI included in SA payload with situation
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
> o Notify Message Type - set to SITUATION-NOT-SUPPORTED
> o SPI - set to empty or to the sender's inbound IPSEC SPI
There is really no point filling in the protocol ID, and spi, because
we might not yet have selected anything. I would suggest similar
handling than above.
> o Notification Data - contains unsupported situation value
This SHOULD contain Offending Payload Data, and Message Id of the
Offending Negotiation, and it MAY contain Error Position Offset, and Error
Text Describing the Problem.
> 2.4 INVALID-COOKIE
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to IPSEC DOI (1)
This should defenately be ISAKMP DOI (0).
> o Protocol ID - set to PROTO_ISAKMP
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-COOKIE
> o SPI - empty
And we must fill in the SPI size to 16, and SPI data to cookies of the
offending payload so the other end can find the ISAKMP SA that is
expired or invalid.
> o Notification Data - contains the invalid cookie (size may be
> derived from payload length
This SHOULD contain Message Id of the Offending Negotiation, and it
MAY contain Error Text Describing the Problem.
> 2.5 INVALID-MAJOR-VERSION
> o Payload Length - set to length of payload + size of data (5)
> o DOI - set to DOI under which message was received
We haven't parsed the SA payload yet, so we don't know the DOI, so it
should be ISAKMP DOI (0).
> o Protocol ID - set to PROTO_ISAKMP
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-MAJOR-VERSION
> o SPI - empty
Again, I would put the ISAKMP SPI (cookies) of the offending packet
here (16 bytes).
> o Notification Data - contains the message ID, followed by the
> invalid version octet
This SHOULD contain Message Id of the Offending Negotiation, and it
MAY contain Error Text Describing the Problem.
The version supported by the other end can be seen from the header of
this notification, the sender fills it with his own version number.
> 2.6 INVALID-MINOR-VERSION
Same than INVALID-MAJOR-VERSION.
> 2.7 INVALID-EXCHANGE-TYPE
> o Payload Length - set to length of payload + size of data (1)
> o DOI - set to DOI under which message was received
We do not have DOI yet, so ISAKMP DOI (0).
> o Protocol ID - set to PROTO_ISAKMP
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-EXCHANGE-TYPE
> o SPI - empty
Again, ISAKMP SA SPI here.
> o Notification Data - contains the invalid exchange type octet
This SHOULD contain Message Id of the Offending Negotiation, and it
MAY contain Error Text Describing the Problem.
No need to put the invalid exchange type, because the sender can find
it from the message id. If we want to put it here, just add one more
attribute type.
> 2.8 INVALID-FLAGS
> o Payload Length - set to length of payload + size of data (1)
> o DOI - set to DOI under which message was received
> o Protocol ID - set to PROTO_ISAKMP
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-FLAGS
> o SPI - empty
Same as above, ISAKMP DOI, ISAKMP SA SPI.
> o Notification Data - contains the flags octet with only
> the unknown/invalid flags bits set (valid bits masked off)
I am not sure if that is really needed, but it might be useful.
> 2.9 INVALID-MESSAGE-ID
> o Payload Length - set to length of payload
> o DOI - set to DOI under which message was received
> o Protocol ID - set to PROTO_ISAKMP
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-MESSAGE-ID
> o SPI - empty
Same as above, ISAKMP DOI, ISAKMP SA SPI.
> o Notification Data - empty
This SHOULD contain Message Id of the Offending Negotiation, and it
MAY contain Error Text Describing the Problem.
> In this case, the invalid message ID is contained in the ISAKMP
> header of the notify message.
Somebody already commented this, no need to say more about it.
> 2.10 INVALID-PROTOCOL-ID
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to invalid protocol ID value
I would leave that Protocol ID to 0, and put that invalid protocol
value in the data.
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-PROTOCOL-ID
> o SPI - empty
> o Notification Data - contains the proposal payload in which the
> unrecognized protocol ID was found.
Notification data SHOULD contain the offending (SA) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
Now the error position offset points inside to the SA payload to the
byte which contains the invalid protocol id.
> 2.11 INVALID-SPI
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from offending SA
> proposal
> o SPI Size - set to zero (0)
> o Notify Message Type - set to INVALID-SPI
> o SPI - empty
> o Notification Data - contains the proposal payload in which the
> invalid SPI was found.
Again I would use similar approach than in INVALID-PROTOCOL-ID, i.e
protocol ID 0, empty spi, and notification data SHOULD contain the
offending (SA) payload data, error position offset, and Message Id of
the Offending Negotiation, and it MAY contain error text describing
the problem.
> 2.12 INVALID-TRANSFORM-ID
> o Payload Length - set to length of payload + size of data (2)
> o DOI - set to DOI of received packet
> o Protocol ID - set to Protocol ID from proposal containing
> subject
> transform ID
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
> o Notify Message Type - set to INVALID-TRANSFORM-ID
> o SPI - set to empty or to the sender's inbound IPSEC SPI
> o Notification Data - contains the transform number, followed by
> the invalid transform ID.
I would make this identical to INVALID-PROTOCOL-ID.
> 2.13 ATTRIBUTES-NOT-SUPPORTED
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from subject SA
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
> o Notify Message Type - set to ATTRIBUTES-NOT-SUPPORTED
> o SPI - set to empty or to the sender's inbound IPSEC SPI
> o Notification Data - contains an ISAKMP attribute list consisting
> of the unsupported attributes
In this case we can use protocol ID, and SPI, but then I would also
defined that the SPI must be from the same proposal payload which
contains the offending transform (or first of them).
Notification data SHOULD contain the offending (SA) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.14 NO-PROPOSAL-CHOSEN
> o Payload Length - set to length of payload
> o DOI - set to DOI of received packet
> o Protocol ID - set to PROTO_ISAKMP
> o SPI Size - set to zero (0)
Size 16.
> o Notify Message Type - set to NO-PROPOSAL-CHOSEN
> o SPI - set to the two ISAKMP cookies
> o Notification Data - empty
Notification data SHOULD contain the Message Id of the Offending
Negotiation, and it MAY contain error text describing the problem.
There might be use to put SA payload data and error position offset so
that the error position offset points to the first byte which didn't
match the policy, but it might be too complicated to really be
usefull.
> 2.15 BAD-PROPOSAL-SYNTAX
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
I would put PROTO_ISAKMP here.
> o SPI Size - set to zero (0) (SPI is in proposal)
Size 16 or 0 depending if the ISAKMP SPI is same than notification
packet or not.
> o Notify Message Type - set to BAD-PROPOSAL-SYNTAX
> o SPI - empty
ISAKMP SPI or empty.
> o Notification Data - contains the improperly-formed proposal or
> transform payload
> [Note: There's an ambiguity here due to overloading this error
> type. It would be resolved by adding a BAD-TRANSFORM-SYNTAX error,
> and only using this one for proposals. Alternatively, we could
> add
> an identifier to this message to distinguish between the two
> cases]
I would always put in the SA payload. I.e notification data SHOULD
contain the offending (SA) payload data, error position offset, and
Message Id of the Offending Negotiation, and it MAY contain error text
describing the problem.
Here the offending byte would point to the error inside the SA
payload.
> 2.16 PAYLOAD-MALFORMED
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
We might not yet have DOI yet, so ISAKMP DOI (0).
> o Protocol ID - set to PROTO_ISAKMP
Selected protocol if we have it or PROTO_ISAKMP (in which case the SPI
must be ISAKMP SA SPI).
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
0, 2, 4 or 16. We might not yet have IPSEC SPI.
> o Notify Message Type - set to PAYLOAD-MALFORMED
> o SPI - set to empty or to the sender's inbound IPSEC SPI
If protocol ID is PROTO_ISAKMP then this should contain ISAKMP SA SPI
(cookies), or if the protocol id is something else (AH/ESP/IPCOMP)
then that SPI.
> o Notification Data - contains the offending payload
> [Note: This overlaps with BAD-PROPOSAL-SYNTAX...]
Notification data SHOULD contain the type of offending payload, the
offending payload data, error position offset, and Message Id of
the Offending Negotiation, and it MAY contain error text describing
the problem.
> 2.17 INVALID-KEY-INFORMATION
> The INVALID-KEY-INFORMATION error message may be used to communicate
> that the key exchange type specified by the key exchange payload is
> not supported.
There is no key exchange type in the KE payload. There is a key
exchange transform ID in the SA payload (KEY_IKE). This should only be
sent if the KE payload is invalidly formatted (too short/long etc).
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
Depending of the Protocol ID this should be either 0 or 16
(PROTO_ISAKMP) or 2/4 (IPCOMP/IPSEC).
> o Notify Message Type - set to INVALID-KEY-INFORMATION
> o SPI - set to empty or to the sender's inbound IPSEC SPI
If protocol ID is PROTO_ISAKMP then this should contain ISAKMP SA SPI
(cookies), or if the protocol id is something else (AH/ESP/IPCOMP)
then that SPI.
> o Notification Data - contains the subject key exchange payload
Notification data SHOULD contain the offending (KE) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.18 INVALID-ID-INFORMATION
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to PROTO_ISAKMP
For phase 2 this should be selected Protocol ID, and PROTO_ISAKMP if
in phase 1.
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
Size = 0, 2, 4, 16.
> o Notify Message Type - set to INVALID-ID-INFORMATION
> o SPI - set to empty or to the sender's inbound IPSEC SPI
Same stuff here than above.
> o Notification Data - contains subject ID payload
Notification data SHOULD contain the offending (ID) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.19 INVALID-CERT-ENCODING
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
It cannot be IPSEC SPI, only ISAKMP SPI is valid (0, or 16 bytes). So
it must also be PROTO_ISAKMP.
> o Notification Data - contains the certificate payload
Notification data SHOULD contain the offending (CERT) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.20 INVALID-CERTIFICATE
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
It cannot be IPSEC SPI, only ISAKMP SPI is valid (0, or 16 bytes). So
it must also be PROTO_ISAKMP.
> o Notification Data - contains subject certificate payload
Notification data SHOULD contain the offending (CERT) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.21 CERT-TYPE-UNSUPPORTED
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
Same here.
> o Notification Data - contains the subject certificate payload
Notification data SHOULD contain the offending (CERT) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.22 INVALID-CERT-AUTHORITY
>
> The INVALID-CERT-AUTHORITY error message may be used to communicate
> that the Certificate Authority in a certificate payload is invalid or
> improperly formatted.
Not in certificate payload, but in certificate request payload.
> Phase: 1 or 2
Phase 1 only.
> Differentiator: Cookies, message ID, SPI, CERT payload
CR payload.
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
See above
> o Notification Data - contains the subject certificate payload
Notification data SHOULD contain the offending (CR) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.23 INVALID-HASH-INFORMATION
> o Payload Length - set to length of payload + size of data (1)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
We might not have DOI / protocol / SPI yet. For example this might be
the first payload of the quick mode and the first hash payload is
invalid... So it should be ok to use PROTO_ISAKMP, and ISAKMP SPI.
> o Notification Data - contains the subject hash payload
Notification data SHOULD contain the offending (HASH) payload data,
error position offset, and Message Id of the Offending Negotiation,
and it MAY contain error text describing the problem.
> 2.24 AUTHENTICATION-FAILED
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to zero (0)or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound
> IPSEC SPI
Might not be IPSEC SPI, which failed, so PROTO_ISAKMP, and ISAKMP SA
SPI should also be allowed.
> o Notification Data - empty
Notification data SHOULD contain Message Id of the Offending
Negotiation, and it MAY contain error text describing the problem.
> 2.25 INVALID-SIGNATURE
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
Again ISAKMP SA SPI must also be allowed.
> o Notification Data - contains the subject signature payload
Notification data SHOULD contain Message Id of the Offending
Negotiation, and it MAY contain error text describing the problem.
> 2.27 NOTIFY-SA-LIFETIME
> o SPI Size - set to zero(0) o Notify Message Type - set to
> NOTIFY-SA-LIFETIME
Formatting error.
> o SPI - empty
SPI should be the IPSEC or ISAKMP SA SPI. Not empty.
> 2.28 CERTIFICATE-UNAVAILABLE
> o Payload Length - set to length of payload + size of data (var)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to zero (0) or four (4) (one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
Normally this is PROTO_ISAKMP, spi size 0 or 16, and ISAKMP SA SPI.
> o Notification Data - contains the subject certificate request
Notification data SHOULD contain the offending (CR) payload data and
Message Id of the Offending Negotiation, and it MAY contain error text
describing the problem.
> 2.29 UNSUPPORTED-EXCHANGE-TYPE
> o DOI - set to DOI of received packet
We do not have DOI, so ISAKMP DOI (0).
> o Protocol ID - set to selected Protocol ID from chosen SA
We do not have protocol, so PROTO_ISAKMP.
> o SPI Size - set to zero (0) or four (4)(one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
ISAKMP SA SPI.
> o Notification Data - contains the message ID, followed by the
> invalid exchange type octet
This SHOULD contain Message Id of the Offending Negotiation, and it
MAY contain Error Text Describing the Problem.
We might want to add that exchange type also here.
> 2.30 UNEQUAL-PAYLOAD-LENGTHS
> The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate
> that message length in the ISAKMP header does not match the sum of
> the actual payload lengths.
It can also be used when for example data attributes values are longer
than transform payload, or spi size causes sa payload to overflow etc.
> o Payload Length - set to length of payload + size of data (4)
> o DOI - set to DOI of received packet
> o Protocol ID - set to selected Protocol ID from chosen SA
> o SPI Size - set to zero (0) or four (4)(one IPSEC SPI)
> o SPI - set to empty or to the sender's inbound IPSEC SPI
Quite often we do not have DOI or IPSEC SPI, so ISAKMP_DOI /
PROTO_ISAKMP / ISAKMP SA SPI should also be allowed.
> o Notification Data - contains the actual payload length as a
> 32-bit unsigned value.
Notification data SHOULD contain the type of offending payload, and it
MAY contain offending payload data, error position offset, error text
describing the problem and message id of the offending negotiation.
If error position offset is given it points to place where the buffer
overflow is detected. For example if the spi size is set to 16 bytes,
and the generic Notify payload header doesn't include that to size (it
has size of 12 bytes) then it points to the SPI size byte inside the
notify payload.
> 3.1 CONNECTED
> o SPI - set to the the sender's inbound IPSEC SPI
Selected SPI. In phase 1 ISAKMP SA SPI (or empty), in phase 2 one of
the selected SPIs (there can be multiple of them if we have multiple
protocols (AH/ESP/IPCOMP)).
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups: