[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-notifymsg-00.txt (long)
<fontfamily><param>Courier New</param><bigger>This is an excellent and
much-needed document. I just have 2 general
comments:
1) In a number of messages, rather than placing the erroneous data
in the Notification Data field, you've incorporated it into another
Notification Payload field (e.g., for INVALID-PROTOCOL-ID the invalid
protocol value is placed in the Protocol ID field). This necessitates
individualized processing for these messages; whether or not that
processing will take place, it would be helpful if a standardized
logging routine could just save the Notify Message Type and the
Notification Data.
2) For each message, you've indicated the Phase and the
Differentiators. It would also be helpful to list the relevant payloads
to which the message applies. (I've added those in my comments; if the
consensus
is that this isn't useful, that's OK with me.)
>2.1 INVALID-PAYLOAD-TYPE
>
> The INVALID-PAYLOAD-TYPE error message may be used to communicate
> that an unrecognized or invalid payload type was received.
>
This should also apply to unsupported payloads. As IKE versions
proliferate, new payloads may be added that are not supported by
existing implementations. It should also apply to out-of-order
payload types, e.g., a Phase 2 SA payload that precedes the Hash
Payload.
Payloads: ALL
>2.2 DOI-NOT-SUPPORTED
>
> o DOI - set to the subject (unsupported) DOI
This should (also) be in the Notification Data Field.
Payloads: SA
>2.3 SITUATION-NOT-SUPPORTED
>
Payloads: SA
>2.4 INVALID-COOKIE
>
> The INVALID-COOKIE error message may be used to communicate that an
> invalid ISAKMP cookie was received.
>
What's an invalid ISAKMP cookie? Does this message apply when the peer
initiates a Quick Mode negotiation for an expired Phase 1 SA?
If so, this should be explicitly stated.
Payloads: ISAKMP Header
>2.5 INVALID-MAJOR-VERSION
>
Payloads: ISAKMP Header
>2.6 INVALID-MINOR-VERSION
>
Payloads: ISAKMP Header
>2.7 INVALID-EXCHANGE-TYPE
>
> The INVALID-EXCHANGE-TYPE error message may be used to communicate
> that that an unrecognized or invalid ISAKMP exchange type was
> received.
>
Should this also apply to unsupported exchange types? (I think this is
the only case
where we have separate messages for invalid and unsupported.)
Payloads: ISAKMP Header
>2.8 INVALID-FLAGS
>
> The INVALID-FLAGS error message may be used to communicate that one
> or more of the received ISAKMP header flags were unrecognized or
> invalid.
>
Should this message be used in the following cases:
1) An unencrypted message is received, which should have been
encrypted.
2) An encrypted message is received, which should have been
unencrypted.
If so, this should be explicitly stated.
Payloads: ISAKMP Header
>2.9 INVALID-MESSAGE-ID
>
> o Notify Message Type - set to INVALID-MESSAGE-ID
>
This should (also) be in the Notification Data Field.
Payloads: ISAKMP Header
>2.10 INVALID-PROTOCOL-ID
>
> The INVALID-PROTOCOL-ID error message may be used to communicate
that
> an invalid or unrecognized protocol ID was received as part of a
> proposal payload.
>
Is unrecognized the same as unsupported? In either case, I think
unsupported
should be mentioned here. (picky, picky!!)
Payloads: Proposal
>2.11 INVALID-SPI
>
Payloads: Proposal
>2.12 INVALID-TRANSFORM-ID
>
Payloads: Transform
>2.13 ATTRIBUTES-NOT-SUPPORTED
>
Payloads: Transform
>2.14 NO-PROPOSAL-CHOSEN
>
Payloads: SA
>2.15 BAD-PROPOSAL-SYNTAX
>
Payloads: Generic Payload Header, Proposal, Transform
>2.16 PAYLOAD-MALFORMED
>
> The PAYLOAD-MALFORMED error message may be used to communicate that
a
> malformed payload was received.
>
This includes proposals/transforms/attributes that are syntactically
incorrect.
Anything else?
Payloads: Generic Payload Header, Proposal, Transform
>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.
>
Wouldn't this also include key info that is not the correct length/size
for the key exchange?
Payloads: Key Exchange
>2.18 INVALID-ID-INFORMATION
>
Payloads: ID
>2.19 INVALID-CERT-ENCODING
>
Payloads: Certificate, Certificate Request
>2.20 INVALID-CERTIFICATE
>
Payloads: Certificate
>2.21 CERT-TYPE-UNSUPPORTED
>
Payloads: Certificate Request
>2.22 INVALID-CERT-AUTHORITY
>
Payloads: Certificate Request
>2.23 INVALID-HASH-INFORMATION
>
> The INVALID-HASH-INFORMATION error message may be used to
communicate
> that the required hash type is not supported.
>
Wouldn't this include a hash of the wrong length/size?
Payloads: Hash
>2.24 AUTHENTICATION-FAILED
>
Payloads: Hash, Signature
>2.25 INVALID-SIGNATURE
>
Payloads: Signature
>2.26 ADDRESS-NOTIFICATION
>
Payloads: ??
>2.27 NOTIFY-SA-LIFETIME
>
Payloads: Transform
>2.28 CERTIFICATE-UNAVAILABLE
>
Payloads: Certificate Request
>2.29 UNSUPPORTED-EXCHANGE-TYPE
>
> The UNSUPPORTED-EXCHANGE-TYPE error message may be used to
> communicate that the requested exchange type is not supported.
>
Do we need this? (I think this is the only case
where we have separate messages for invalid and unsupported.)
Payloads: ISAKMP Header
>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.
This also applies in the case where the message length in the ISAKMP
header
does not match the length of the message that was actually received. It
should
probably also apply to other length-related anomalies.
Payloads: ISAKMP Header</bigger></fontfamily>
Follow-Ups: