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

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