[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Phase 1 Re-keying Implementation Identification
Date: Tue, 23 Nov 1999 11:49:02 -0500
From: Paul Koning <pkoning@xedia.com>
It seems to me you're suggesting I'm objecting to the use of vendor ID
as a feature indicator for reasons of purism. That's not correct.
The bigger issue is that it's not going to work.
Optional features are a set, and you can't use a boolean or
enumeration to describe them. You need an encoding that can represent
the subset each side implements (or wants to use). A bitmap will do
that, but a vendor ID cannot.
My understanding (please correct me if I am wrong!) is that existing
implementations which are doing this hack are sending multiple vendor
ID's, one for each feature that they advertise that they support. The
negotiated set of features is determined by having each side taking the
intersection of the advertised features via the vendor ID.
Hence, I believe it *does* work, although it is limited kind of
negotiation, and as one person has pointed out, the vendor ID's aren't
secured, so it is not a secure negotiation, thus further limiting its
usefulness.
If we believe that we need a stronger, better negotiation mechanism,
then certainly we should design one instead of relying on the vendor ID
field, which the spec explicitly disclaims as a possible way of
negotiating protocol extensions.
- Ted
Follow-Ups:
References: