[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 Tue, 26 Mar 2002 16:53:08 PST you wrote
> 
> This is why I advocate that the protocol for broadening a tunnel's
> traffic selectors consist of simply sending the packet that you want to
> send.  This already has to be checked by the recipient for conformance
> to its policy, so let it be an implicit request to "broaden" the tunnel.
> No latency.

  If the selectors that defined your particular SPD entry allowed this
received packet already then no "broadening" would be necessary. The TS
mechanism will ensure that the largest intersection of selectors between
the two parties will already be assigned to the established SA. 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.
 
  The problem is that certain protocols float ports and it is not possible
to know what ports will be used by that particular protocol when defining
the ordered list of selectors in your SPD. Your proposal solves problem that
does not exist and does not solve the problem that does.

  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.
Having two boxes be correctly configured (according to their own UI) and
still not interoperate is not something we should we working towards.

  Dan.