Yoav Nir writes:
> I agree with Tero.
>
> How about replacing this:
> The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
> payload, optionally a Diffie-Hellman value in the KEi payload, and
> the proposed traffic selectors for the proposed Child SA in the TSi
> and TSr payloads.
>
> With this:
> The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
> payload, optionally a Diffie-Hellman value in the KEi payload, and
> the proposed traffic selectors for the proposed Child SA in the TSi
> and TSr payloads. The TSi and TSr payloads SHOULD include the
> very specifig traffic selectors including the addresses in the packet
> triggering the request, as described in section 2.9.
That is one change that is needed, but in addition I think we need to
say that the TSi and TSr should be the original traffic selectors from
the policy, not the already narrowed down ones that the current child
SA is using.
I.e. if initiator originally offered TSi as 10.0.0.0-10.0.255.255 and
included specific packet of 10.0.0.5 TCP port 25 by sending following
TSi entries:
TSi = (TCP, 25 - 25, 10.0.0.5 - 10.0.0.5)
(0, 0 - 65535, 10.0.0.0 - 10.0.255.255)
and then the responder narrowed it down to per host basic, i.e.
returned TSi as:
TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)
now when the initiator starts to rekey that SA after receiving TCP
packet going to that SA (otherwise he would not be rekeying this SA),
and lets say the packet is 10.0.0.5 TCP port 80, so he should send TSi
when rekeying as follows:
TSi = (TCP, 80 - 80, 10.0.0.5 - 10.0.0.5)
(0, 0 - 65535, 10.0.0.0 - 10.0.255.255)
Note, that the second entry is still the whole 10.0.0.0 - 10.0.255.255
range as specified by the policy, not the already narrowed down range
of 10.0.0.5 - 10.0.0.5 which the current child SA is using.
If the responders policy is still same it will still return same TSi:
TSi = (0, 0 - 65535, 10.0.0.5 - 10.0.0.5)
If the responders policy has been changed so that port host SAs are no
longer required it can instead rekey the old SA to have TSi which
would cover the new range, i.e. widen up the traffic selectors from
what they used to be.
If this is not done, then this kind of widening is not possible,
meaning that even if the policy is fixed the original more narrow
policy is still used.
I have seen implementations where the traffic selectors are sent out
(and narrowed to) based on the traffic selectors used in the child SA
now, not what is specified in the policy. The traffic selectors used
in the child SA can always be only more narrow than what is in the
policy (if child SA would have more wider traffic selectors than what
is allowed by policy it would be violating the policy, and it would be
deleted).
I would like to have text saying that the original traffic selectors
from the policy SHOULD be used.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
