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

RE: Phase 1 Re-keying Implementation Identification

I don't think we want to start having to configure multiple behaviors (or
have knowledge of them) based upon a particular vendors implementation. The
whole point of a protocol to facilitate common communication framework.
Vendor ID usage for enabling standard based features are fine, but basing
behavior (slight variants of the standard) on a vendors interpretation of
the standard gives me the willies.

Scott

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning
> Sent: Thursday, November 18, 1999 12:18 PM
> To: akrywaniuk@TimeStep.com
> Cc: ipsec@lists.tislabs.com
> Subject: RE: Phase 1 Re-keying Implementation Identification
>
>
> >>>>> "Andrew" == Andrew Krywaniuk <akrywaniuk@TimeStep.com> writes:
>
>  Andrew> Hi Dan. I think Tim already answered most of your questions,
>  Andrew> but I have one additional comment:
>
>  >> The issue is whether those of us who do not want to implement
>  >> "continuous channel mode" will have to take certain precautions
>  >> for those of you who do.  If a side effect of doing "continuous
>  >> channel mode" is that you will continue to re-key an SA which
>  >> should be deleted, and unnecessarily use up resources on my box,
>  >> then I'm going to have to take that into account and take some
>  >> different behavior when I notice the vendor ID payload (or
>  >> whatever mechanism you decide to use) indicating a "continuous
>  >> channel mode" implementation.
>
>  Andrew> The reason for the vendor id is so you don't have to change
>  Andrew> your behaviour.  If a continuous channel implementation
>  Andrew> detects a peer that is also continuous channel then it may
>  Andrew> make certain assumptions:
>
>  Andrew> 1) It is ok to always rekey phase 1s before they go down.  2)
>  Andrew> If the phase 1 goes down without being rekeyed it is because
>  Andrew> the peer is unreachable (so the phase 2s can be deleted).
>
>  Andrew> If we recognize that the peer is a dangling phase 2
>  Andrew> implementation then we alter our behaviour in order to
>  Andrew> cooperate.
>
> That's a nice idea but you CANNOT do this with Vendor ID.
>
> If in running a protocol you need to know whether feature X is
> implemented at the other end, the ONLY correct way to do this is to
> encode that fact directly in the protocol.  If X is mandatory in
> version Y, the version number is one way to do that.  Alternatively, a
> flag that says "I implement X" works.  But it is never correct to
> infer from the identity of the vendor that X is, or isn't,
> implemented.
>
> 	paul
>
>
>
References: