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

Re: Question about the ISAKMP Notification Payload

On 21 Feb 01, at 13:02, Dan Harkins wrote:

Dan,

some information can be found in draft-ietf-ipsec-notifymsg-04.txt. 
Unfortunately, the document seems to contain quite a lot of typos, 
errors and unclear places. Yet some rationale for the document's text 
can be found in Tero's message:
http://www.vpnc.org/ietf-ipsec/99.ipsec/msg01263.html.

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

Supposed to indicate invalid Key Exchange Payload length (unequal to 
what must be according to negotiated Oakley Group). I think PAYLOAD-
MALFORMED or UNEQUAL-PAYLOAD-LENGTH can be used instead.

>    * CERT-TYPE-UNSUPPORTED - isn't this the same as INVALID-CERT-ENCODING?

The former is supposed to be used to indicate an error in CertRequest 
Payload, while the latter - in Certificate Payload. Meanings are the 
same.

>    * INVALID-HASH-INFORMATION - wouldn't this be an authentication failure?

No. It has the same meaning as INVALID-KEY-INFORMATION, only applied 
to Hash Payload (its length is unequal to resulted hash length of 
negotiated hash function). And again, I think it can be replaced with 
PAYLOAD-MALFORMED or UNEQUAL-PAYLOAD-LENGTH.

>    * ADDRESS-NOTIFICATON - ???

No idea. Seem to be overlapped with (or completely covered by?)  
INVALID-ID-INFORMATION.

>    * NOTIFY-SA-LIFETIME - isn't this the same as RESPONDER-LIFETIME?

No. According to the draft it is supposed to indicate invalid format 
of Life Time attributes in proposal (for example, no SA Life Duration 
attribute follows SA Life Type attribute), but in this meaning it is 
comletely covered by BAD-PROPOSAL-SYNTAX. So, I don't know what is it 
for.

Regards,
Valery.

> 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
>
References: