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

RE: Phase 1 Re-keying Implementation Identification

This is from Tero's draft, [EXT-METH]:

	"The second use [of vendor ids] is to allow for vendor specific
extensions, after both
	ends have sent and received familiar vendor IDs. [...]
	If familiar vendor ID payloads have been exchanged (both sent and
	received) then implementations MAY do anything, including using
private
	extensions, private payloads, new identity types, running nethack
over
	the ISAKMP SA, etc."

This is from [ISAKMP]:

   "The Vendor ID payload is not an announcement from the sender that it
   will send private payload types.  A vendor sending the Vendor ID MUST
   not make any assumptions about private payloads that it may send
   unless a Vendor ID is received as well."


By my interpretation of the drafts, if both peers send a vendor id which
says "I do continuous channels" then it is appropriate for them to modify
their behaviour accordingly. However, if a host sends the vendor id and the
peer does not return it then he should not make any assumptions about the
peer's implementation. Therefore, he should not delete the phase 2s if the
phase 1 is not rekeyed.

As you can see, this means that (contrary to popular belief) continuous
channel support is ***UNOBTRUSIVE***. If you don't want to support it then
don't send the vendor id and the continuous channel feature will be
automatically disabled. 

Our belief is that the benefits of continuous channels outweigh the
disadvantages. Even if other vendors will be using dangling phase 2s, we
want to use it when negotiating with our own products. Tim was merely
proposing that the vendor id be made public so that other vendors who use
this mode can use it when interoperating with us.

As for the more general question of whether it is appropriate to use vendor
ids to advertise a feature, this appears to be the only method available in
IKE at the moment. All I can say is that the drafts do not disallow this,
and they specifically allow an implementation to send as many version ids as
it wants. If you have a better solution then let's talk.

Andrew
_______________________________________________
 Beauty without truth is insubstantial.
 Truth without beauty is unbearable.


> -----Original Message-----
> From: Paul Koning [mailto:pkoning@xedia.com]
> Sent: Thursday, November 18, 1999 3: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
>
Follow-Ups: