Re: FQDN authorization and splitting drafts (was Re: Concensus Call: DNS Update for Bootstrapping)

>
> IMO, this is explained clearly in the draft. if not the
> draft can be clarified as you want. which part of the draft
> is not clear?
>

The draft states:

"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..."

And then states:

"Therefore, due to security and administrative reasons, it is
        RECOMMENDED that the Home Agent perform DNS entry update for the
        Mobile Node...."

This is misleading. You are not solving the above problem of generally
protecting against all malicious nodes. You are specifically solving
the problem of "a node being trusted to provide the right FQDN
providing the wrong HoA". The definition of a malicious node is really
much broader and can be subject to interpretation.

Even in section 9.5, the draft talks about the fact that FQDN
ownership can be taken care of with DNSSEC, while address ownership
can't. It fails to mention that with the HA performing the DNS update,
it is the exact reverse - while address ownership is taken care of,
FQDN ownership isn't. I think it should be clearer that we cannot get
FQDN *and* address ownership if that was needed.

>
> nope. we already have too many drafts for MIP6 bootstrapping.
> it becomes a mess when somebody tries to implement all
> the stuff. so far there are potentially 9 drafts if we talk
> about a complete MIP6 bootstrapping solution.
>

Whether it is the 9 documents listed below or a shorter list as
Francis says, I am sorry to say that this seems to be taking the
doomed path of IKEv1. The kind of cross references we will have here
is going to be bad. (Not to mention that boostrapping mip6 technically
doesn't compare in complexity to IKE in any dimension!!). Also, we
shouldn't say "bootstrapping with IKEv2" if parts of that document are
meant to be a base document that other bootstrapping documents will
refer to.

Vidya


> 1. bootstrapping with IKEv2
> 2. bootstrapping with IKEv1
> 3. bootstrapping with the authentication option protocol
> 4. bootstrapping with DHCP
> 5. DHCP options for bootstrapping
> 6. bootstrapping problem statement draft
> 7. HA-AAAH interface goals document
> 8. RADIUS extensions to support NAS-AAA and HA-AAAH interfaces
> 9. Diameter extensions to support NAS-AAA and HA-AAAH interfaces
>
> > The topic of auth option protocol keeps coming up - this draft does
> > not provide bootstrapping solutions for the auth option protocol. That
> > work is yet to be done. In fact, I thought it wasn't even in the scope
> > of the design team to do that work. If we are talking about the auth
> > protocol, I think there is a lot more to discuss here than just DNS.
>
> the design team consensus was that it is out of scope. it
> will be an individual draft. it will be out soon.
>
> > Does this make sense to anyone?
>
> you havent actually explained what is not clear in the
> split bootstrapping document. we can clarify that.
>
> Vijay
>
>