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

["Sankar Ramamoorthi" <Sankar.Ramamoorthi@nexsi.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.  


I think I used the word 'control' too liberally in my messages.

I would argue that even in protocols like IP, TCP certain amount
of control information is passed along with the data in
flag field of the header. The control information may be describing
an attribute of a specific data packet (such as DF bit in the IP header)
or may affect the entire session (such as RST bit in the TCP header).
Unfortunately ESP does not have a flag field.

I would also argue that TCP has really no separation of control
and data (acknowledgement of TCP connection establishment is
carried in the first data packet, and data packets can carry information
to teardown the sesson.).


>It's much better to keep it
>separate and make the binding explicit.  (IKE does that.  So do
>protocols like ATM, or IP routing.)
>

Agreed. However it would still have been useful to leave some
room in the ESP header for conveying information about the session.

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

Intresting ideas. If ESP had a flag field, it could be used to
identify a control channel - use the same keying material and SPI 
as the data channel yet maintain the SAs separate.

>	paul
>