Subject: [Mip6] Comments on draft-ietf-mip6-bootstrapping-split-01.txt

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 30 Nov 2005 10:29:55 +0100

Hi Gerardo, all,

Gerardo requested me to review
draft-ietf-mip6-bootstrapping-split-01.txt. Please find my comments
below, sorry for the delay.
In general, I think this is a well written document. 

Technical
=========

page 7 (end of page): 
---------------------
- "If, instead, a PKI is used, the MN and HA exchange certificates and 
there is no AAA server involved. This is conceptually similar to 
Figure 1, since the MSP == MSA, except the HA may require a 
certificate revocation list check (CRL check) with the Certificate 
Authority (CA). " 

	The text says that if PKI is used, the HA may require a CRL.
Doesn't the MN potentially require a CRL as well in this case? (e.g.,
for the rare case that HA is compromised). 

page 12:
--------
- " One way is to provision the 
mobile node with an FQDN for a local home agent when it configures 
for the local link. Another way is to specify an interoperable 
naming convention for constructing home agent FQDNs based on 
location. For example, an operator might assign the FQDN 
"ha.locationA.operator.com" to the Home Agent located in "location 
A" and the FQDN "ha.locationB.operator.com" to the Home Agent 
located in "location B". If the Mobile Node wants to use a Home 
Agent located in "location A", it will set the QNAME to 
"ha.locationA.operator.com" in the DNS request. The exact way in 
which localized Home Agents are configured is out of scope for 
this draft."

	I'm not totally happy with this paragraph. It describes how
local HA discovery/assignment in the split scenario can be done using
FQDNs based on location and the last sentence says that local HA
assignment is out of scope. IMHO it would be better to either make local
HA assignment in scope and specify a solution or, if it shall be out of
scope, not describe a solution at all. BTW, is there a separate document
planned for local HA assignment/discovery in the split scenario or shall
local HA assignment not be supported at all in this scenario? 

page 15:
--------
- "The Mobile Node auto-configures a Home Address from 
the prefix returned in the CFG_REPLY message and runs a 
CREATE_CHILD_SA exchange to create security associations for the 
new Home Address.  "

	Since there is not lifetime field in the home prefix attribute,
what is the lifetime the MN sets for the Home Address configured with
the prefix obtained from CFG_REPLY home prefix attribute? Is there a
default value? If so, what is this value? Or should MN do mobile prefix
discovery to obtain lifetime for the home prefix after the Home Address
has been configured with a prefix obtained through CFG_REPLY home prefix
attribute? 

- " Please see other drafts that contain detailed 
mechanisms for localized home agent assignment, such as [15], "

	There is no such section in [15] yet

- Regarding DDNS updates, I share some of Francis concerns, but I also
share the concerns of the DT stated in section 9.5.
(authentication/authorization of updates and redirection-based flooding
issue, if MN updates DNS). IMHO some more thoughts/discussions should be
spent on this issue. For instance, something like a cookie-based
reachability test (done by DNS server) of the address claimed by MN in
the DNS update could be considered to address the redirection-based
flooding attack concern. 

Editorial
=========

page 7 (end of page): 
---------------------
- The last sentence "Figure 3 illustrates. " seems to be missing
something

page 8:
-------
- "The split scenario is the simplest model that can be identified, 
since no assumptions about the access network are made. "

	s/"simplest model"/"most generic model" 

page 12:
--------

- "Note that a 
transport name cannot be used here because Mobile IPv6 does not 
run   over a transport protocol. "

	s/"run   over"/"run over"

- "The SRV RR has a DNS type code of 33. As an example, the Mobile 
constructs a request with QNAME set to "_mip6_ipv6.example.com" 
and QTYPE to SRV."

	s/"_mip6_ipv6.example.com"/"_mip6._ipv6.example.com"

page 14:
--------
- "Generated Addresses (CGAs) [9] or based on the privacy extensions 
for stateless autoconfiguration [10]. "

	s/autoconfiguration/auto-configuration 
("auto-configuration" most used spelling in rest of document)

page 17: 
----------
- "For this purpose the Mobile Node MAY include a new 
mobility option, the DNS Update option, with the flag R not set in 
the Binding Update. 

	This can be read as the R flag is in the BU, but it is in the
DNS Update option (same on next page). 

page 19:
--------
- Figure 3: I guess second BU should be BA

- Wrong figure numbering: Figure 3 already exist on page 8

page 20:
--------
- "Notice that, even in this last case, the Home Agent is always 
required to perform a DNS update for the reverse entry, since this 
is always performed in the DNS server of the MSP."

	IMHO this should be stated earlier (in section 6), not in the
"Summary of bootstrapping flow" section.

- Figure 4: I guess second BU should be BA

