[Mip6] review of draft-ietf-mip6-bootstrap-ps-03.txt

[Jari Arkko <[e-mail]>]

Hi,

I have read the latest version of this draft. Some comments
below.

Overall: This is a well written document, ready to
be published. It covers the issues well. Some nits
and a few technical issues are noted below, however.

Technical:

>    o  A basic assumption in the Mobile IPv6 RFC [RFC3775] is that there
>       is a trust relationship between the mobile node and MSP.  This
>       trust relationship can be direct, or indirect through, for
>       instance, an ASP that has a contract with the MSP.  This trust
>       relationship can be used to bootstrap the MN.

Actually, in RFC 3775 there's an assumption about a relationship
between the mobile node and its home agent. The concept of an
MSP is rather defined in the reviewed document. I understand
that the concepts are very close, but the distinction may be
important, because it implies the difference between operating
directly with a home agent vs. through supporting infrastructure
such as AAA. Suggest s/and MSP/and its home agent(s)/.

Same issue also 9.1.

>    o  Yet another assumption is that some identifier, such as NAI, as
>       defined in [I-D.ietf-mip6-mn-ident-option-02] or [RFC2794] is
>       provisioned on the MN which permits the MN to identify itself to
>       the ASP and ASP.

This assumption that may not have to be true if
you consider all possible solutions - though its certainly
true in the solutions that are being designed right now.
(A bare bones bootstrapping scheme would allocate a
local home agent via DHCP and generate a limited-lifetime
SA using leap-of-faith. This would need to be supported
with a return routability check on every home registration.)

Also, s/ASP and ASP/ASP and MSP/ ?

> 6.  Network Access and Mobility services

This is a good section, but it appears to make
the assumption that current access
network and bootstrapping go together. I think
we should retain a degree of independence between
the mobility and access service, even if we use
it for bootstrapping. One aspect of this independence
is the ability to get the mobility service from somewhere
and keep on using it afterwards. For instance, you
probably want to visit your private home network
once in a while, and that network runs typically on
a bare DSL service that isn't likely to offer a lot
of service, let alone mobility on top of it.

> 3.  Design Goals

I liked the goals.

> 4.  Non-Goals

I was involved in the work of the design team in its
early phases, and probably agreed with these at the time.
However, I've recently started to wonder whether a
zero-config model (i.e. no trust relationship at all)
would actually be something that we should do as well.
Technically, this is possible. Provider input points to the
direction of always having a trust relationship, but I have a
feeling that we are developing a lot of complicated
technology, and the zero-config model would actually
allow us to reduce complexity instead, perhaps leading
to wider deployement.

Editorial

>       The serving network accesss provider may or may not additionally

s/accesss/access/

>       legitimate home agent address or boostrapping for the IPsec SAs

s/boostrapping/bootstrapping/

>    dependent.  For instance, the MN may bootstrap everytime it boots,

s/everytime/every time/

>    relevent IPsec RFCs must be quite strong.  Provisioning of keys and

s/relevent/relevant/

Maybe also "... we have to place a lot of trust to these security 
associations:
Provisioning of keys ..."

--Jari


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