Subject: [netlmm] LMA Discovery

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 10 Oct 2008 14:09:14 -0700

Hello,

The draft at the URL below captures the solution for LMA discovery.
Much of the content in the draft has already been discussed before on
the mailing list and at the Dublin IETF meeting.

Comments/reviews are welcome.

Vijay

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2008/10/10
Subject: I-D Action:draft-korhonen-netlmm-lma-discovery-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : LMA Discovery for Proxy Mobile IPv6
       Author(s)       : J. Korhonen, V. Devarapalli
       Filename        : draft-korhonen-netlmm-lma-discovery-00.txt
       Pages           : 9
       Date            : 2008-10-10

Large Proxy Mobile IPv6 deployments would benefit from a
functionality, where a Mobile Access Gateway could dynamically
discover a Local Mobility Anchor for a Mobile Node attaching to a
Proxy Mobile IPv6 domain.  The purpose of the dynamic discovery
functionality is to reduce the amount of static configuration in the
Mobile Access Gateway.  This specification describes a number of
possible dynamic Local Mobility Anchor discovery solutions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-korhonen-netlmm-lma-discovery-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 11 Oct 2008 00:35:16 +0300

What would be the utility of delivering LMA FQDN during AAA when we could
deliver IP address of LMA? Is there any benefit of having this FQDN->IP
address indirection?

   However, the risks described in RFC
   5026 are mitigated to a large extent in this document, since the MAG
   and the LMA belong belong to the same PMIPv6 domain.  The DNS server
   that the MAG queries is also part of the same PMIPv6 domain.  

LMA and MAG can belong to two different operator networks. Not sure how
being in "same PMIPv6 domain" helps here.

   Even if
   the MAG obtains the IP address of a bogus LMA from a bogus DNS
   server, further harm is prevented since the MAG and the LMA should
   authenticate each other before exchanging PMIPv6 signaling messages.
   RFC 5213 [1] specifies the use of IKEv2 [3] between the MAG and the
   LMA to authenticate each other and setup IPsec security associations
   for protecting the PMIPv6 signaling messages.

But we know it is not mandatory to use IPsec. And in fact 3GPP does not. So,
the above assumption is not always valid either.

Alper 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Vijay Devarapalli
> Sent: Saturday, October 11, 2008 12:09 AM
> To: NETLMM Mailing List
> Subject: [netlmm] LMA Discovery
> 
> Hello,
>

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Fri, 10 Oct 2008 17:59:54 -0400

Hi Alper,

> deliver IP address of LMA? Is there any benefit of having

I believe there are some scenarios where the FQDN is returned to the MAG
and the some sort of DNS-based load balancing is used to pick the right
LMA. The AAA might not be able to do this sort of load balancing. This
scenario, where the LMA FQDN is returned to the MAG during access
authentication, is described in 3GPP specifications. 

> being in "same PMIPv6 domain" helps here.

See the definition of PMIPv6 domain in RFC 5213.    

   Proxy Mobile IPv6 Domain (PMIPv6-Domain)

      Proxy Mobile IPv6 domain refers to the network where the mobility
      management of a mobile node is handled using the Proxy Mobile IPv6
      protocol as defined in this specification.  The Proxy Mobile IPv6
      domain includes local mobility anchors and mobile access gateways
      between which security associations can be set up and
      authorization for sending Proxy Binding Updates on behalf of the
      mobile nodes can be ensured.

The fact is the MAG would not be querying a DNS server on the Internet.
The MAG and the DNS server would be in the same PMIPv6 domain, if the
PMIPv6 domain stretches across two operator administrative domains. The
intention is to say, even though you use DNS, you don't send the request
to some random DNS server. The "bogus DNS server threat" might not be
too relevant in a PMIPv6 domain. Any text suggestions to better capture
this are welcome. 
 
>    authenticate each other before exchanging PMIPv6 signaling
>    messages. RFC 5213 [1] specifies the use of IKEv2 [3] between the
>    MAG and the LMA to authenticate each other and setup IPsec
>    security associations for protecting the PMIPv6 signaling messages.
> 
> But we know it is not mandatory to use IPsec. And in fact 3GPP does
> not. So, the above assumption is not always valid either.

RFC 5213 uses 'SHOULD' for the MAG and the LMA to authentication each
other. So yes, it is not mandatory. We can modify the text to

   Even if
   server, further harm can be prevented if the MAG and the LMA

Does this sound better?

Vijay

>> From: [email-masked]
> [mailto:[email-masked]] On Behalf
>> Of Vijay Devarapalli
>>        Pages           : 9 Date            : 2008-10-10
>> 
> http://www.ietf.org/internet-drafts/draft-korhonen-netlmm-lma-
> discovery-
>> 00.txt
>>

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 11 Oct 2008 22:28:17 +0300

Hi Vijay,

> authentication, is described in 3GPP specifications.

