Subject: [Mip6] Comments on kempf-mip6-bootstrap

From: Alper Yegin <[email-masked]>
Date: Sat, 28 Feb 2004 23:08:29 -0800

Hello James, Jari,

I've just read the draft. Please see my comments below.

   With IKEv1, the mobile node needs to have a
   statically defined home address in order that the home agent can make
   an authorization decision and identify the credentials during the IKE
   Phase 1 ISAKMP exchange.  In this document, we discuss why these
   constraints may be problematic in some deployment scenarios.

IKEv2 allows named SPIs with address selectors set to NULL. Names can be
NAI and FQDN. If we use IKEv2, do we still have a problem?

   However, support for dynamic home address assignment would be
   desirable for the following reasons:

   DHCP-based address assignment

      Some ISPs may want to use DHCPv6 from the home network to
      configure home addresses [7].

I think we are concerned that the MN might get different DHCP addresses
each time it asks for one. Note that deployments can ensure that the
host (MN) gets the same IP address (home address) by supplying a
client-id with DHCP requests. So, this may not be a problem. 

   Currently, the address of the home agent is specified in the security
   policy database.  Support for multiple home agents requires the
   configuration of multiple security policy database entries.

We are talking about SPDs on the MN, right? If so, is this a problem? MN
can set the HA address in the SPD once it determines which HA it will be
using. The challenge is, I think, bootstrapping the keys for a given HA.

      Ease of deployment

      ISP may want to allow "opportunistic" discovery and utilization of
      its mobility services without any prearranged contact.  These
      scenarios will require dynamic home address assignment.

... and keys.

   The current IKEv1-based dynamic key exchange protocol described in
   [5] has no integration with backend authentication, authorization and
   accounting techniques unless the authentication credentials and trust
   relationships use certificates.

Isn't this an implementation issue? For example can't I use LDAP to
retrieve the keys for a MN when my HA receives an IKE request? Well,
there isn't a RADIUS or Diameter application for this scenario, maybe
this is what you mean. But I think this doesn't require integration of
IKE with RADIUS/Diameter.

   Using certificates may require the ISP to deploy a PKI, which may not
   be possible or desirable in certain circumstances.  Where a
   traditional AAA infrastructure is used, the home agent is not able to
   leverage authentication and authorization information established
   between the mobile node, the foreign AAA server, and the home AAA
   server when the mobile node gains access to the foreign network, in
   order to authenticate the mobile node's identity and determine if the
   mobile node is authorized for mobility service.

This is talking about integration of AAA for network access and AAA for
mobility management. I think "AAA for mobility management" does not
necessarily imply this level of integration. 

   The lack of connection to the AAA infrastructure also means the home
   agent does not know where to issue accounting records at appropriate
   times during the mobile node's session, as determined by the business
   relationship between the home ISP and the mobile node's owner.
   Presumably, some backend AAA protocol between the home agent and home
   AAA could be utilized but IKEv1 does not contain support for
   exchanging the right kind of information, primarily the NAI [6], with
   the mobile node.

Mobility management and network access are two separate services. We
shouldn't assume they have to be integrated. 

   The home agent discovery protocol does not support "opportunistic" or
   local discovery mechanisms in a roaming partner's local access
   network.  It is expected that the mobile node must know the prefix of
   the home subnet in order to be able to discover a home agent, it must
   either obtain that information through prefix update or have it
   statically configured.  A more typical pattern for interdomain
   service discovery in the Internet is that the client (mobile node in
   this case) knows the domain name of the service, and uses DNS in some
   manner to find the server in the other domain.  For local service
   discovery, DHCP is typically used.

If HAs are located on the visited links, then the current dynamic home
agent discovery is good enough. If they are somewhere deeper in the
access network, then a DHCP-based discovery, or what HMIP approach can
be utilized.

   Another scenario involves turning an existing security association in
   the user's home network for a different purpose into a new security
   association suitable for protecting Mobile IPv6.  For instance, an
   existing security association for a VPN service could be used to
   generate suitable Mobile IPv6 security associations, on a
   first-come-first-served home address basis.

Wouldn't some (most?) problems we encountered with the Mobile IPv6
service also apply to the VPN service? 

   For instance, when
   the mobile node boots and connects to the network for the first time,
   it could create a security association with the access operator's
   home agent.  This home agent could then be used as the mobile node
   moves into a different position or even into a different access
   network.

We are applying this type of a technique to the DHCP security problem.
Please see draft-yegin-eap-boot-rfc3118-00.txt

Regards,

Alper

_______________________________________________
Mip6 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip6

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 15:31:50 -0800

Alper,

Thanx for the comments. Replies below.

> NAI and FQDN. If we use IKEv2, do we still have a problem?

IKEv2 helps for this part of the problem.

> client-id with DHCP requests. So, this may not be a problem.

Having the addresses be fully dynamic would involve less administrative
burden than having them be partially static. But partially static addresses
might be a good solution for some deployment cases.

> using. The challenge is, I think, bootstrapping the keys for a given HA.

There's an issue of configuring the SPD, if the HA is discovered
dynamically. Presumably, this would be better done automatically, as it is
not something that most users would typically not want to deal with. But,
yes, key distribution is the primary problem.

>       scenarios will require dynamic home address assignment.

Yes.

> IKE with RADIUS/Diameter.

AAA and the HA can communicate auth/authz information via LDAP. There's an
issue of how the MN identifies itself to the HA independently of its home
address. IKEv2 helps with these problems, as you note above. There is still
an issue with accounting records, however, even if IKEv2 is used.

> necessarily imply this level of integration.

What level of integration do you think is necessary for AAA for mobility
management?

> shouldn't assume they have to be integrated.

When we wrote this paragraph, we didn't assume they are. The paragraph is
just trying to say that the mobility service provider might need some
support for issuing accounting records on the appropriate event boundaries.
If you can think of some text that makes this clearer, please post it.

> access network, then a DHCP-based discovery, or what HMIP approach can

This paragaph is trying to making a statement about 1) a lack of particular
functionality in the existing MIP spec and 2) how that functionality is
typically provided for other Internet services. It is not attempting to make
a statement about a solution for MIP. I think it advisable to keep solutions
out of a problem statement document. We could add a final statement to make
that clearer if you like.

> service also apply to the VPN service?

I'm not sure I understand your point. Could you clarify?

> Please see draft-yegin-eap-boot-rfc3118-00.txt

Good to see that we have some solutions under consideration.

            jak

---

From: Alper Yegin <[email-masked]>
Date: Sun, 29 Feb 2004 16:43:44 -0800

Hi Jim,

> an issue with accounting records, however, even if IKEv2 is used.

What is the accounting issue? HA should simply collect some counters,
and any centralized accounting server should be able to query HA via
SNMP.

> What level of integration do you think is necessary for AAA for
mobility

I think this is a different discussion than what this I-D should be
addressing. We should discuss it under another thread.

> support for issuing accounting records on the appropriate event
boundaries.

OK, I see.

> I'm not sure I understand your point. Could you clarify?

For example, the problems encountered in using dynamically allocated
home addresses with IKEv1 would also be applicable to the VPN solution.
Or, discovering and having dynamic keys with a Home agent is equivalent
to doing those with a VPN gateway. So I think you'd encounter the
similar problems with the VPN solution, hence bootstrapping off of a VPN
solution is more like moving the problem around. 

Alper

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Feb 2004 16:53:04 -0800

> and any centralized accounting server should be able to query HA via

Sure. But it might be cleaner for the HA to be able to issue its own
accounting records directly into the AAA system, as opposed to using a
gateway. Fewer moving parts.

> addressing. We should discuss it under another thread.

OK. But, isn't there a connection? The HA might want to use IKEv2 to check
auth/authz for mobility service via the AAA system.

> solution is more like moving the problem around.

Yes, that's true. I think the idea here is that if a VPN gateway exists and
is also an HA, the mobility service could somehow "upgrade" a VPN SA to a
Mobile IP SA if the user suddenly decided it wanted to move, rather than
have to establish a separate SA.

            jak