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

Re: IKEv2 (son-of-ike) draft

Dan,

You did answer my question, but let's follow.. Is it then implicitly
understood that all payloads defined in the current draft are understood
by all implementations, and therefore have implicitly the critical bit
set, even though it's not? If they are all implicitly critical, why
not make them explicitly critical. I would feel better if the draft
stated clearly when the bit is to be set and when not. 

Would it be allowed to send a non-Critical private payload type preceded
by a VID in the first message? If not, why not? This would solve my
biggest gripe with VIDs.

Ari

dharkins@tibernian.com wrote:
> 
>   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?
> >

-- 
"They that can give up essential liberty to obtain a little 
temporary safety deserve neither liberty nor safety." - Benjamin Franklin

Ari Huttunen                   phone: +358 9 2520 0700
Software Architect             fax  : +358 9 2520 5001

F-Secure Corporation       http://www.F-Secure.com 

F(ully)-Secure products: Securing the Mobile Enterprise
References: