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

["Sankar Ramamoorthi" <Sankar.Ramamoorthi@nexsi.com>]

> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Tuesday, March 26, 2002 2: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.

I agree that we should minimize/avoid changes to ipsec protocol since many
people have it implemented in hardware - but does that make it immune
to enhancement/changes?

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

I would recommend that any proposed solution for the SA selector update
take latency considerations into account.

-- sankar --


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