I'm skeptical about that. How can the DNS ensure to give the same LMA to
each MAG? Also, how can the DNS know the load situation on the LMAs? 

> too relevant in a PMIPv6 domain. Any text suggestions to better capture

Based on the above definition, the PMIP6 domain can span the collection of a
number of operator networks. It is not necessarily a single network domain.
I'm not able to come up with a text to turn this into some sort of a
"protected domain" where DNS is secured from threats. Maybe someone with
more DNS expertise can help here. 

>    for protecting the PMIPv6 signaling messages.

If an out-of band security mechanism, such as relying on lower-layer
security, is used instead of IKEv2/IPsec, then the bogus LMA threats can be
prevented to some extent (e.g., LMA cannot be some node on the wild Internet
outside the PMIP6 domain. But it can be the wrong LMA within the same PMIP6
domain.... AAA-based discovery does not have this problem.)

Alper

---

From: <[email-masked]>
Date: Sun, 12 Oct 2008 10:22:48 +0200

Hi Alper, 

See some comments inline.

> Hi Vijay,
> 
> > > What would be the utility of delivering LMA FQDN during 
> AAA when we 
> > > could deliver IP address of LMA? Is there any benefit of 
> having this 
> > > FQDN->IP address indirection?
> > 
> > I believe there are some scenarios where the FQDN is 
> returned to the 
> > MAG and the some sort of DNS-based load balancing is used 
> to pick the 
> > right LMA. The AAA might not be able to do this sort of load 
> > balancing. This scenario, where the LMA FQDN is returned to the MAG 
> > during access authentication, is described in 3GPP specifications.
> 
> I'm skeptical about that. How can the DNS ensure to give the 
> same LMA to each MAG? Also, how can the DNS know the load 
> situation on the LMAs? 

The last paragraph of Section 2.2 already hints that a plain FQDN-based
discovery is not really enough alone. Merely useful for the initial
discovery of the LMA, where I think it has an use case.

I did not really think that DNS would be aware of the load of the LMAs.
Typically just a simple DNS roundrobin would be used to distribute MNs
among several LMAs.

> > >    5026 are mitigated to a large extent in this document, 
> since the 
> > > MAG
> > PMIPv6 domain stretches across two operator administrative domains. 
> > The intention is to say, even though you use DNS, you don't 
> send the 
> > request to some random DNS server. The "bogus DNS server 
> threat" might 
> > not be too relevant in a PMIPv6 domain. Any text 
> suggestions to better 
> > capture this are welcome.
> 
> Based on the above definition, the PMIP6 domain can span the 
> collection of a number of operator networks. It is not 
> necessarily a single network domain.

That's true and also assumed here.

> I'm not able to come up with a text to turn this into some 
> sort of a "protected domain" where DNS is secured from 
> threats. Maybe someone with more DNS expertise can help here. 

I think we are back to normal DNS security issues here that exists
there for all deployments that use DNS. We could come up with generic
DNSSEC etc text.

Deployments I had in mind do not really depend on Internet DNS.
However, the draft should not assume that.

> If an out-of band security mechanism, such as relying on 
> lower-layer security, is used instead of IKEv2/IPsec, then 
> the bogus LMA threats can be prevented to some extent (e.g., 
> LMA cannot be some node on the wild Internet outside the 
> PMIP6 domain. But it can be the wrong LMA within the same 
> PMIP6 domain.... AAA-based discovery does not have this problem.)

Cheers,
	Jouni

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 12 Oct 2008 22:13:08 +0300

Jouni,

> Typically just a simple DNS roundrobin would be used to distribute MNs

It is still not clear how you handle MAG2 learning a different LMA than what
MAG1 learned from DNS because DNS is alternating the LMAs it sends back.

Alper

---

From: <[email-masked]>
Date: Mon, 13 Oct 2008 01:12:09 +0200

Alper,

> > > > balancing. This scenario, where the LMA FQDN is returned to the 
> > > > MAG during access authentication, is described in 3GPP 
> specifications.
> > >
> > > I'm skeptical about that. How can the DNS ensure to give the same 
> > > LMA to each MAG? Also, how can the DNS know the load situation on 
> > > the LMAs?
> > 
> > The last paragraph of Section 2.2 already hints that a plain 
> > FQDN-based discovery is not really enough alone. Merely 
> useful for the 
> > initial discovery of the LMA, where I think it has an use case.
> > 

Section 4 Handover Considerations says:

   information to the new MAG is required.  Obviously, relying on DNS
   during handovers is not a working solution if the PMIPv6 domain has
   more than one LMA...

So you simply don't handle such case if a FQDN resolves to more than
one LMA.

Obviously, if the AAA-based deployment wishes to always use DNS, even
if there are multiple LMAs, then the AAA must always return FQDNs that
resolve exactly to one LMA. Such solution is doable but not necessarily
reasonable.

Cheers,
	Jouni