Re: [dnsop] WGLC for draft-huston-6to4-reverse-dns-04.txt

[Pekka Savola <[e-mail]>]

On Thu, 9 Mar 2006, Peter Koch wrote:
> Please send comments and statements of support or objection to the
> WG mailing list. We'd like to ask for at least five substantive reviews.

I support the spec.

I have three bigger issues with the doc, described below but easily 
fixable, as well as a couple of editorial comments.

1) "password-based authentication deployed but not documented"
2) "is it OK to have all the DNS servers at the 6to4 site?"
3) "ability for upstream to block 6to4 delegations is inappropriate"

In addition, there is more of a meta-question raised by Mark Andrews. 
In my opinion, the real issue is whether the whether this solves the 
problem for sufficiently large/interesting subset of 6to4 users or 
whether we need something else instead or in addition.

substantial
-----------

1) "password-based authentication deployed but not documented"

    The delegation system is proposed to be self-driven by clients
    residing within 6to4 networks.  The server's delegation function is
    proposed to be accessible only by clients using 6to4 IPv6 source
    addresses, and the only delegation that can be managed is that
    corresponding to the /48 prefix of the IPv6 source address of the
    client.

==> the latter sentence does not match the service as implemented today. 
It's possible to access the delegation function by optional password
authentication. I'd suggest one of the following, with personal bias towards
either of the first two:

  a) describe the auth service as well (I'd like security folks review it),
  b) remove the auth service from the implementation, or
  c) massage the text a bit so that it doesn't imply normativeness ("..
additional authentication methods may be used as necessary..")

2) "is it OK to have all the DNS servers at the 6to4 site?"

  The delegation servers are
    checked by the delegation manager to ensure that they are responding,
    that they are configured consistently and are authoritative for the
    delegated domain.

(also a bit later..)

==> is it OK that all the auth servers are under the same 6to4 prefix (but
different IPs)?  This seems something that should probably be checked and
prohibited, as if one server would go down, the other would also likely do
so...

3) "ability for upstream to block 6to4 delegations is inappropriate"

    There may be circumstances with an IPv4 address controller wishes to
    "block" the ability for "children" to use this 6to4 scheme.
    Scenarios that would motivate this concern would include situations
    when the IPv4 provider is also offering an IPv6 service, and native
    IPv6 should be deployed instead of 6to4.  In such circumstances the
    2002 zone operator should allow for such a delegation blocking
    function upon application to the delegation zone operator.

==> I believe this doesn't make sense on various levels.  First of all, the
operators shouldn't be in the business of specifying what their users can or
can't do: if they wish to block 6to4, they can just put in ACL to block
proto-41 (or appropriate portions of it) -- there is nothing needed in the
delegation system to provide additional capabilities for this. 
Additionally, it's perfectly valid scenario to run 6to4 as an optimization
mechanism (see RFC3956 for details), on the side with native addressing. 
This could block reverse DNS delegations in such cases.

In short, the whole paragraph should be removed as unnecessary and even
harmful.



editorial
---------

    domain.  The client is primarily authenticated by it's source address

==> s/it's/its/

    This address structure allows any site that is connected to the IPv4
    Internet the ability to use IPv6 via automatically created IPv6 over
    IPv4 tunnels.

==> "any site" is not accurate as the site is required to have a public v4
address; minor reword..

    The zone files containing the end site delegations are proposed to be
    operated with a TTL (configured to be a time value in the scale of
    hours rather than days or weeks), and updates from delegation
    requests are to be made using incremental DNS updates [RFC2136].

==> it may be worth spelling out that you're talking about DNS updates
between the web interface and authoritative servers; the clients don't
perform any DNS updates.

    o  IPv4 DHCP-based 6to4 sites could inherit nonsense reverse entries
       created by previous users of the DHCP address.  In this case the
       client site could request delegation of the reverse zone as
       required.

==> it may be worth adding a forward pointer to the periodic cleanup check,
which should mitigate this problem a bit.

7.  References

==> rename this to Informative References and maybe put RFC3056 under
normative references.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html