Subject: [Dime] HA-to-AAAH/HA as a single box ?

From: Julien Bournelle <[email-masked]>
Date: Fri, 6 Oct 2006 12:58:32 +0200

Hi all,

   I also prefer start a new thread on this subject.

   Gerardo raised an issue concerning the fact that 
   the IKEv2 Responder of the HA may also act as a VPN concentrator.

   The issue is that the IKEv2 responder has (a priori) no way to know
   if the IKEv2 Initiator wants mip6 service or VPN.

   If it wants mip6 service, it should use 4072 in
   AUTHENTICATE_ONLY mode and then use the mip6 Authorization
   application. If it wants VPN, I guess 4072 would be used
   in a different way.

   So before trying to solve this, the question is to know wether
   we can assume that HA is a single box.

   I personnally would prefer assume the IKEv2 responder is only for 
   HA and add a note in the document about this problem.

   Any comments ?
   
    Julien

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 11 Oct 2006 17:10:21 -0700

>    the IKEv2 Responder of the HA may also act as a VPN concentrator.

IMO, this must be supported.

>    if the IKEv2 Initiator wants mip6 service or VPN.

there are many ways of doing this. some deployments use
the IDr field to indicate that you are going to use a
certain service.

Vijay

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Thu, 12 Oct 2006 10:34:52 +0200

> IMO, this must be supported.

Agree (this is obvious since I raised the issue)

> the IDr field to indicate that you are going to use a

based on this approach, the IDi (isn't the initiator's ID and not the
reponder's?) must be chosen based on the service. This means that the
MN needs to have different permanent long-lived identities for
different services. This is doable but it seems it introduces an extra
identity management effort.

Obviously another approach would be to identify the service in IKEv2
exchange (e.g. using different CONFIG attributes for different
services), but I'm not sure this can be acceptable for IPsec people.

Some more suggestions?

--Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 12 Oct 2006 08:00:28 -0700

> services), but I'm not sure this can be acceptable for IPsec people.

do you want to find a solution for this on this
mailing list or assume it would be possible to get
an indication at the IKEv2 responder somehow? ;)

Vijay

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 12 Oct 2006 11:11:28 -0400

On Thu, Oct 12, 2006 at 10:34:52AM +0200, Gerardo Giaretta wrote:

(snip)
> services), but I'm not sure this can be acceptable for IPsec people.

It seems that identification of service within IKEv2 can be a rat hole
because of ambiguity of the term "service" in IKEv2.  I believe this
approach is difficult to succeed.

Yoshihiro Ohba

---

From: "Julien Bournelle" <[email-masked]>
Date: Thu, 12 Oct 2006 17:14:46 +0200

Hi vijay, all,

> an indication at the IKEv2 responder somehow? ;)

 I personnaly would prefer assume that the IKEV2 responder has a way
to differentiate but not deal with that in the document (however we
may add a quick note on this)

 Julien