Re: Choosing between IKEv2 and JFK

[Jan Vilhuber <vilhuber@cisco.com>]

On Sun, 10 Mar 2002, Jan Vilhuber wrote:

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


Oh.. I think I get it (sort of): You're saying that *IF* you decided
that you *want* to (not SHOULD!) send all flows with different QoS
through the same tunnel (by some definition of tunnel ;), then you
COULD do it the way you describe. That is a true statement.

The caveats are, of course, that chances are this won't be terribly
useful, because

a) like I mentioned, you're hiding all the internal Tos-bits from the
network you're traversing, so your performance will be suboptimal
(since you're lifting all low-priority traffic up to high-priority for
the 'duration' of the tunnel). The whole reason to do QoS is so that
high priority traffic gets preferential treatment. I thought there was
an implicit assumption of "preferential treatment as far as possible",
i.e. in as much of the network as possible. You'd loose a large chunk
of the performance gain that QoS potentially offers you, if you
elevate low priority traffic to high-priority traffic for the span of
the tunnel.

b) the way to prevent everyone from simply using the highest level of
QoS (with or without IPsec) is to charge for it. If you pay per level
of QoS, (up)lifting all your low-priority bulk traffic  to high
priority traffic will cost you more, and I bet customers won't find
that terribly palatable. Your crypto endpoints MAY be the same place
doing admission control, but they may also NOT be (like my IPsec box
here at home; if all my esp traffic went at the max-qos over all
flows, assuming my ISP did Qos and charged for it (which it doesn't),
I'd pay up the wazoo).

In theory, you could use the mechanism you describe. And maybe some
will, but I bet it won't be wide spread. I also wouldn't want this WG
to recommend this approach. I would argue that we don't have to worry
about this case, as it doesn't have any implications to IKE (or son of
IKE) at all. This is purely a matter of IPsec, not the key exchange.

I claim we need to realize that the case where you need multiple SA's,
one for each level of QoS (per flow) is going to be MUCH more
prevalent (and a single ID or cert is used, since the endpoints are
still the same two endpoints), and therefore we need to worry about
it, which to ME says: 2 phases (YCMV(*)).

BTW: 2401 states "If Inner Hdr is IPv4 (Protocol = 4), copy the
TOS.". So while technically you COULD make the outside TOS bits
anything you want, this seems like it would go against 2401. Maybe
other areas of this 2401 (or other rfc's?) relax the implied rule
here?

jan

(*) Your Conclusions May Vary ;)



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

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