[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-notifymsg-00.txt (long again)
Sorry to take so long to reply to this. I think I agree with most if not
all of your points, and will make the needed changes to the doc. Also,
since I have heard no dissent regarding the use of attribute lists to
contain the notification fields, I will also incorporate this change.
Tero Kivinen wrote:
>
> 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/
References: