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

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



On Fri, 29 Mar 2002 16:19:02 PST you wrote
> On the specific idea of making TS optional, isn't it effectively
> optional already?  Can't an implementation that has no use for them
> always propose wildcard selectors, and always accept (and ignore) any
> selectors proposed to it?

The information that is proposed comes from the SPD. You can define policy
that says, 0.0.0.0 <--> 0.0.0.0 but to whom would you send every single
packet and why would you expect to only receive packets from that person?

An implementation that has no need for selectors is not an IPsec
implementation. 

> Dan Harkins <dharkins@tibernian.com> wrote:
> >   If the selectors that defined your particular SPD entry allowed this
> > received packet already then no "broadening" would be necessary.
> 
> That depends on what you mean by SPD.  Do you mean the traffic selectors
> affiliated with each SA, as communicated by IKE/SOI/whatever?  Or do you
> mean the configured policy that I must enforce? They are quite
> different things.  

They are an expression of your policy that deals with what packets need
IPsec protection. Your "policy" may also say other things that have nothing
to do with protecting packets with IPsec but that is not what the TS
payloads are dealing with.

The information conveyed in the TS payloads comes out of the SPD. The way
it happens is that an SPD extry exists with an action of "protect" and a
packet gets a hit on that entry when it is checked against the SPD during
IPsec processing. If an SA already exists to satisfy this then the packet
is protected by the SA and sent out. If an SA doesn't exist then the SPD
entry that caused the hit is given to IKE.

> Traffic selectors as currently proposed are simple
> sets of addresses, protocols, port numbers and the like.  My policy is,
> in essence, a function that takes a packet as input and produces a
> boolean output.  

No, it's a tertiary output. drop, bypass, or protect. But if it's the term
"policy" that is causing this confusion then don't think of it as "policy".
It's the set of traffic selectors that specify "protect".

> I can't take some selectors and see if they match my
> policy, and if I somehow encode my policy function (say, as a Java class
> file or a bit vector with a value for every conceivable IP packet) and
> send it to you when we're negotiating a tunnel, it will be just as
> useless to you as your traffic selectors are to me.

You can "encode your policy" in any manner you choose but you must support
the ability to classify packets in a well-defined manner (according to
RFC2401). It is packet classification in this well-defined manner that is
conveyed in the TS payload.

My selectors are not useless to you because they allow you to unambiguously
determine which SA should be used to send packets to me. If you have a
wildcard selector entry for port and protocol to me and I have separate
entries for protocol=TCP and protocol=UDP to you and I initiate initiate
an IKE connection to you I will tell you how I want to constrain the SAs
we create, say protocol=TCP. Then later if I initiate to you because a UDP
packet got a hit in my SPD check we will create another pair of SAs for
UDP traffic. Now if we did not send TS payloads you would have 2 SAs to
me that could both be used to satisfy your policy. You get a TCP packet.
Which SA do you use?

> I could, with a lot of otherwise unnecessary work, generate a set of
> selectors that loosely approximates my policy, and use them to negotiate
> a tunnel with you.  

It's unnecessary to generate a set of selectors? How do you use IPsec then?

> > A new
> > packet that required "broadening a tunnel's traffic selectors" would BY
> > DEFINITION be dropped on the other side so there is no point in sending
> > it under protection of that SA in the first place.
> 
> That is only true if each end somehow knows exactly how the other end's
> policy actually differs from the negotiated traffic selectors.  I can
> see how this could work if both ends are the same implementation, or if
> both are trivial implementations that don't have any policy other than
> addresses and port numbers.  But I don't see how it can work in real
> life.

Each end does not have to know how the other end's policy differs from
the negotiated set, they just have to know the largest intersection.
And they then know, unambiguously, what packets to send to the other end
under the protection of which SA.

It actually does work in real life.

  Dan.