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

RE: QoS and IKEv2



How about rephrasing this:

   This form of rekeying may temporarily result in multiple similar SAs
   between the same pairs of nodes. When there are two SAs eligible to
   receive packets, a node MUST accept incoming packets through either
   SA. An endpoint SHOULD wait a random amount of time before closing a
   redundant SA to prevent cycling.

Into this:

   This form of rekeying may temporarily result in multiple similar SAs
   between the same pairs of nodes. When there are two SAs eligible to
   receive packets, a node MUST accept incoming packets through either
   SA. A node MAY only close a redundant SA if it was the initiator in
   the negotiation that led to the creation of the SA.  An endpoint
   SHOULD wait a random amount of time before closing a redundant SA to
   prevent cycling.

The only problem I see with this is that this requires that this introduces
a concept of an "owner" of an SA.  A node would have to keep track of which
SAs belong to it (are "local") and which SAs do not (are "remote").  I think
I can live with it, although I like the uniquifier idea better.  I don't
think we need a lot of uniquifier.  One byte of the three reserved bytes in
the TS payload would be enough.

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Radia Perlman -
<snip>
The current IKEv2 spec isn't too explicit about redundant SA's,
which (before Jesse brought up the issue) we'd assumed were
unintentional, due to creating SAs simultaneously in
each direction, upon startup or upon rekeying. What the
current spec says about redundant SAs is:
"An endpoint SHOULD wait a random amount of time before closing a
   redundant SA to prevent cycling."

It doesn't say you have to close redundant SAs, or even that you should.

Here's a proposal (but in the next paragraph I'll propose an
even simpler solution):
only the initiator of an SA is allowed to close an SA due to its
looking redundant. (you're allowed to close it for some other reason,
but not because it looks redundant). You still need to wait the
random delay if you're closing an SA that you think is redundant
with one created by the other end,
so that the two ends don't create and delete a single
SA simultaneously. But it allows one end to create as many SAs as
it wants, and it doesn't require a uniquifier field. It's none
of Bob's business why Alice wants to create n SAs all with the same
traffic selectors. Bob has to accept traffic on any of them.
<snip>