[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-notifymsg-00.txt


Hi Scott,

I tried mailing this y'day but somehow there was an error. I think you
will find a few repeats of what Valery had talked about. I am not editing
my mail, though I can delete a few points from my mail....

Hi Scott,

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.

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? And, one 
more question on this - isnt it inconsistent to make the SPI size 0 and the 
SPI to be the two ISAKMP cookies?

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?!

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.)

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.

And, the latter choice seems more appropriate if we consider the following 
scenario :

Initiator (I) sends the first message of QM to the responder (R). R finds 
that the transform ID of a transform is invalid. It may not even have 
generated a SPI as yet since it cannot parse I's request itself. Also, even 
if it generates the SPI and sends it out, 'I' does not have any way of 
identifying the QM from this information - the SPI and protocol are both 
required to uniquely identify a QM state in ISAKMP (from the requirement 
that the Dest addr, SPI and protocol form a unique triple). 'I' would have 
stored its SPI and protocol and the rest of info in its QM state and so will 
not find the QM based on the sender's inbound SPI.

In fact, I think that it will be easier to identify the QM by making the first 
four bytes of the notification data the message ID of the QM this message 
corresponds to for all QM notify messages.
Still, I think that the SPI should be the receiver's inbound SPI so that the 
appropriate proposal is identified (unless as in some cases, the entire 
proposal payload is included as the notification data).

regards,
Anupama
Follow-Ups: References: