Subject: [Mip6] Review of draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Oct 2005 17:03:13 +0300

Hi,

I have read this draft. Thanks for writing this up! This is
indeed an important scenario that we must cover. Overall,
I'm happy with the solution architecture, particularly the
part where DHCP does not need any AAA interface and
the AAA-derived keys are not needed. But I still wonder
if the solution could be simplified some more, given that
the an eventual second authentication and AAA transaction
will be performed when you actually contact the discovered
home agent.

First, if the DHCP relay/NAS is aware of which client
is making the DHCP request, it does not seem necessary
to communicate home network information. The NAS
either got a home network-allocated HA in the AAA
transaction or it didn't. If it did, this can be passed on
in to the DHCP in the relay option. If it didn't, then we
can allow DHCP server to assign local home agents
on a round-robin (or whatever) basis. The latter approach
is nice in the sense that it does not require any additions
to existing NASes, DHCP relays, or AAA.

But I could be missing something.

Some additional points below.

Technical:

>3.2  Bootstrapping Message Sequence, Success Case
>
>   In the success case, the mobile node is able to acquire the home
>   agent address via a DHCPv6 query.  The message flows for home agent
>   allocation in the ASP and the MSP are illustrated below.  Since, in
>   the integrated scenario, the ASA and the MSA are the same, it can be
>   safely assumed that the AAAH used for network access authentication
>   (ASA) has access to the same database as the AAAH used for the
>   mobility service authentication (MSA).  Hence, the same AAAH can
>   authorize the mobile node for network access and mobility service at
>   the same time.
>
At the same time... hmm... there are two complications.
One is that the AAAH does not know at the time the network
access request is being made if the MN even wants mobility
service. This may not be a practical problem, unless only
the AAA infrastructure is taking care of load-balancing -type
issues for the home agents.

The other complication is that presumably, since [BOOT-SPLIT]
is being used for the actual communication with the home agent,
then *another* AAA transaction will be made. So I would say
that what this draft is doing is really only about discovery.
It can not guarantee that the subsequent transaction will
be authorized nor can it prevent that someone who hasn't
gone through the discovery part will be denied service.

This questions the need to spend a lot of effort for the
discovery part.

>   (2) The mobile node sends a DHCPv6 Information Request message
>   [RFC3315] to the All_DHCP_Relay_Agents_and_Servers multicast address.
>   In this message the mobile node (DHCP client) SHALL include the
>   Option Code for Home Network Identifier Option [HAOPT] in the
>   OPTION_ORO, Home Network Identifier Option with id-type set to 1 and
>   the Home Network Identifier field set to the network realm of the
>  
>
Why do we need this option? Presumably, the DHCP relay
is aware which NAS client this is, and picks the correct
information.

>   This section describes a scenario where the mobile node requests for
>   home agent allocation in the ASP by setting the id-type field to zero
>   in the Home Network Identifier Option in the DHCPv6 request message.
>   In this scenario, the ASP becomes the MSP for the duration of the
>   network access authentication session.
>  
>
There's an assumption here about the (non-)interleaving
of mobility and access services that I'm not sure I like.
Presumably you'd want the ASP to become an MSP for a
given duration, possibly at least for a while beyond the
time the mobile node is at this access network. Or at
the very least you should allow this.

>   (3) The Relay Agent intercepts the Information Request from the
>   mobile node and forwards it to the DHCP server.  The Relay Agent
>   (which is the NAS) also includes the received AAA AVP from the AAAH
>   in the OPTION_MIP6-RELAY-Option.
>  
>
>3.5.1  DHC Relay Agent Option to carry Mobile IPv6 parameters
>
Ok, so the basic solution is simply inserting the
discovered home agent information (if any) at the
relay so that the DHCP server can pick it up without
having to have an interface to AAA. This sounds good.
(Is there a reason why the relay can't add the answer
directly to the response?)

>   The transport of the assigned home agent information via the AAA
>   infrastructure (i.e., from the AAA server to the AAA client) to the
>  
>
Do we have existing, standard AAA attributes for the transport
of this information?

>   The communication between the NAS/DHCP relay agent to the DHCP server
>   must be authenticated, integrity and replay protected.  Deployments
>   MAY either rely on lower-layer security, (i.e., physical or link
>   layer security), or rely on security mechanisms specifically defined
>   for DHCPv6, such as [RELAY-IPSEC] or [RFC4030].
>  
>
I wasn't sure if the above means that e.g. dedicated physically
protected link is out of the question.

Anyway, I would recommend "SHOULD be authenticated ...
Deployments MAY rely on physical protection of the links
in question, or security mechanisms designed to protect
link layer, IP layer, or DHCP communications [...]".

Editorial:

>   in the mobile node's home MSP network. in order to provide the mobile
>
s/in/In/

--Jari

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