[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Scott,

Thanks for the clarification. Yes, I was implying changing
the selector only -  not the crypto policy.

-- sankar --


> -----Original Message-----
> From: Scott G. Kelly [mailto:skelly@sonicwall.com]
> Sent: Tuesday, March 26, 2002 1:41 PM
> To: Markku Savela
> Cc: Sankar Ramamoorthi; ipsec@lists.tislabs.com
> Subject: Re: Move TS to optional (RE: Don't remove TS from IKEv2)
> 
> 
> Hi Marrku,
> 
> Comments below...
> 
> Markku Savela wrote:
> > 
> > > From: "sankar ramamoorthi" <sankar@nexsi.com>
> > 
> > > Another alternative worth considering is to do policy change
> > > inband to ipsec traffic.
> > 
> > NO! NO! You cannot change policy from IKE.
> > 
> > There is some serious misunderstanding about what policy is.
> > 
> > In my view policy can never be changed as a result of IKE
> > negotiation. That would be a huge security hole.
> > 
> > Surely you are not suggesting something like if, I have
> > 
> >   selector -> require ESP with 3DES
> > 
> > IKE negotiation could change this  into
> > 
> >   selector -> allow data in clear
> > 
> <lots trimmed...>
> 
> I don't think anyone is suggesting that policy be changed by IKE. The
> problem being addressed is that for some protocols (e.g. FTP), you
> cannot know all of the associated selectors a priori, as some 
> selectors
> are chosen dynamically during the protocol transaction. This 
> means that
> to permit these within IPsec, you have to open up a whole range of
> selectors. For example, to permit FTP, you have to open up 
> TCP from any
> port to any port. The way many of us have gotten around this 
> is to open
> up the tunnel, but use stateful inspection (outside of IPsec) to
> regulate what actually goes through. However, this is not standard, so
> we have no guarantee of interoperability in multivendor environments.
> 
> When people have referred to changing or updating policy within this
> thread, what (I think) they refer to is the ability to dynamically
> update the selectors associated with a given SA based upon current
> protocol state (which might better be referred to as changing the SAD
> rather than the SPD). For example, it would be nice to have a 
> rule which
> permits FTP explicitly, without opening all TCP ports. Such a 
> rule would
> have to allow for dynamically updating the SA selectors based on the
> content of the PORT command within FTP, i.e. it would have to rely on
> stateful protocol monitoring. Currently, no such support is
> standardized. 
> 
> The question is, should we be trying to solve this here, and 
> if so, how
> can it be done? Obviously, any solution has implications for the SPD
> first (as we need a way to represent such dynamic selectors 
> there), and
> in IKE second, as there would be some associated TS payload(s).
> 
> Scott
>