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

From: Alper Yegin <[email-masked]>
Date: Mon, 01 Mar 2004 02:52:08 -0800

> > What is the accounting issue? HA should simply collect some
counters,
> > and any centralized accounting server should be able to query HA via
> > SNMP.
> >
> 
> 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.

There is no 3rd party necessarily in my approach. What you call "AAA
system" is my "centralized accounting server".

> > I think this is a different discussion than what this I-D should be
> > 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.

Sure, this is "AAA for Mobile IPv6 service". My point was, there is one
other level of integration, basically bundling "AAA for Mobile IPv6
service" with "AAA for network access service". This is what 3GPP2 did
with Mobile IPv4. 

Alper

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

---

From: "Barany, Pete" <[email-masked]>
Date: Sun, 28 Mar 2004 07:40:35 -0800

Hi,

In regards to your first point below, I am not quite sure what you are
saying. During the IKEv2 IKE_AUTH phase, the initiator message looks as
follows (per IKEv2 -12 I-D):

HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr] AUTH, SAi2, TSi, TSr} -->

The responder message looks like:

<-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Are you saying that in the initiator's message the TSi, TSr will be
wildcarded (i.e., is that what you mean by NULL)? Wouldn't the TSi
included (at a minimum), the dynamic HoA, protocol MH in order to update
SPD?

Also, are saying that the IDi in the initiator's message will be mapped
to the SPI(s) in SAi2? If so, is the SPI mapped (indirectly via the IDi)
to a name selector?

Thanks.

Regards,

Pete

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Alper Yegin
Sent: Saturday, February 28, 2004 11:08 PM
To: [email-masked]
Subject: [Mip6] Comments on kempf-mip6-bootstrap

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