[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Phase 1 Re-keying Implementation Identification
>>>>> "Andrew" == Andrew Krywaniuk <akrywaniuk@TimeStep.com> writes:
Andrew> This is from Tero's draft, [EXT-METH]: "The second use [of
Andrew> vendor ids] is to allow for vendor specific extensions, after
Andrew> both ends have sent and received familiar vendor IDs. [...]
Andrew> If familiar vendor ID payloads have been exchanged (both sent
Andrew> and received) then implementations MAY do anything, including
Andrew> using private extensions, private payloads, new identity
Andrew> types, running nethack over the ISAKMP SA, etc."
Andrew> This is from [ISAKMP]:
Andrew> "The Vendor ID payload is not an announcement from the sender
Andrew> that it will send private payload types. A vendor sending
Andrew> the Vendor ID MUST not make any assumptions about private
Andrew> payloads that it may send unless a Vendor ID is received as
Andrew> well."
Andrew> By my interpretation of the drafts, if both peers send a
Andrew> vendor id which says "I do continuous channels" then it is
Andrew> appropriate for them to modify their behaviour
Andrew> accordingly.
NO!
Vendor ID is for enabling private extensions. It is NOT for enabling
optional features in the standard. I don't think Tero is saying
otherwise, though if the wording is being misinterpreted that way it
should be clarified so it's obvious that it must not be interpreted
that way.
Now, if you're proposing that continuous channels should remain a
private extension that's not standardized, that's different (but then
of course this discussion doesn't belong on this list).
paul
Follow-Ups:
References: