Subject: [Dime] Some thoughts about Diameter MIPv6 Application

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 2 Oct 2006 11:04:39 +0200

Hi all,

I would like to share with you some considerations about the Diameter
Application for MIPv6. Some questions also follow.

- first of all I think the proposal made by Yoshi to use rfc4072 in
AUTHENTICATION_ONLY mode and define another MIP6-specific application
for authorization is the right one. Indeed, this would let separate
clearly the authentication procedure from the authorization step and I
think this is really needed in case IKEv2 is used. Suppose for example
a node acts as both VPN concentrator and HA (or 3GPP PDG and HA): it
supports IKEv2 signaling and acts as EAP pass-through authenticator in
order to setup the IPsec SA with the peer. If a MN starts an IKEv2
exchange with this node, this node has no way to know if the MN is
going to use MIPv6 service or not (since the MN could be just setting
up the SA for remore access). Therefore, we need to take into account
that the HA is not sure that the MN is going to use MIPv6 service
untill it receives a BU. In my view, this is a valid reason to keep
authentication and authorization separated: the former is based on
rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific
and can be done later

- based on what stated above, the first authorization request should
be sent by the HA upon the receipt of the first BU. However, this will
increase the latency of the first registration, since the AAA of the
MSA will be involved. Notice that in case the MN is moving from the
home link to a visited link, the first registration has low handoff
latency requirements.
An alternative approach to handle this scenario is that the HA sends
the Authorization Request in a proactive way, before receiving the BU.
However, based on what stated above, this is possible only if the HA
is sure the MN will use MIPv6 service (i.e. the IKEv2 responder acts
only as HA and not as a generic node providing remote access)

- based on draft-ietf-mip6-aaa-ha-goals the AAA server may send an
Abort Session Request to the HA in order to stop the MIPv6 service for
a MN. This message may be very similar to the ASR in NASREQ. One
question is: from a MIPv6 perspective, is there any signaling the HA
will send to the MN to communicate that the session is over for a
specific reason? Or the MN is just blocked?

- I guess, as in NASREQ, the AAA-MSA sends an authorization lifetime
to the HA and this lifetime will be renewed later. Is this
authorization lifetime related with the BU/BA lifetime? Are they equal
or orthogonal? The HA may set the binding lifetime in the BA equal to
the authorization lifetime. Is this approach useful?

- again on the re-authorization: which are the information used to
request the re-authorization? Does a change of CoA trigger a
re-authentication? This will let the operator to authorize the MN
depending on the location. However this will increase the handoff
latency experienced by the MN.

- on the identities used by the MN: which identity is used by the HA
to identify the MN in the authorization phase? There is no identity in
the BU, unless we use the HoA as the identity. Otherwise the HA must
keep the identity used in IKEv2 by the MN. Any thought?

--Gerardo

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 02 Oct 2006 23:14:21 +0200

Hi Gerardo,

Gerardo Giaretta schrieb:
> for authorization is the right one.

I think it is a good starting point for further discussions.

  Indeed, this would let separate
> rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific

A problem appears only if the IKEv2 responder plays two roles and if the 
authorization decisions are different for the two.

> the authorization lifetime. Is this approach useful?

I think this is largely a policy decision. A short discussion in the 
document would be useful though.

> latency experienced by the MN.

That's a good question and also showed up in QoS discussions in the 
past. It is again a policy decision. If it is purely a policy at the HA 
then there is no problem since it can trigger a re-authorization 
procedure with the HA whenever necessary.

The problem appears only when the AAA server wants to trigger the HA to 
initiate re-authorization procedure in presence of certain events (e.g., 
  change of CoA). In this case there is a need for an extension.

Which one do we want here?

> keep the identity used in IKEv2 by the MN. Any thought?

Good question. What about using the session identifier?
For accounting records one might also use the session identifier (in the 
Acct-Multi-Session-Id) to indicate that accounting records relate to the 
   previous authentication/authorization protocol message exchange.

Ciao
Hannes

---

From: Julien Bournelle <[email-masked]>
Date: Tue, 3 Oct 2006 12:37:12 +0200

Hi gerardo, all,

 thanks for this considerations,

> for authorization is the right one. 

 yes. 

> home link to a visited link, the first registration has low handoff

 This basically raises the following general question: when do the HA use the
 mip6-Authz application ?

 I think to solve this issue, we also have to take into considerations
 the Home Address Allocation. Let me start a new thread on this
 particular subject.

> specific reason? Or the MN is just blocked?

 that's indeed a good question. Maybe we should also ask it to the mip6
 WG. Personnally, I think the MN should be informed.

> the authorization lifetime. Is this approach useful?

 this raises another question. As we use 2 Diameter Application for
 this, which one provide the Authorization-Lifetime and for which
 purposes ?

 In fact, we may also consider the lifetime of the IPsec SAs.
 So we can consider:
 - IPsec SAs lifetime
 - Binding Lifetime (related to BU/BA)
 - Mobile IPv6 Session Lifetime

 others ?

> keep the identity used in IKEv2 by the MN. Any thought?

 I thought that the HA should use the identity provided in the IKEv2
 exchange.

 Sorry to bring more questions than responses...

 Julien

-- 
julien.bournelle at int-evry.fr

---

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

apologies for the late reply.

> rfc4072 and occurs during IKEv2 exchange, the latter is mip6-specific

it should be possible to combine the two AAA round trips
when the VPN gateway and the MIP6 HA are co-located and
if it is known beforehand that the MS is going to be
using MIPv6 after the IPsec tunnel is setup. we shouldn't
_require_ two round trips.

> home link to a visited link, the first registration has low handoff

that is fine. RFC 3775 has defined a longer timer for
the initial BU to allow for DAD for the home address to
happen.

> specific reason? Or the MN is just blocked?

the HA switch message from the HA to the MN can be used.
http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt

> the authorization lifetime. Is this approach useful?

they should be orthogonal.

> keep the identity used in IKEv2 by the MN. Any thought?

identity used in IKEv2 should be used. if there is a need
for a separate identifier for MIPv6, RFC 4283 defines an
MN identifier option to carry, for e.g. an NAI.

Vijay

---

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

Hi Vijay,

thanks for your comments. Please see inline...

> _require_ two round trips.

Agree, if we can solve the issue about HA and VPN server co-location.
But it seems to me that the correct design is to have the two AAA
round trips as separated; obviously we can allow an optimization to
have them combined if this is possible.

> the initial BU to allow for DAD for the home address to

ok

> http://www.ietf.org/internet-drafts/draft-ietf-mip6-ha-switch-00.txt

Based on HA switch draft the MN MUST perform HA discovery if no HA
addresses are provided in the HA switch message. However, in this
scenario, the AAA server may just want to tear down the service. The
MN should stop trying to access mobility service.

We may use the HA switch message with a flag set in order to indicate
that the service will be torn down.

> they should be orthogonal.

any particular reason to not bind them?

> MN identifier option to carry, for e.g. an NAI.

good, agree that identity used in IKEv2 should be used.

--Gerardo

---

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

> have them combined if this is possible.

right.

> that the service will be torn down.

it would be good to discuss this on the MIP6 mailing
list. the HA Switch message can have a flag to say
MIPv6 service is not available anymore.

> any particular reason to not bind them?

the BU lifetime is proposed by the MN and the HA
normally agrees to it (unless it is larger than the
maximum binding lifetime on the HA). the
authorization lifetime is decided by the AAA-MSA. I
don't see an advantage in trying to bind them.

Vijay