On 2007-07-17 20:06, [EMAIL PROTECTED] wrote:
...
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.
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.
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.
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
