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

Re: Don't remove TS from IKEv2



On Wed, 20 Mar 2002, Bill Sommerfeld wrote:
> The purpose of traffic selectors is *not* to modify the SPD, but
> rather to allow policy compatibility (or lack thereof) to be
> discovered sooner rather than later.

I agree with Bill's basic point -- he and I are on the same side of this
particular debate -- but for slightly different reasons. 

The IPsec "SPD" is rather poorly named.  It's a distinctly low-level
concept, precisely dictating details of packet handling.  In some
implementations (such as FreeS/WAN), the SPD is dynamic, not static, with
SPD entries set up and torn down as tunnels come and go, based on IKE
negotiations constrained by policy specifications at a much higher level
of abstraction. 

(As a non-traffic-selector example, the SPD says whether encrypted ESP
packets should be authenticated using ESP authentication, or using a
separate AH SA.  Our high-level policy says that we prefer ESP
authentication but will accept AH+ESP as an alternative.  The SPD entry
can't even be set up until IKE has negotiated which form the connection
will use.  This is important; one reason why we interoperate with almost
all other IPsec implementations is precisely that we are willing to
postpone such decisions until we see what the other end wants/needs.)

So yes, traffic selectors really *can* modify the SPD.  And it's useful. 
For Opportunistic Encryption (draft-richardson-ipsec-opportunistic-03.txt)
in particular, we are willing to negotiate with a security gateway on
behalf of someone behind him with no prearrangement whatsoever; this
cannot be made to work unless the gateway tells us who he is representing.
(In fact, it's annoying that we get this information so late in an IKE 
negotiation.)  Something like traffic selectors is absolutely vital here,
because we have no a priori information at all.

                                                          Henry Spencer
                                                       henry@spsystems.net