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


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

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.  If your end does reduce the set at all, I have no
way of knowing whether that subset will actually allow the services I
want to use over that tunnel.  In general, the "approximation selectors"
will include some things that aren't really included by the policy, or
exclude some things that are, or some of both.  So there will always be
a discrepancy between the actual policy and the traffic selectors.  This
could probably be lived with if the discrepancy was small, like a few
corner cases.  But for some commonly used services, the discrepancy is
so large that the selectors have no value (because they are wildcards)
or prevent interoperability (because they are too constraining).


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


>   If we choose to just do away with the TS payloads (as you suggest) then
> we have no standard way of agreeing on anything. What would happen is that
> two boxes would be correctly configured to protect FOO (some protocol) but
> because the definition of how to implement protection of FOO is left to the
> imagination of those implementing IPsec the two boxes might not interoperate.

We can still agree about any particular packet, which is the only thing
we have agree on.  I don't see why they wouldn't interoperate, unless
their respective definitions of the service are actually incompatible,
which is equally possible regardless of how IKE works or even whether
IPsec is in use at all.


					-=] Mike [=-