Subject: [Dime] HA acting as a VPN

From: "Julien Bournelle" <[email-masked]>
Date: Sat, 24 Mar 2007 13:47:26 +0100

Hi all,

 I changed the thread subject.

 A quick comment:

 The problem that I can see is that we have decided to use
 a Application-ID because we are doing AAA for Mobile IPv6.
  So, we shouldn't use the same Application to handle the case
 where IKEv2 is used for VPN. Diameter EAP should be used
 in this case.

 Concerning IDr to know the purpose for which IKEv2 is used,
 are you suggesting to define a specific FQDN that would say
 if it is for mip6 or not ?

 Regards,

 Julien

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

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Sat, 24 Mar 2007 15:35:31 -0400

Hi Julien,

The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be collocated
with the Home Agent function. This collocation makes sense in many
deployment scenarios.

So, the Home Agent/PDG/PDIF can initiate the correct Diameter
application based on IDr field. If the IDr is set to "mip6" or any other
string/fqdn indicating mip6, the appropriate Diameter application ID for
mip6 can be used. If not, regular Diameter base or Diameter EAP
application IDs should be used.

-Kuntal

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]]
> Sent: Saturday, March 24, 2007 7:47 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: HA acting as a VPN
> 
> Hi all,
>

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Mon, 26 Mar 2007 15:53:24 +0200

I agree with Kuntal that this is an issue we should handle or at least
mention in the document. Not sure if we need to provide a solution in
the IETF, since it seems a system-level issue, related to some
deployments.

What do others think?

--Gerardo

---

From: <[email-masked]>
Date: Mon, 26 Mar 2007 18:35:58 +0200

I agree with Gerardo. It is worthwhile documenting this but I also
think it could be better leave the solution outside IETF.

Cheers,
	Jouni

> From: Gerardo Giaretta [mailto:[email-masked]] 
> Sent: 26. maaliskuuta 2007 16:53
> To: Chowdhury, Kuntal
> Cc: [email-masked]
> Subject: Re: [Dime] RE: HA acting as a VPN
> 
> I agree with Kuntal that this is an issue we should handle or 
> at least mention in the document. Not sure if we need to 
> provide a solution in the IETF, since it seems a system-level 
> issue, related to some deployments.
> 
> What do others think?
> 
> --Gerardo
> 
> > application based on IDr field. If the IDr is set to "mip6" or any 
> > other string/fqdn indicating mip6, the appropriate Diameter 
> > application ID for
> > >  The problem that I can see is that we have decided to use  a 
> > > Application-ID because we are doing AAA for Mobile IPv6.
> > > where IKEv2 is used for VPN. Diameter EAP should be used  in this 
> > > case.
> > >
> > >  Concerning IDr to know the purpose for which IKEv2 is used,  are 
> > > you suggesting to define a specific FQDN that would say  if it is 
> > > for mip6 or not ?
> > >
> > >  Regards,
> > >
> > >  Julien
> >

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Mon, 26 Mar 2007 13:15:57 -0400

Jouni, Gerardo,

OK, in IETF what should be the trigger for using mip6 application ID in
Diameter messages?

-Kuntal

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, March 26, 2007 11:36 AM
> To: [email-masked]; Chowdhury, Kuntal
> Cc: [email-masked]
> Subject: RE: [Dime] RE: HA acting as a VPN
> 
are

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 27 Mar 2007 10:30:05 +0200

Hi Kuntal,

as far as IETF is concerned, I think we should not worry about
co-location of different logical entities. This is really something
that other SDOs need to look at.

Therefore, in IETF, the HA is a logical entity that starts the Mobile
IPv6 Diameter Application when it receives an IKEv2 message from a MN.
No need for anything else, since you can't make any assumption on
co-location of other logical entities with the HA.

I agree we should mention the issue in the document (I raised such an
issue last year), but I don't think we should define a solution for
that in IETF.

--Gerardo

On 3/26/07, Chowdhury, Kuntal <[email-masked]> wrote:
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 27 Mar 2007 06:03:43 -0400

Gerardo,

Fair enough...in IETF we can simply assume that IKEv2 is the trigger for
using mip6 application ID for the Home Agent. However we cannot make
this a MUST requirement if we want to allow the SDOs to define their
specs based on the collocation assumption.

Regards,
Kuntal

> Sent: Tuesday, March 27, 2007 3:30 AM
> To: Chowdhury, Kuntal
> Cc: [email-masked]; [email-masked]
a
> > > > > > you suggesting to define a specific FQDN that would say  if
it
> > is
> > "This email message and any attachments are confidential information
of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks,
Corp.
> Any review, retransmission, dissemination or other use of, or taking
of
> any action in reliance upon this e-mail and its attachments by persons
or
> entities other than the intended recipient is prohibited. If you are
not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [email-masked] -- and destroy all copies of this
message
> and any attachments without reading or disclosing their contents.
Thank
> you."