Raj Singh writes:
> Your suggestion of having "critical" bit set on childless notify/VID payload
> from initiator in IKE_SA_INIT exchange will define the bahavior as mentioned
> below.
That is not correct way of using critical bit. Critical bit means that
if it is set and the PAYLOAD TYPE is not understood, then
UNSUPPORTED_CRITICAL_PAYLOAD error is reported. Every implementation
will understand Notify and Vendor ID payloads, thus they will never
return UNSUPPORTED_CRITICAL_PAYLOAD regardless what the contents of
those payloads are.
> If initiator want to childless IKE_AUTH, it will send CHILDLESS_IKE_AUTH
> notify/VID payload having "critical" flag SET in IKE_SA_INIT request.
And complient implentation will do what to do as RFC4306 says ie:
... MUST be ignored by the recipient if the recipient
understands the payload type code. MUST be set to zero for
payload types defined in this document. Note that the critical
bit applies to the current payload rather than the "next"
payload whose type code appears in the first octet. The
reasoning behind not setting the critical bit for payloads
defined in this document is that all implementations MUST
understand all payload types defined in this document and
therefore must ignore the Critical bit's value. Skipped payloads
are expected to have valid Next Payload and Payload Length
fields.
The correct way to do is to make new exchange type for this new
childless IKE_SA_INIT & IKE_AUTH. That way old implenentations will
then know that they do not understand this new type and will drop the
packets. This is if you really want the property that if responder
does not understand chieldless IKE_AUTH you do not want to continue at
all.
I have not yet read the draft, as I have been too busy with working
group drafts already, and I still do not know if this is really needed
at all...
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
