[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Choosing between IKEv2 and JFK
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 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 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. 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