[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question about the ISAKMP Notification Payload
I don't know but this segues nicely into a subject I've been meaning
to raise on this list. I'm working on a new draft which combines RFC2407,
RFC2408, and RFC2409 into a new key exchange protocol for IPsec. I'm
also trying to address the complaints the editors of those documents
received, one of which was that there was no description of what one
should put into a particular Notify payload. While trying to describe
each I realized that I don't understand a few Notify types and was
wondering what others have done.
Who implements the following Notify types, when and why do you send
them, and what do you put in the payload?
* INVALID-KEY-INFORMATION - ???
* CERT-TYPE-UNSUPPORTED - isn't this the same as INVALID-CERT-ENCODING?
* INVALID-HASH-INFORMATION - wouldn't this be an authentication failure?
* ADDRESS-NOTIFICATON - ???
* NOTIFY-SA-LIFETIME - isn't this the same as RESPONDER-LIFETIME?
Any help is appreciated.
Dan.
On Wed, 21 Feb 2001 08:54:35 +0100 fd@cisco.com wrote
> Hi,
>
> Does anyone know why an SPI for ISAKMP (the cookie pair) MUST be ignored when
> it appears in a Notification Payload ?
>
> Well. I understand the cookie pair at the beginning *may* be enough but I do
>not understand why it MUST be ignored if present in the payload. That is, what
> is the risk associated ? (what's the story behind ?)
>
>
> --8<---- RFC 2408 - 3.14 - excerpt ---
> SPI Size (1 octet) - Length in octets of the SPI as defined by
> the Protocol-Id. In the case of ISAKMP, the Initiator and
> Responder cookie pair from the ISAKMP Header is the ISAKMP SPI,
> therefore, the SPI Size is irrelevant and MAY be from zero (0) to
> sixteen (16). If the SPI Size is non-zero, the content of the
> SPI field MUST be ignored. The Domain of Interpretation (DOI)
> will dictate the SPI Size for other protocols.
> --8<----
>
> thank you,
>
> frederic detienne
Follow-Ups:
References: