RE: Move TS to optional (RE: Don't remove TS from IKEv2)

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Sankar" == Sankar Ramamoorthi <Sankar.Ramamoorthi@nexsi.com> writes:

 Sankar> Having an inband way (yes - that may require ipsec tunnel to
 Sankar> be accepting control traffic in addition to data traffic)
 Sankar> allows the possiblity of piggybacking control information
 Sankar> along with data within the ipsec tunnel. To me, that seems to
 Sankar> be most efficient way to indicate to the other side about the
 Sankar> change in ipsec selectors.  The control channel can be put to
 Sankar> other uses as well..

I may be reading too much into this, but this thread frightens me.

Separating the control plane from the data plane is a well established
design approach.  It's universally applied in telecom, where high
reliability is crucial.  It's an essential design principle to
achieve very high performance.

The control channel messages have to be bound to the data channel they
apply to.  That's *all* that's needed for things to work.  Yes, you
can do that binding by embedding the control messages into the data
channel, but only at the expense of making the high performance data
plane implementation more difficult.  It's much better to keep it
separate and make the binding explicit.  (IKE does that.  So do
protocols like ATM, or IP routing.)

A somewhat different argument is the reuse of mechanisms.  IKEv1 has
SAs but they are a bit different from IPsec SAs, so the protection
assurances do not directly carry over.  It's a reasonable idea to use
the same mechanisms rather than just "similar" mechanisms to protect
control plane traffic.  But the control plane SAs should remain
separate from the data SAs.

	paul