Re: Choosing between IKEv2 and JFK

["Angelos D. Keromytis" <angelos@cs.columbia.edu>]

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)

The network and the receiver can do prioritization only if:
1) they can decrypt the ESP packets (in which case, there's not issue with
    the replay window), or
2) the packets are marked appropriately by the sender

So the sender has control over QoS in this case. Then again, I'm not a QoS
person.

(*) I use the term tunnel in a general sense, I don't want to start another
     holy war about its use and exact semantics, or transport vs. tunnel mode.

 >> --- huge, monolithic protocols are not pleasant to specify,
 >> analyze, implement, or debug. On a slightly more philosophical vein, they
 >> promote both bloat
 >
 >What kind of bloat are we talking about?

Piling up of not-very-necessary features.

 >> (see IKEv1) and bad APIs (another source of trouble and
 >> embarassments).
 >
 >Underspecification in a protocol definition leads to bad API's, not a
 >comprehensive protocol...

To begin with, a complex protocol is more likely to be underspecified. And,
complicated protocols lead to complicated APIs (because people feel the need to
exploit all the features offered by the protocol).

 >IOS does, I believe. Not an unprotected notify, of course.

That hasn't been my experience, with any vendor I've interoperated with (mind
you, *my* implementations are not doing any better).

 >That's because so far there's been much confusion surrounding these
 >exchanges. If they were clearly spelled out in their use and semantics
 >(note: well defined protocol specification), this wouldn't be nearly
 >as confusing. We're finding that it's becoming very important to have
 >these informational exchanges and are starting to use them more and
 >more.

As far as I can tell, everyone is simply ignoring them (except for a couple of
easy-to-understand cases); and, the more complicated the protocol, the harder
it is to figure out what the right response is to an error message. Again,
not all notifications are bad, just that they are not as useful as people
think (and that's IMOE).

Cheers,
-Angelos