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