[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> 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



Follow-Ups: References: