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

[Jan Vilhuber <vilhuber@cisco.com>]

On Tue, 26 Mar 2002 andrew.krywaniuk@alcatel.com wrote:

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

And if we need to devise a completely new protocol for this mythical
management channel, then why not simply use the one that already
exists (like you say below): IKE (or ISAKMP messages).

jan


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

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