page 22:
--------
- in the figure: "!R|         Attribute Type     !            Length
| "

	use "|R|         Attribute Type     |            Length
| "  instead?

- "Prefix Length (1 octet) - The length of the home prefix 
           specified in the field Home Prefix. "

  use "Prefix Length (1 octet) - The length *in bits* of the home
prefix..." instead?

page 24: 
--------
- "Finally notice that assignment of an home agent from the serving 
network access provider's (local home agent) or a home agent from 
a nearby network (nearby home agent) may set up the potential to 
compromise a MN's location privacy. "

	s/"MN's location privacy"/"mobile node's location privacy"

- "The Mobile Node can either choose to request an 
address, similar to DHCP, or the Mobile Node can request a prefix 
on the home link then autoconfigure an address. "

	s/"autoconfigure"/"auto-configure"

- "RFC 3775 [2] and 3776 [3] require that a Home Agent check 
authorization on a home address received during a Binding Update."

	s/"a Home Agent check authorization on a home address"/"a Home
Agent checks authorization of a home address" ?

page 25:
--------
- "If the address is autoconfigured, RFC 3775 requires the Home Agent 
to proxy-defend the address on the home link after the Mobile Node 
performs the initial Binding Update. "

	s/autoconfigure/auto-configure

page 29:
--------
- some contributors are also in the ack section, some not. Is this
intended?

Regards,

Kilian

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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 30 Nov 2005 12:14:45 +0100

In your previous mail you wrote:

=> according to this argument the DNS update mechanism should be
changed because the mobility is not a special case. BTW it is clear
a solution to this problem is not in the scope of the MIP6 WG.
(IMHO it is a simple trust issue between the DDNS server and client)

Regards

[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Nov 2005 11:56:09 -0800

hi Kilian,

I am going to respond to a few of your comments.

Kilian Weniger wrote:

> assignment is out of scope. 

the text in the draft is not clear. what is out of scope
is how the MN is configured with the FQDN of the local HA
or configured with the knowledge of how to construct an
FQDN that points to a local HA. describing how FQDNs can
be used to lookup local HAs is very much in scope.

> IMHO it would be better to either make local

there are many ways to locally assign a HA.

1. the MN is configured with the FQDN of the local HA or
atleast configured with the knowledge of how to construct
an FQDN that would result in a local HA
2. the visited network uses DHCP to inform the MN of the
local HA's FQDN. (or the visited network uses DHCP to
inform the MN of the local HA's IP address)
3. the visited network uses link layer information
(examples - IPv6CP in PPP, configuration options in GTP)
to inform the MN of the local HA's FQDN or the local HA's
IP address.

I dont think we should be documenting all this in the
split scenario document.

> has been configured with a prefix obtained through CFG_REPLY home prefix

good question. it should be prefix lifetime. prefix
lifetime is generally used for auto-configuration. I
think we need to extend MIP6_HOME_PREFIX attribute to
include the prefix lifetime. perhaps something like
the following.

   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |R|         Attribute Type      !            Length             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                        home prefix                            |
  |                                                               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Prefix Lifetime                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Prefix Length |
  +-+-+-+-+-+-+-+-+

> the DNS update could be considered to address the redirection-based

agree. but I think modifications to DNS are beyond
the scope of MIP6 bootstrapping work.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Nov 2005 12:42:59 -0800

> (IMHO it is a simple trust issue between the DDNS server and client)

if the MN has some other mechanism to update the DNS
entry without involving the HA, all it has to do is
to exclude the DNS update option in the BU. the
problem is that we dont have scalable and secure
mechanism today without involving the HA.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Dec 2005 01:02:23 +0100

=> we have RFC 2136 which is used everyday and is scalable and secure
for the direct tree. The update in the reverse tree is done by the
entity which controls the allocation (I try to cover both static and
dynamic cases). So can you develop your argument, is it not secure
enough, not scalable, is the problem for the direct or the reverse tree.
BTW the term "involving the HA" is not accurate enough, I believe you
mean involving the mobility code in the HA.

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Nov 2005 16:28:28 -0800

Francis Dupont wrote:
> for the direct tree. 

well, AFAIK, RFC 2316 is not practical when you have a
lot of mobile nodes that want to update their DNS entries
from visited networks. you have to setup security between
each mobile node and the DNS server. it is easier for
the HA to do the DNS update on behalf of the mobile node.
and you still have the problem of the mobile node proving
to the DNS server that it actually owns the address and
is not setting up a DNS entry for some other mobile node's
home address.

> mean involving the mobility code in the HA.

correct. the MIP6 code on the HA.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Nov 2005 16:51:10 -0800

BTW, 2136 is used between the HA and the DNS server
in draft-ietf-mip6-bootstrapping-split-01.txt.

Vijay