Re: Choosing between IKEv2 and JFK

[Michael Thomas <mat@cisco.com>]

Angelos D. Keromytis writes:
 > 
 > In message <Pine.LNX.4.33.0203071347150.29434-100000@janpc-home.cisco.com>, Jan
 >   Vilhuber writes:
 >  >
 >  >Yes. Think about it: If you have load and high priority traffic on the
 >  >same SA, and there are not only reordering (and prioritization) of
 >  >packets as they leave the box, but also when they enter (and are
 >  >processed by) the receiver AND there is prioritization and reordering
 >  >happening IN THE NETWORK (assuming QoS ever becomes more prevalent),
 >  >then chances are the receiver will see a LOT of the higher priority
 >  >packets before he sees any low priority packets.
 >  >
 >  >hence each high priority packet will advance the replay window, until
 >  >finally some low priority packet comes in which is rejected, since the
 >  >replay window has moved too far forward due to the high priority
 >  >packets.
 >  >
 >  >Hence: Separate SA's and replay counters.
 > 
 > Yes, in that scenario you would need separate SAs.
 > 
 > However, I would assume that, in the case of multiple traffic streams of
 > different priorities going over the same IPsec tunnel (*), the sender:
 > 
 > a) would request for the ESP traffic the same priority level as the highest
 >     priority among the different data streams, and
 > b) would do its own prioritization for packets entering the tunnel
 >    (treating the tunnel as a link on its own)

   Would that it were so simple. QoS is not just
   about strict prioritization. Queuing treatment
   certainly cares about which packet goes out
   first, but I don't think you can map, say, an 
   EF per hop behavior into an AF class. In other
   words, there are multiple dimensions in jitter,
   loss characteristics, etc, which would give
   unsatisfactory results if you tried to do that.
   This is completely aside from the fact it might
   be extremely wasteful to "upgrade" your least
   common denominator traffic -- best effort
   typically -- to your traffic which has tighter
   jitter/loss characteristics. Indeed, the
   percentage of EF traffic which can be safely 
   placed on a link is usually less than 20%. Not
   very good link utilization if that's your
   "highest" priority.

   Also: at some level, there is nothing which
   prevents somebody from creating a SPD entry
   which does this regardless of whether you think
   this is useful. I don't think it's arguable
   that authentication amortization is useful were
   somebody to do such a thing. Since this is just
   one data point in a list of reasons why
   amortization is a Good Thing, it really needs
   to be weighed as part of that package. My
   feeling is that DPD, rekeying, etc are pretty
   compelling reasons in and of themselves.

		      Mike