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

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

My previous mail bounced. I am not if the mail
made it to the list. Pardon me if you receive the mail twice.

Resending the mail.


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

As you point out having a specialized ipsec control channel is
equivalent to another isakmp message or some other protocol.


The advantages of sending control messages in-band to an ipsec SA are
 
1) Control messages are authenticated and replay protected in the
   same manner as data packet - hence have the security property.

2) If necessary, control messages can piggyack data, thereby avoiding
   latency issues.

   For example if the ipsec selector needs to be broadend,
   the sender encapsulates the esp data packet in a control packet indicating 
   the required selector change. The peer on receiving it will ack/nack
   the selector-change using another control packet(may or may not piggyback
   data along with it). The sender continues to send the data in encapsulated 
   form till it receives the acknowledgement from the peer.

3) Control messages are inband and specific to the SA of interest.
   Since the control message follows the same path as data path,
   it could serve as a better way to check the health of the ipsec SA.

-- sankar --



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