Re: Choosing between IKEv2 and JFK

[Jan Vilhuber <vilhuber@cisco.com>]

On Mon, 11 Mar 2002, Michael Thomas wrote:

> Michael Richardson writes:
>  >     Jan> That's sort of my assertion. Something else did the check whether
>  >     Jan> you (the guy with the certificate) are allowed QoS for this traffic
>  >     Jan> at level X. IKE doesn't (and shouldn't IMHO) answer this question,
>  >     Jan> but should negotiate the tunnel for the different QoS level if
>  >     Jan> instructed to do so (by ipsec or rsvp or whatever...).
>  >
>  >   if you think about encryption as a "quality" of "service", then the SPD is
>  > going to say something like:
>  >    for traffic from v.x.y.z/mask to a.b.c.d/mask on tcp port 25
>  >    do  ESP-AES-SHA2 with "Telnet"-EF-QoS policy.
>  >
>  >   IKE will have to inform the other end that it is doing this so that the
>  > reverse flow can have appropriate QoS applied. (Since the QOS will be based
>  > upon proto,dst,SPI# not TCP ports).
>
> Ugh. I think that layering got sent through the
> blender here. Let's step back a bit. For a
> security gateway, IKE is nothing more than a
> virtual wire establishment protocol. Under normal
> circumstances, it would just copy

Correction: *IPsec* does the copying, not IKE. As you say, IKE merely
negotiated the parameters of the tunnel for IPsec.

> the inner DSCP
> to the outer, and inherit the PHB treatment on its
> way to the adjacent security gateway. Like any
> other interface to a wire you'll have policing and
> potentially admission control. Diffserv/Intserv
> gives the former, RSVP typically gives the latter.
> In the non-admission control case, there is no
> reason for IKE to do anything special. There is
> need for policing, but that is down in the kernel,
> not with IKE.
>
> For admission control, IKE still has no part, per
> se -- other than its job as a virtual wire
> creator.

If I understood mcr correctly, he's saying the same thing as you,
i.e. if you're going to have separate SA's for each QoS-flow, then you
must have IKE negotiate it. IKE currently can not negotiate a tunnel
with QoS parameters.


> If there's admission control at the
> virtual wire entry, it works just like any other
> wire's admission control module. That is, RSVP
> should work on the virtual wire just like a real
> one.
>
> One twist, however, is that when you signal for a
> reservation which traverses a security gateway,
> there may be need to create a virtual wire with
> the proper characteristics. In the degenerate
> case, you build a single wire to the adjacent SG,
> but there may be need to create virtual wires with
> different characteristics (eg, low delay,
> etc). For this case, you may need to create a
> reservation for the bandwidth on the routers along
> the path (including the SG itself) of the virtual
> wire. Here, you'd use RSVP to describe the flow
> and its needed characteristics for the virtual
> wire itself. Note that this doesn't have anything
> directly to with the original request. It's just a
> matter of creating the set of virtual wires which
> fits the incoming traffic patterns and policies.
> That is, there isn't necessarily a one-one
> relationship between the virtual wire's
> reservation and the incoming traffic. The virtual
> wire can be dimensioned however the SG wants to
> dimension it, and in fact would probably want
> aggregate the incoming flows if large enough.
> Indeed, it would probably want to use the same
> sorts of heuristics described in RSVP aggregation
> (RFC 3175). Also: it is perfectly possible to use
> RSVP to create dimensioned virtual wires, but the
> incoming traffic to the SG is pure diffserv. Here
> the SG polices the incoming traffic, but doesn't
> perform admission control on it.
>
> All in all, I don't see where IKE has any part in
> this mix.

It comes in only in the fact that you may need to negotiate an SA for
traffic with certain QoS settings. Whether the user is allowed a
higher level of QoS, and underlying packet classification in the
forwarding engine is completely separate and obviously not IKE's job.

jan


> Virtual wires need to be treated just
> like real wires, with admission control and
> policing as necessary, and virtual wires can be
> dimensioned on the fly themselves. Repeat until
> MTU == 0 :-).
>
> 	 Mike
>

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