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

Re: IKEv2 (son-of-ike) draft

  Ari,

  The draft clearly states that "If the critical flag is set and the
payload type is unsupported, the message MUST be rejected....If the
critical flag is not set and the payload type is unsupported, that
payload is simply skipped." In addition it states it "MUST be ignored
by the receipient if the recipient understands the payload type code."
Also, it "MUST be set to zero for payload types defined in this
document."

  Since you presumably understand the "cert payload" you MUST ignore
that field when it is in the header of a "cert payload". The sender
should not have set it but by ignoring the field there is not problem
with interoperability.

  It is "for further flexibility for forward compatibility." So if the
"foo payload" is defined somewhere by someone for some reason you can
set the critical bit for the "foo payload" to ensure that if someone
does not understand the "foo payload" they will reject the entire
message which contains the "foo payload". Or you can clear the critical
bit for the "foo payload" to ensure that the recipient will skip this
payload and finish processing the message. Whether you set it or not
with the "foo payload" depends on you and what the purpose of sending
the "foo payload" is.

  I think the draft is quite clear in this regard.

  Dan.

On Tue, 20 Nov 2001 08:28:51 +0200 you wrote
> 
> - IKEv2 must be well defined. For example, this draft doesn't state
>   clearly how the critical bit is to be used (for each payload), notifies 
>   are unclear and should be accompanied by a state machine.
>   I.e. if a cert payload with critical bit contains a DSS-signature,
>   is it critical that you know "cert payload", support DSS-signatures, or wha
>t?
>
Follow-Ups: References: