Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt

From: "Alper Yegin" <[email-masked]>
Date: Thu, 17 Jan 2008 12:04:36 +0200

This I-D allows HA assignment by the NAS and HAAA. But how about HA
assignment by VAAA?

In WiMAX architecture, there are three distinct networks involved:
- ASN: that's where the NAS is.
- VCSN: VAAA is in that network. 
- HCSN: HAAA is here.

Is there a particular way to read this I-D such that it can support HA
assignment by the VAAA? Or, can we introduce specific text towards that?

Thanks.

Alper

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

---

From: <[email-masked]>
Date: Wed, 23 Jan 2008 08:58:14 +0100

Hi Alper,

> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 17. tammikuuta 2008 12:05
> To: [email-masked]
> Subject: [Dime] draft-ietf-dime-mip6-integrated-07.txt
> 
> This I-D allows HA assignment by the NAS and HAAA. But how 
> about HA assignment by VAAA?

A good point. The current text does not reflect this type of
deployment clearly enough, as the MIP6 integrated scenario 
bootstrapping does not really define such. Local HA is within
ASP and the current architecture does not make explicit
distinction between NAS and VAAA roles when it comes to local
HA assigment. 

However, in my opinion the I-D does not prohibit such
deployment either.

> Is there a particular way to read this I-D such that it can 
> support HA assignment by the VAAA? Or, can we introduce 
> specific text towards that?

I would reword a bit the text in section 4.7.5 and add an
example under section 5 to cover situations where the HA
is assigned by the visited AAA.

The rough logic for VAAA assigned HA would be the following:

1) NAS may or may not set the LOCAL_HOME_AGENT_ASSIGNMENT  
   capability.. it does not really matter if VAAA is in charge
   of local HA assignment and the NAS won't do anything regarding
   to local HA assignment anyway

2) VAAA overwrites the capability bits to indicate its preferences
   to HAAA regarding to the local HA assignment

3) HAAA functions as normally

4) In the reply the VAAA adds its local HA to the reply message

5) NAS receives 0-n assigned HAs, out of which some may be 
   assigned by the VAAA. NAS may find the which HA is from VAAA
   and which from HAAA by examing MIP6-Agent-Info AVP and
   associated HA FQDNs

Would this cover your needs? The above is within the current I-D
but could be expressed more clearly.

Cheers,
	Jouni

---

From: "Marks, Robert" <[email-masked]>
Date: Wed, 23 Jan 2008 09:14:29 -0500

Hi Jouni,

The VAAA should not be allowed to overwrite the reply. Instead, the VAAA
should propose the local HA in the request, as is done for NAS assigned
HA.

Bob

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Wednesday, January 23, 2008 1:58 AM
To: [email-masked]; [email-masked]
Subject: RE: [Dime] draft-ietf-dime-mip6-integrated-07.txt

Hi Alper,

Cheers,
	Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 23 Jan 2008 21:48:06 +0200

Hi Robert,

Seemed that my previous mail took off a bit early ;) Anyway..
In step 4) the VAAA does not need to overwrite AVPs in the
reply, it just adds its own HA info to the reply.

Cheers,
	Jouni

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Jan 2008 11:08:15 +0200

Thank you Alper for the review comments with regard to the applicability 
of the document to the Wimax environment.
Thank you Robert for the feedback.

I like Jouni's suggestion to make the text in the draft a bit more 
explicit regarding the functionality described below:

1) The NAS may set the LOCAL_HOME_AGENT_ASSIGNMENT 
   capability.

2) A VAAA may set or overwrite the capability bits to
   indicate the preference for the visited network.

3) The HAAA performs authentication and authorization (as usual)
   and returns a reply message.

4) The VAAA may add its local HA to the reply message

5) The NAS may receive zero or more HAs, out of which some may be
   assigned by the VAAA. The NAS is able to determine
   which HA is from the VAAA or from the HAAA by examing
   MIP6-Agent-Info AVP and associated HA FQDNs

Ciao
Hannes

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 24 Jan 2008 14:04:23 +0200

Thank you Jouni and Hannes for the responses.

In WiMAX use of RADIUS, we have dedicated attributes for both home-assigned
HAs and visited-assigned HAs. I see you are making that distinction by
relying on the FQDN of the assigning domain.

I guess that works as well. I'm also considering how we can deal with
protocol translation between RADIUS and Diameter for these payloads. Can we
assume if VCSN receives a RADIUS message with the home-assigned HA IP
address in it, the VAAA can generate the Diameter AVP with the right FQDN
for that HA as it forwards the message towards a Diameter-only ASN?

Alper 

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, January 24, 2008 11:08 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Marks, Robert
> Subject: Reviews of draft-ietf-dime-mip6-integrated-07.txt
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Jan 2008 14:22:21 +0200

Hi Alper,

> relying on the FQDN of the assigning domain.
That's interesting. Since we would re-use the approach we develop in 
DIME for the work in the corresponding RADIUS document there would be a 
misalignment.

> for that HA as it forwards the message towards a Diameter-only ASN?
That's a good question. The level of difficulty would largely depend on 
the placement of the translation device. I can imagine that there are 
potential translation device placements where the processing step 
wouldn't be so easy todo.

Ciao
Hannes

---

From: <[email-masked]>
Date: Thu, 24 Jan 2008 14:00:34 +0100

Hi Alper,

> In WiMAX use of RADIUS, we have dedicated attributes for both 
> home-assigned HAs and visited-assigned HAs. I see you are 
> making that distinction by relying on the FQDN of the 
> assigning domain.

Yes, the current ABNF allows 0-n HAs. That was mainly
due some folks thought it would be important. Peeking into
FQDNs is imho OK'ish approach. A mobile that is aware of
roaming in general typically also knows the realms of its
roaming partners.

> I guess that works as well. I'm also considering how we can 
> deal with protocol translation between RADIUS and Diameter 
> for these payloads. Can we assume if VCSN receives a RADIUS 
> message with the home-assigned HA IP address in it, the VAAA 
> can generate the Diameter AVP with the right FQDN for that HA 
> as it forwards the message towards a Diameter-only ASN?

This falls more into a system design and how roaming is defined
within the said system. The VAAA could e.g. inspect the contents
of the User-Name or CUI attributes in the replies, learn the home
realm there. Based on the realm info generate the FQDN for the
HA.. but as said details such these are out of scope of IETF.

Cheers,
	Jouni

> > Thank you Alper for the review comments with regard to the 
> > applicability of the document to the Wimax environment.
> > > bootstrapping does not really define such. Local HA is within ASP 
> > > and the current architecture does not make explicit distinction 
> > > between NAS and VAAA roles when it comes to local HA assigment.
> > >
> > > However, in my opinion the I-D does not prohibit such deployment 
> > > either.
> > >
> > >
> > >> Is there a particular way to read this I-D such that it 
> can support 
> > >> HA assignment by the VAAA? Or, can we introduce specific text 
> > >> towards that?
> > >>
> > >
> > > I would reword a bit the text in section 4.7.5 and add an example 
> > > under section 5 to cover situations where the HA is 
> assigned by the 
> > > visited AAA.
> > >
> > > Would this cover your needs? The above is within the 
> current I-D but 
> > > could be expressed more clearly.
> > >
> > > Cheers,
> > > 	Jouni
> > >
> > >
> > >
> > >
> > >
> > >> Thanks.
> > >>
> > >> Alper
> > >>
> > >>
> > >>