[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lack of negotiation capability (was RE: Phase 1 Re-keying Implementation Identification)
Hi Andrew,
Andrew Krywaniuk wrote:
>
> I think we're hitting a roadblock in the development of IKE. It seems like
> we can't develop new features because there is no feature negotiation
> capability in IKE. How can we expect a feature to gain support if no one can
> implement it and use it because it is not standardized?
>
You are welcome to implement and test new functionality using a
(private) vendor ID payload. If the functions are truly useful, you
shouldn't have much trouble convincing people of this, at which time
they can be added to IKE (sans vendor ID). The problem is, not many
think the "feature" you're proposing is required, or even marginally
useful. You can't expect capricious changes to a deployed security
protocol whenever you have some pet "feature" you want implemented. You
have to first convincingly demonstrate the requirement. You have not
done that.
> Look at how the dangling phase 2 vs. continuous channel implementation got
> resolved. It wasn't that after an enlightened, intellectual chat, everyone
> agreed that dangling phase 2s were better. Basically what happened is that
> both groups released their products, they didn't work well together, and the
> dangling implementations prevailed because they were the lowest common
> denominator.
This is just plain wrong, perhaps even misleading - another term springs
to mind, but I'll hold my tongue. There was a significant discussion
about this, and the majority of participants agreed that this is a
non-issue.
> Anyone who waits for all the drafts to become RFCs before implementing them
> is going to get killed in the marketplace. Currently, whenever we develop a
> new feature that has not been standardized, that feature has to be enabled
> by policy which is set manually on both sides (which is a bitch to manage).
> Hindering interoperability between vendors who show initiative is tantamount
> to discouraging innovation.
Welcome to the bleeding edge. I will point out again that you are
welcome to use a vendor ID to test this function with anyone you wish,
but vendor IDs are, by definition, private, so you have no basis for
attempting to "standardize" on one.
I find your post a bit astonishing. You've completely mischaracterized
the history of this discussion, as well as its current status. I suggest
you go back to the archives to see previous threads on the same topic.
Scott
References: