Re: Choosing between IKEv2 and JFK

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

In message <Pine.LNX.4.21.0203081742510.504-100000@localhost>, Jan Vilhuber wri
tes:
 >> 
 >> a) would request for the ESP traffic the same priority level as the highest
 >>     priority among the different data streams, and
 >
 >But that would kill QoS.
 >
 >Also, I thought the IPsec specs say to copy the inner Tos bits to the
 >outer header. Now you are saying we copy the inner tos bits and map
 >them to the highest of all streams in our ESP tunnel.

Yes -- but you also need to do (b).

 >Not sure I get this. I think you'd do this anyway, but the problem is
 >that high priority packets will traverse the network at large faster
 >than low priority traffic.
 >
 >I don't think it's valid to just put all your ESP packets into the
 >highest QoS level....

Sure it is. What (a) and (b) together do is make sure that your high
priority traffic gets there as you'd like it to, and then you do admission
control at the sender using the same algorithm as the network would use.
You basically treat the ESP tunnel as a single-hop link, and pretend that
the sender is the network. The same trick is sometimes used in modeling
QoS, as I understand it.

 >> Piling up of not-very-necessary features.
 >
 >Like doing QoS' admission control for it?

It wouldn't be IKE (or IKEv2, or JFK) doing that -- probably not even
of the IPsec stack itself; in OpenBSD, I'd probably do it via altq.

I was refering to things like dealing with NATs, legacy authentication,
and dead peer detection. Not that these are useless: but the issues can
be addressed just as well by other protocols, without complicating a
protocol that is already large and complicated (rough linecount of
OpenBSD's isakmpd is 36K lines, excluding crypto libraries), and which
is supposed to be at the core of our security architecture.

 >As Andrew said, that's mostly because they were not well understood
 >and ambiguous to deploy. We've learned a lot and can actually now
 >specify better messages and semantics to go with them.
 >
 >Just because the situation is currently bad means it's a bad mechanism.

I remain doubtful for anything other than the potential debugging uses of such
messages. Error handling has been problematic in most protocols (and applications, for that matter) --- there's no reason for unqualified optimism in this
case.
Cheers,
-Angelos