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

[andrew.krywaniuk@alcatel.com]

I don't necessarily have any objections to doing this through an IPsec
tunnel, but it should at least be a specialized control channel tunnel
rather than having it mixed in with IPsec-tunneled data. I would suggest
that the transport mode connection between two gateways be considered a
control channel, but it seems that the L2TP people have already subsumed
this SA for their purposes. So it should probably be a port-specific SA on
which the IPSP protocol would run. This solution, in turn, necessitates a
2-phase approach in order to negotiate the IPsec control channel. An
alternative is to create an ISAKMP message for this, which is what most
people would have done before the great complexity crisis of '99.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Tuesday, March 26, 2002 5:38 PM
> To: Sankar Ramamoorthi
> Cc: Andrew Krywaniuk; Dan Harkins; IP Security List
> Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2)
>
>
> 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
>