Praveen Sathyanarayan writes:
> I agree, it is a corner case. Example, out of 5000 tunnels, may be we will
> see 10 to 15 tunnels end up in this scenario. So memory/resource is not a
> concern.
There are two cases: Your implementation is very limited, and support
very few Child SAs and cannot cope when there are two SAs. In that
case your implementation will reply with NO_ADDITIONAL_SAS to
CREATE_CHILD_SA requests coming in, when they do not have space in the
Child SA table. If both ends are limited implementations and both of
them reply with NO_ADDITIONAL_SAS, then following the section 4 of
RFC5996 they need to delete the IKE SA and start over.
----------------------------------------------------------------------
1.3. The CREATE_CHILD_SA Exchange
...
The responder sends a NO_ADDITIONAL_SAS notification to indicate that
a CREATE_CHILD_SA request is unacceptable because the responder is
unwilling to accept any more Child SAs on this IKE SA. This
notification can also be used to reject IKE SA rekey. Some minimal
implementations may only accept a single Child SA setup in the
context of an initial IKE exchange and reject any subsequent attempts
to add more.
...
4. Conformance Requirements
...
A minimal
implementation MAY support the CREATE_CHILD_SA exchange only in so
far as to recognize requests and reject them with a Notify payload of
type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
expires (based on locally configured values of either lifetime or
octets passed), and implementation MAY either try to renew it with a
CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
create a new one. If the responder rejects the CREATE_CHILD_SA
request with a NO_ADDITIONAL_SAS notification, the implementation
MUST be capable of instead deleting the old SA and creating a new
one.
----------------------------------------------------------------------
If your implemenations do support multiple SAs, then you MUST accept
to create two SAs, as there is no way from the responder to know why
the other end is creating the SA. It might be that the other end is
creating it because of this policy reload, but it might also be caused
because the other end got traffic on different QoS level, and needs to
create separate SA for that QoS level. Section 4.1 of RFC4301 says:
----------------------------------------------------------------------
4.1. Definition and Scope
...
Therefore, a sender SHOULD
put traffic of different classes, but with the same selector values,
on different SAs to support Quality of Service (QoS) appropriately.
To permit this, the IPsec implementation MUST permit establishment
and maintenance of multiple SAs between a given sender and receiver,
with the same selectors. Distribution of traffic among these
parallel SAs to support QoS is locally determined by the sender and
is not negotiated by IKE. The receiver MUST process the packets from
the different SAs without prejudice.
...
----------------------------------------------------------------------
and Section 2.8 in RFC5996
----------------------------------------------------------------------
2.8. Rekeying
...
Note that IKEv2 deliberately allows parallel SAs with the same
Traffic Selectors between common endpoints. One of the purposes of
this is to support traffic quality of service (QoS) differences among
the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
[DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
and the Traffic Selectors may not uniquely identify an SA between
those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
the basis of duplicate Traffic Selectors SHOULD NOT be used.
----------------------------------------------------------------------
So the end result with non-minimal implementations is that there will
be two Child SAs with same traffic selectors.
> But question is, how do we handle once we are in that state. For
> example, which phase1/phase2 SA we should continue to hold (Rekey) and
> which one we need drop it, etc.
>
> This is where the confusion comes. Each vendor may end up choosing
> different way to handle it and it may cause confusion with other vendor.
> If there is a clear description on how to handle (which one to choose and
> which one to drop), will help.
Both of the SAs are valid and both ends needs to process packets
coming from either of SA without prejudice. Each implementation will
most likely pick one SA when sending traffic and it will send traffic
out from that SA. Neither end should not drop SAs as it does not know
why the other end created them.
When it comes time to rekey, then it depends on the implementation
what will happen. If both ends happened to select same SA pair for
their traffic, then when it comes to time to rekey the second SA, it
is dropped as there has not been traffic on it at all (there is no
point of rekeying SA which do not have traffic).
If they picked different SAs for their traffic and one of them is
going to rekey his outbound SA, then he will rekey that and the old SA
is deleted. Now the other peer might notice that when his outbound SA
is about to expire, he notices that there is already good Child SA
with same traffic selectors which is going to be valid, so he might
simply just skip the rekeying and instead move the traffic to the
other SA. Then as he didn't do rekey, then when the SA actually
expires, then he will delete it.
If they happened to do rekey exactly same time (both of them happen to
have exactly same lifetimes), then it might be possible that both ends
rekey their own outgoing SA and the situation continues. There is no
possibility for getting more SAs as this is rekey, not creating new
SA, so simultaneous rekeys are already covered by the protocol. Also
both ends only use one SA for sending, so at most there can be two SA
pairs between the peers that has traffic, and all others should not be
rekeyed, as there has not been any traffic.
All of that is just implementation details, not protocol issues. As
there is no concept of "one Child SA per one Traffic Flow (SPD)" in
the IPsec architecture, if you implement such concept you need to
define how it should work. On the other hand IKEv2 do have mandatory
feature that you support multiple Child SAs with same Traffic
Selectors... On the other hand Traffic Flow and Traffic Selectors are
not the same thing. Traffic flow could include other things which
cannot be expressed in Traffic Selectors, like QoS parameters etc.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
