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

[Paul Koning <pkoning@equallogic.com>]

Excerpt of message (sent 27 March 2002) by Sankar Ramamoorthi:
> >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.

What for?  Is there information about the session that the *data
plane* machinery needs to know about?  I can think of none.
 
> >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.

You misunderstood my suggestion.  What I described requires NO change
in ESP.  I meant only to suggest that son-of-IKE could use the ESP
packet formats and algorithms.  In essence, SOI ends up running over
an ESP transport mode (presumably) connection.  But that requires no
changes to ESP at all; it simply happens to be that some of the
currently active SAs are protecting user data, and some are protecting
SOI control traffic -- to ESP that makes no difference and it requires
no change in any ESP hardware or fastpath software.

Also, credit where it belongs: I was paraphrasing a proposal in the
ikev2 draft.

      paul