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

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

> On 2007-07-17 20:06, Black_David@emc.com 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
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art