Re: Choosing between IKEv2 and JFK

[Jan Vilhuber <vilhuber@cisco.com>]

On Fri, 8 Mar 2002, Angelos D. Keromytis wrote:

>
> 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.

I'd prefer to hear from QoS people on this. I suspect this is NOT
kosher. It would go against the whole point of QoS, i.e. getting high
priority traffic across your network faster then low priority
traffic. If you cheat and make ALL your traffic into high priority
traffic, you might as well not do QoS at all.


> 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.
>

Modelling and the real world are very different. You're hiding the QoS
from the network here, and that's not valid, IMHO.


> >> 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

It is, if you say you need different certs for different levels of
Qos..


> -- 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.

There's also no reason to throw it out, just because IKEv1 got it
wrong.

jan


> Cheers,
> -Angelos
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847