[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-notifymsg-00.txt (long)
Hi Sheila,
More responses to your comments below...
> Sheila Frankel wrote:
>
<trimmed...>
> >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.
>
This turns up a good point. There are a couple of situations under which
an invalid cookie occurs:
- one cookie matches, and one doesn't
- neither cookie matches
In the first case, there is (probably) some sort of bug or error on the
other end. In the second case, the SA has probably expired. I can add
clarifying language, and I think the receiving end can figure out which
case it is based upon the number of cookies returned in the notify
message, i.e. if it's the first case, only return the (single) invalid
cookie, and in the second case, return them both.
Another question I have is, where should the cookies go, in the
notification data, or in the SPI field? Any thoughts on this?
> >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.
Okay, I'll add clarifying text.
> >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
>
I can change unrecognized to unsupported.
> >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?
>
This is not specified in the ISAKMP RFC, though it seems sensible. I'll
add text to that effect.
> >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?
>
This is not specified in the ISAKMP RFC, though it seems sensible. I'll
add text to that effect.
> >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.)
>
I guess that would be a question for the ISAKMP RFC editor.
> >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.
>
I don't understand the difference between the text and what you say
here. Please clarify.
Thanks for your thorough reading...
Scott
Follow-Ups:
References: