Subject: [Mip6] review of draft-ietf-mip6-bootstrapping-split-00.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Sep 2005 11:25:25 +0300

Hi,

I finally found time to read this document. Overall, its
in very good shape, and I like the approach which
provides a number of separate tools that together
provide everything that you need for bootstrapping.

Some comments below, however:

Technical:

>      5.3.2. Home Address auto-configuration by the Mobile Node 

This section probably needs some additional work. I'm not
entirely happy with the approach, particularly the part where
home addresses are authorized. I'm not sure I have a better
suggestion, however.

One potential issue (and this is also an issue in [6]) is
that the identity given in EAP-based authentication
is not necessarily something that you can tie a long-term
home address identity to. For instance, the identity
could be a pseudonym (e.g. EAP-SIM), or a privacy NAI (e.g.
RFC2486bis). Another issue is that it would seem to be
useful that where CGA-based addresses are used that the
home agent would actually check the ownership.

>         Additionally, it could be useful to provide an ability for the 
> Mobile
>         Node to discover a Home Agent placed in a particular location 
> (e.g.
>         on the visited link). In order to achieve this, the Mobile 
> Node must
>         be able to construct a DNS request such that the DNS server 
> will be
>         able to reply with a Home Agent from the requested location. 
> This can
>         be accomplished by using a specific  naming convention for the 
> FQDNs
>         of the Home Agents.

Possible, but the description is mostly handwaving and would probably
benefit from a more generic solution in any case. Suggest
removing this.

>         The definition of this backend communication is out of the 
> scope of
>         this document. In [12] a list of goals for such a 
> communication is
>         provided.

I haven't read [12] yet. I'm just wondering whether this communication
is the same or very different from what a VPN gateway with IKEv2-EAP
support needs. If its the same, you might note that here. (There's no
spec for that either, but people still seem to be able to do that --
with some interoperability issues though.)

>         Since the DNS update must be performed securely in order to 
> prevent
>         attacks or modifications from malicious nodes, the node 
> performing
>         this update must share a security association with the DNS 
> server.
>         Having all possible Mobile Nodes sharing a security 
> association with
>         the DNS servers of the MSP might be cumbersome from an 
> administrative
>         perspective. Moreover, even if a Mobile Node has a security
>         association with a DNS server of its MSP, an address 
> authorization
>         issue comes into the picture. A detailed analysis of possible 
> threats
>         against DNS update is provided in section 9.5.

Hmm. An address authorization issue appears to come to the picture
even in the home agent based solution. We don't want a mobile node
M1 to take over the DNS name of mobile node M2. That's why the
home agent, or someone, needs to authorize the use of a particular
fqdn. This is later correctly noted, but not here.

And then in Section 9.5:

>         Regardless of whether the AAA server or Home Agent performs DNS
>         update, the authorization of the Mobile Node to update a FQDN 
> MUST be
>         checked prior to the performance of the update. It is an
>         implementation issue as to how authorization is determined.

I'm not sure its just an implementation issue. If its the home agent that
performs such an update, then its likely that some AAA attributes
are needed to support that (authorized-fqdn, 
feel-free-to-trust-the-mobile-node-
on-its-any-request attributes, for instance). Similarly, if its the
AAA server that performs the update, then the fqdn needs to be
carried in the protocol.

Editorial:

>         Node. The solution defined in this document solves the 
> boostrapping 

Typo.

>         there is not a Binding Cache entry, it sends a Neighbor 
> Soliciation 

Typo.

>         network deployment model [4], even if it might not be optimized . 

Extra space.

--Jari

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 23 Sep 2005 15:45:47 -0700

> benefit from a more generic solution in any case. Suggest

the main purpose of that paragraph is to point out that one can
lookup a HA based on the location, rather than always lookup a
HA from the home link. we initially had a lot of text explaining
how one could configure and construct a name based on the
location of the HA.

it was later removed since "lookup by location" and "lookup by
name" is the same with respect to MN's behavior. in both cases
the MN needs to be configured with the name. so this became a
paragraph in section 5.1.1.

I think it is needed.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Sat, 24 Sep 2005 09:23:14 +0300

> paragraph in section 5.1.1.

Ok. But ideally, I'd like to see either one of two outcomes: we don't
talk about this at all, or we talk about it in sufficient detail that
it can actually be implemented in an interoperable (multi-vendor)
way. If we keep the text, doesn't that imply that we have to talk
about the details too? For instance, you did not specify anything
about the manner in which you determine the location. Would that
be based on some location-determining technology, or simply
local router identities or IPv6 prefixes? Secondly, if the naming
convention isn't agreed upon its hard for the mobile node
implementations to guess the right name. Or perhaps the
idea is to have limited local prefix => fqdn mappings configured
in the mobile node?

(I like this function, by the way.)

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Tue, 27 Sep 2005 08:55:24 -0700

Another problem is that the MSP might want to set up the naming convention 
on their HAs to reflect some other aspect of their service offering or 
customer characteristics rather than location. I think it might be hard to 
capture the full range of what an MSP might want to do in sufficient detail 
to make a well-specified standard.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Vijay Devarapalli" <[email-masked]>
Cc: "Gerardo Giaretta" <[email-masked]>; "Mobile IPv6 Mailing 
List" <[email-masked]>
Sent: Friday, September 23, 2005 11:23 PM
Subject: Re: [Mip6] review of draft-ietf-mip6-bootstrapping-split-00.txt

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 27 Sep 2005 10:17:34 -0700

Jari Arkko wrote:
> local router identities or IPv6 prefixes? 

any of the above. I think it is out of scope for us to
specify this. AFAIK, there is a lot of work going on
in many SDOs for determining a mobile node's location.

Secondly, if the naming
> implementations to guess the right name. 

well, its just a "name". it could be anything, defined by
a particular operator and configured on the mobile node.
taking the example given in 5.1.1, it could be something
like "ha1.bayarea.example.com". I dont think we can come
up with a sensible naming convention that would be useful
for all deployments.

 > Or perhaps the

thats one way to do it. there could be a limited set of
mappings configured on the mobile node, mapping the prefix
on the access network to a particular "name".

> (I like this function, by the way.)

cool.

Vijay