[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-notifymsg-00.txt
Hi Anupama,
Thanks for reviewing the draft. Comments below.
Anupama Potluri wrote:
<trimmed here and there...>
> I have the following questions regarding the draft.
>
> 2.9 INVALID-MESSAGE-ID
>
> In this case, the invalid message ID is contained in the ISAKMP
> header of the notify message.
>
> But, the message ID of an informational exchange is supposed to be a unique
> value (not the same as the message ID which triggered this message). How can
> the invalid message ID be part of the ISAKMP header of the notify message?
> In fact, I would like it if they are the same but the ISAKMP RFC clearly
> states that except for the CONNECTED message, for all other notifies, it
> is a new message ID.
You're right - I'll fix that.
> NO-PROPOSAL-CHOSEN : there is no information to find out which QM exchange
> under an ISAKMP SA, this notify belongs to. Why isnt the protocol ID
> here the protocol ID from the selected SA? How do we handle this?
The message ID provides the quick mode info, but as you previously
pointed out, it can't be the same as the one in isakmp header. One way
to fix this is by putting the message ID in the notification data. If
there are no objections, I'll do this.
> ... And one
> more question on this - isnt it inconsistent to make the SPI size 0 and the
> SPI to be the two ISAKMP cookies?
Yes - this is a cut-and-paste error.
> INVALID-CERT-ENCODING, INVALID-CERTIFICATE, CERT-TYPE-UNSUPPORTED,
> INVALID-CERT-AUTHORITY, INVALID-SIGNATURE, CERTIFICATE-UNAVAILABLE : are not
> valid in quick mode (as far as I know) since signature and RSA encryption
> authentication modes are for phase 1 and not for QM. If it is any other mode
> other than QM in phase 2, it is fine but in that case the SPI will not be
> the 4 byte IPSEC SPI, will it?!
Right. I guess I'm thinking that some of the phase 2 ID payload values
(present and future) may require additional cert functionality, and that
these messages would then be useful. For example, it seems possible
that phase 2 SAs for multiple endpoint pairs (using different DNs for
selectors) might be negotiated through a single phase 1 SA. In this
case, additional cert/auth exchanges would be required. If this seems
far-fetched to folks, I guess we could delete this from the doc, and add
it back later if it ever becomes necessary.
> UNSUPPORTED-EXCHANGE-TYPE : Wont the protocol always be ISAKMP for this and
> the SPI none even if we get an invalid exchange type after the ISAKMP SA is
> mature? Esp. as we dont know that there will be a SA payload in that exchange?
> (The draft says the protocol is the Protocol ID from the chosen SA.)
Yes, this is more cut-and-paste madness, probably the result of the fact
that my eyes were glazing over by the time I got that far into the doc.
I'll change this.
> I have a question regarding the phase 2 notify messages.
> The following has been stated for all phase 2 notify messages.
>
> o SPI - set to empty or to the sender's inbound IPSEC SPI
>
> But, the ISAKMP RFC states the following :
>
> o SPI (variable length) - Security Parameter Index. The receiving
> entity's SPI.
>
> We did have this problem in the bakeoff and it seemed to me that people
> agreed that it has to be the receiving entity's SPI.
Another cut-and-paste from the DOI doc, and as you point out, it's
incorrect in this context. I'll fix it.
Thanks for your very thorough reading of the doc.
Scott
References: