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