Re: Choosing between IKEv2 and JFK

[Jan Vilhuber <vilhuber@cisco.com>]

On Sat, 9 Mar 2002, Michael Richardson wrote:

> | Pretty Good Privacy(tm) Version 6.5.8
> | (c) 1999 Network Associates Inc.
> | Uses the RSAREF(tm) Toolkit, which is copyright RSA Data Security, Inc.
> | Export of this software may be restricted by the U.S. government.
> |
> | File is signed.  signature not checked.
> | Signature made 2002/03/09 16:52 GMT
> | key does not meet validity threshold.
> |
> | WARNING:  Because this public key is not certified with a trusted
> | signature, it is not known with high confidence that this public key
> | actually belongs to: "(KeyID: 0xE99DD5FD)".
>
>
> >>>>> "Jan" == Jan Vilhuber <vilhuber@cisco.com> writes:
>     Jan> I finally realized what bothers me about this, which I think is also
>     Jan> what angelos was talking about: What you're really saying is that IKE
>     Jan> is now essentially doing admission control for QoS based on a cert
>     Jan> (attribute certs?!). I'm not sure I buy that. It's neither IPsec's nor
>     Jan> IKE's job to perform admission control for QoS.
>
>     Jan> I'm assuming that some other layer already did this (does RSVP do
>     Jan> this? Sorry. I don't know much about QoS), and that IKE merely
>     Jan> negotiates the tunnel for the new QoS traffic. if it wasn't allowed,
>     Jan> the other end will drop the packet, or the local stack (if not hacked)
>     Jan> will drop the packet.
>
>   Yes, I do know a lot about about various QoS systems having spent several
> years designing hardware to do packet classification. Go read the RFCs.
>

Gah! :)


>   Yes, on a security gateway, the piece of hardware that implements the IPsec
> SPD will be doing admission control for QoS.

Just to clarify: I don't care if QoS and IPsec use the same database
and possibly interact, but I DO have a problem with basing decision on
whether to allow someone a higher level of QoS or not on IKE
negotiation.

*IF* some external mechanism determined that this user/flow is allowed
a higher level of QoS, THEN IKE should negotiate this. IKE should not
be the mechanism to answer the question "Is this flow allowed at a
higher level of QoS". That question belongs into a different
protocol.

Not sure if this is clear, but it essentially tells me that you do NOT
need separate certs for different levels of QoS, if the
user/end-station of the flows are the same.


> There are three reasons for this:
> 	  1) the form of the database is identical.
>
> 	  2) the hardware is designed to do both already, and why have
> 	     multiple pieces of hardware?
>
> 	  3) the alternative is that the QoS people whine about how they can
> 	     not do QoS once the packets are encrypted and could we please
> 	     reveal pieces of the packet?
>
>   QoS flows will be based upon SPI# (which conveniently is 16bits + 16bits at
> a slightly different offset and looks a lot like TCP or UDP port numbers to
> hardware).
>   Further, odds are that the customer located QoS-enabled security gateway
> will simply use RSVP to arrange QoS with the ISPs DiffServ enabled "diffedge"
> border router. RSVP already has selectors for SPI# and has had them since
> 1996 or so.
>
>   As stated clearly by others, you can not sort the same IPsec flow into
> multiple classes of service. The replay windows get in the way. Any argument
> that you want to avoid traffic analysis is moot - by putting the packets into
> different flows you are in fact doing the traffic analysis for the bad guys.
>
>   It would be nice if all traffic of a given QoS could go into the same
> tunnel. This is not possible with current IKE because you can not negotiate
> multiple disjoint sets of selectors there.
>
>   The requirement is that one is able to negotiate multiple tunnels with
> different contents. We have that already. You have to negotiate a per-port
> tunnel for each QoS flow.

Can you ever do different levels of Qos for the same 5-tuple? Would
this makse sense?



>   Fragment issues are moot. QoS people already recognize that if you
> fragment, you are unlikely to get QoS.
>   Who does this affect? NFSv2 and CIFS (SMB) networking. NFSv3 and NFSv4
> should be run over TCP anyway. It is hard to name another protocol that
> doesn't run over TCP and yet has a problem with big packets. (VoIP packets
> tend to be rather small. Streaming video may present a problem, but streaming
> video will never work without QoS, so they will adapt, in my opinion)
>
>   Any fragments therefore go through the "per-host" or "per-network"
> "best-effort" tunnel anyway.
>
>     Jan> Of course this assumes some additional capabilities in
>     Jan> Ipsec-selectors, i.e. to be able to include QoS levels in the SA
>     Jan> negotiation, but that may be needed whether we use the same or a
>     Jan> different cert.
>
>   Not that I can see. It requires that the QoS level be negotiated, but this
> is an additional "parameter", rather like an cipher algorithm.
>

That's what I meant. I'm curious if it's needed, though (see previous
question). Can a flow (5 tuple) exist in two different levels of QoS?
Or would the two flows exist on different ports?



>   About the only time I can see different identities being used is in host
> (not BITS or BITW) implementations, in which case, there are no fragment or
> classification problems - you keep the SA# in the PCB.
>
>     >> For example, if I could use my personal cert to specify a normal
>     >> connection or a high-QoS connection and the costs to me were the same,
>     >> why wouldn't I specify the high-QoS connection all the time?
>
>     Jan> Why indeed? Because presumably your ISP or whoever is at the other end
>     Jan> will either disallow it, or charge you more.
>
>     Jan> Is this an IKE issue at all? This is a regular QoS admission control
>     Jan> problem.
>
>   it is a regularl QoS admission problem. It is between the Security Gateway
> and the ISPs border router. There will be certificates eventually involved,
> and they may be the same, but it won't be IKE dealing with them.
>


That's sort of my assertion. Something else did the check whether you
(the guy with the certificate) are allowed QoS for this traffic at
level X. IKE doesn't (and shouldn't IMHO) answer this question, but
should negotiate the tunnel for the different QoS level if instructed
to do so (by ipsec or rsvp or whatever...).

Now what do you think of Angelos' idea of simply putting the max
level of Qos of all your flows onto the ESP tunnel, thereby
effectively elevating all low-priority traffic to high priority
traffic as far as the outer IP header is concerned? Seems that is
counter to what QoS is supposed to do, but I'd like to hear some
QoS-savvy opinions on this.

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