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

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 26 Mar 2002, Sankar Ramamoorthi wrote:
> > > Another alternative worth considering is to do policy change
> > > inband to ipsec traffic. After all, if a secure a channel has
> > > already been established with the peer, why not use the same channel
> > > for updating the selector information?
> > >
> >
> > That would require changes to IPsec that I would really not even want
> > to propose. The IPsec tunnel is for data traffic. Are you proposing
> > yet another protocol which runs inside an IPsec tunnel? Why bother?
> > You'd have the same latency. Maybe I'm misunderstanding.
>
> Having an inband way (yes - that may require ipsec tunnel to
> be accepting control traffic in addition to data traffic) allows the
> possiblity of piggybacking control information along with data
> within the ipsec tunnel. To me, that seems to be most efficient
> way to indicate to the other side about the change in ipsec selectors.
> The control channel can be put to other uses as well..
>

I must really be missing something, but that really sounds like an
inappropriate use of IPsec. This would essentially require changes to
everyone's IPsec stacks (especially the 'piggybacking' part), some of
which may reside in hardware.

Let's try to keep the protocols separate. If you think that IKE isn't
the best place to do this, I would argue that ipsec is an even worse
place to do this.

jan
 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847