Re: Choosing between IKEv2 and JFK

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


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

  Yes, on a security gateway, the piece of hardware that implements the IPsec
SPD will be doing admission control for QoS. 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. 
  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.

  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.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys

iQCVAwUBPIo9xIqHRg3pndX9AQE4HwP9GRS6ouT1VrPfyXI89ed8kHEENi7kETsG
xtlY2ADZX1KJLPL/EXhx0Kdcd9zGs05ywkDOxIJtjDnldKD44bbXtC57QE2VQgoS
9bJS4K+qvhevA1QgH2bogLTnwQCS9QX4g+FYcwByWNXOwvSzQVFSTKMWBQz0WUkB
fLijdNV2wq8=
=AZSK
-----END PGP SIGNATURE-----