Subject: RE: QoS and IKEv2

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 12 Mar 2003 19:40:29 -0500 (EST)

I don't think we need the uniquifier field!

To summarize the problem again: This problem was brought up
by Jess Alpert, which is that for various reasons (QOS being only
one of them) F1 and F2 might want to create multiple SAs
between them, and the traffic selectors on them might be the
same, so they would look redundant.

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.

This is a nice simple rule, and perhaps could be made even simpler
by ignoring the case where redundant SAs get created because of
simultaneous creation on the two ends. What's the harm of that case,
really? Just occasionally you'll have more SAs than you intended,
but not by a lot. Worst case is a factor of 2, but that seems unlikely.

So, if we're willing to live with occasionally unintentionally redundant
SAs due to simultaneous SA creation on the two ends,
the rule would be simply that you do not close an SA unless:
  a) you initiated its creation
  b) it is redundant with another SA that you also created (and you don't
      actually need redundant SAs).
  
then we don't need the uniquifier, and we don't need to worry
about random delays and unintentionally closing both ends at once.

Radia

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 13 Mar 2003 10:52:03 +0200

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: [email-masked]
[mailto:[email-masked]]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."

<snip>

---

From: "Yoav Nir" <[email-masked]>
Date: Mon, 17 Mar 2003 10:41:59 +0200

Thinking it over, there needs to be an exception to this.

Suppose a faulty or malicious peer keeps creating more and more identical
Child-SAs, threatening to fill up your data structures.  I think we should
be allowed to close such redundant Child-SAs.  Of course, this is in
response to an attack, which must be allowed, rather than simply closing
apparently redundant SAs, which should probably not be allowed.

Are there any objections to this change?

Yoav

-----Original Message-----
Subject: RE: QoS and IKEv2

Into this: