Subject: [Gen-art] Gen-ART review of draft-huston-6to4-reverse-dns-07.txt

From: [email-masked]
Date: Tue, 17 Jul 2007 14:06:05 -0400

Geoff and Peter,

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-huston-6to4-reverse-dns-07.txt
Reviewer: David Black
Review Date: 17 July 2007
IESG Telechat date: 19 July 2007

Summary:
This draft is on the right track, but has open issues,
described in the review.

Comments:

The draft is in generally good shape, but I think the first
two potential issues noted in Section 4 Delegation Administration
need further attention:

   o  Clients inside a 6to4 site could alter the delegation details
      without the knowledge of the site administrator.  It is noted that
      this is intended for small-scale sites.  Where there are potential
      issues of unauthorized access to this delegation function the
      local site administrator could take appropriate access control
      measures.

Independent of intent, this will get used for larger scale sites.
Some form of prefix control exercisable by the site administrator
would be a good idea.  This may not be possible in all cases as
details of provider address allocation aren't always available
beyond the address block allocated by the registry, but the topic
needs some more thought.  Failing that, this is a v6 firewall
configuration issue, and the need for a firewall to support this
for administratively-controlled multi-address sites should be
called out in the Security Considerations section.

   o  IPv4 DHCP-based 6to4 sites, or any 6to4 site that uses
      dynamically-assigned external IPv4 interface addresses, could
      inherit nonsense reverse entries created by previous users of the
      dynamically assigned address.  In this case the client site could
      request delegation of the reverse zone as required.

This is an invitation to serious problems.  There ought to be a
way in the service to add a delegation expiration time when a
delegation is requested (e.g., a slightly smart piece of client
software could then put in the DHCP lease expiration time and
update the delegation when renewing the DHCP lease).  Inheriting
someone else's reverse DNS delegation because DHCP re-allocated
the IP address is not what I would consider expected behavior.

Nits:

idnits 2.04.12 didn't like some of the boilerplate

  Checking boilerplate required by RFC 3978 and 3979, updated by RFC
4748:
 
------------------------------------------------------------------------
----

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer,
instead
     of the newer disclaimer which includes the IETF Trust according to
RFC
     4748.

It also found a missing reference:

  Checking references for intended status: Informational
 
------------------------------------------------------------------------
----

  == Missing Reference: 'DNS' is mentioned on line 83, but not defined

Finally, idnits complained about IP addresses, but I think the address
usage in the draft is correct.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Jul 2007 09:45:18 +0200

On 2007-07-17 20:06, [email-masked] wrote:
...
> called out in the Security Considerations section.

It doesn't seem hard - it means that access to https://6to4.nro.net
has to be controlled, and there are many firewalls intrusive
enough to do that.

> the IP address is not what I would consider expected behavior.

No, but the combination of 6to4 in site mode with a single
dynamically assigned IPv4 address for a whole site seems a little
outside the parameters 6to4 was designed for. Remember that a 6to4
site also has to establish an ongoing relationship with a 6to4 relay
router. I don't think a model where all that has to be re-done
after a power cut or an ISP glitch is very plausible. Rather than
adding a lifetime mechanism, why need make this a SHOULD NOT?
(i.e. If reverse delegation is needed the site SHOULD NOT use
a non-fixed IPv4ADDR for 6to4.)

      Brian

---

From: [email-masked]
Date: Wed, 18 Jul 2007 09:01:23 -0400

While I'd like to see some consideration of prefix-based control,
a security considerations discussion of access limitation via an
IPv6 firewall is ok (but it *needs* text in the security
considerations section), and Brian's proposed "SHOULD NOT" for
the use of dynamic IPv4 addresses for 6to4 sites with reverse
DNS delegation is fine - that should be sufficient warning for
the surprise that a DHCP reassignment may cause inheritance of
someone else's remote DNS delegation (if this happens, it was
a consequence of ignoring the "SHOULD NOT").

Thanks,
--David