[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Choosing between IKEv2 and JFK



On 8 Mar 2002, Derek Atkins wrote:

> Michael Thomas <mat@cisco.com> writes:
> 
> >    Huh? The certs are only there for identity. If I 
> >    want to have two different SA's so I get differential
> >    queuing treatment, there's nothing that says that I
> >    need two different identities. I just change the
> >    traffic selectors. This isn't any different than
> >    RSVP flow selectors and queuing treatment.
> 
> No, in reality the certs are there for authorization.  It's just that
> people don'e understand the concept of capabilities, so we have this
> ad-hoc "identity" cert and map it via some local lookup method to a
> set of capabilities.
> 
> You receive an "identity" cert, validate the cert, validate that the
> message is authentic using this cert, and then you lookup the
> capabilities of this "identity" to validate the authorization for the
> requested operation.
> 
> In terms of different flow selectors, it is perfectly reasonable to
> say that each flow requires its own certificate specifying the
> capability of that particular flow.

I finally realized what bothers me about this, which I think is also
what angelos was talking about: What you're really saying is that IKE
is now essentially doing admission control for QoS based on a cert
(attribute certs?!). I'm not sure I buy that. It's neither IPsec's nor
IKE's job to perform admission control for QoS.

I'm assuming that some other layer already did this (does RSVP do
this? Sorry. I don't know much about QoS), and that IKE merely
negotiates the tunnel for the new QoS traffic. if it wasn't allowed,
the other end will drop the packet, or the local stack (if not hacked)
will drop the packet.

I think this is especially true in the SGW case.

IKE merely needs to be able to negotiate the new SA for this new QoS
level, and I would assume (have assumed) that this would happen under
the same ID/cert as before. No difference there.

Of course this assumes some additional capabilities in
Ipsec-selectors, i.e. to be able to include QoS levels in the SA
negotiation, but that may be needed whether we use the same or a
different cert.

If you DID want to do it via a new cert, would that cert have to be
built on the fly?! That sounds really rather bad. Voice traffic
doesn't need added latency to build and sign a completely new
cert. Maybe this is how attribute certs work. I'm willing to listen :)

If the information about what you (as identified by your cert) is
static, why not build it into the same cert (i.e. jan is allowed low
priority and high priority)? You save the information and verify it
against the next phase 2. No need to redo a phase 1 (the cert is the
same, the authorization is the same).


>  Similarly, you could specify an
> "identity" that is capable of both flows.
> 
> The problem with using identity for capability verification is that
> there is no way of knowing _which_ capability actually applies to any
> situation.  You have to depend on the user requesting the appropriate
> flow characteristics, but unless there is a real-world cost associated
> with that choice, what incentive does the user have?
> 
> 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?

Why indeed? Because presumably your ISP or whoever is at the other end
will either disallow it, or charge you more.

Is this an IKE issue at all? This is a regular QoS admission control
problem.



>  OTOH, if
> there were clearly different certificates for teh two capabilities,
> then you could restrict access to the different certs.
> 

You COULD, but I'd argue it's not IKE's job (or JFK's or IKEv2)...

jan


> Basically, I'm saying that you are both right -- you are just coming
> from very different viewpoints.  However neither is wrong.
> 
> > 	     Mike
> 
> -derek
> 
> -- 
>        Derek Atkins
>        Computer and Internet Security Consultant
>        derek@ihtfp.com             www.ihtfp.com
> 

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