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

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

Scott, some comments below.

First of all, most of described error messages are applicable not 
only to phase 1 or 2, but also to New Group mode and Transaction 
mode. The problem is that the latter two either don't have SPI 
(Transaction mode) or it is dummy (New Group). So, you need Message 
ID to include to Notify payload to unambiguously indentify exchange. 
Although you've included it into differentiators of most messages, 
you, in general, don't put them into transferred data. Note, that 
message ID from ISAKMP header is different and cannot be used if 
separate informational exchange is used.

This problem was discussed (and one solution proposed) in Tero 
Kivinen's message to the list <199812031546.RAA06867@torni.ssh.fi> 
from 3 Dec 1998.

Then, I agree with proposals to always interpret notification data as 
ISAKMP attributes list. This will give an extra flexibility in 
including additional information.


> 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.
>
>   Phase:            1 or 2
>
>   Differentiators:  Cookies vs SPI,
>                     subject payload in notify data

I think message ID should also be added here.

> 2.4 INVALID-COOKIE
>
>   The INVALID-COOKIE error message may be used to communicate that an
>   invalid ISAKMP cookie was received.
>
>   Phase:            1 or 2
>   Differentiator:   Cookies, message ID
>                     invalid cookie in notify data
>
>   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 IPSEC DOI (1)

Why so? Do you think INVALID-COOKIE error message is only valid for 
IPsec DOI? I don't think so - it is defined in ISAKMP document.

> 2.9 INVALID-MESSAGE-ID
>
>   The INVALID-MESSAGE-ID error message may be used to communicate that
>   the message ID in the received message is unrecognized or invalid.
>
>   Phase:            1 or 2
>   Differentiator:   Cookies, message ID
>
>   When present, the Notification Payload MUST have the following
>   format:
>
>     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
>     o  Notification Data - empty
>
>   In this case, the invalid message ID is contained in the ISAKMP
>   header of the notify message.

If separate informational exchange is used to transfer notify 
message, its message ID may have no connection to your invalid 
message ID.

> 2.13 ATTRIBUTES-NOT-SUPPORTED
>
>   The ATTRIBUTES-NOT-SUPPORTED error message may be used to communicate
>   that unrecognized or unsupported attributes were received as part of
>   a proposal.  Currently, this message may result from one of the
>   following events:
>
>     o  unacceptable group in IKE new-group-mode negotiation o
>     conflicting lifetime attributes are detected o  invalid or
>     unsupported SA attributes are received

Some formatting problem in the document here.


Regards,
Valery.
Follow-Ups: