On 26-Oct-2006, at 13:34, Peter Koch wrote:
this message initiates a working group last call for
"Preventing Use of Recursive Nameservers in Reflector Attacks"
draft-ietf-dnsop-reflectors-are-evil-02.txt
to be published as a BCP. The WGLC will end Sat, 2006-11-11 23:59 UTC.
Please review and comment on this draft on this mailing list. The
chairs
will not forward the document to the AD unless at least five reviewers
have indicated their support (for both the draft and the intended
status).
Vendors' indication to follow (or not) the recommendation would be
appreciated.
I have just reviewed this version of the document, and I support its
publication as BCP as-is.
If another version is rolled for some reason, I would modify section
3, replacing the following text:
o Use TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to
authenticate the clients. This is a less error prone method,
which allows server operators to provide service to clients who
change IP address frequently (e.g. roaming clients). The current
drawback of this method is that very few stub resolver
implementations support TSIG or SIG(0) signing of outgoing
queries. The effective use of this method implies in most cases
running a local instance of a caching nameserver or forwarder
that
will be able to TSIG sign the queries and send them on to the
recursive nameserver of choice.
with something like this:
o Use TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to
authenticate the clients. This provides stronger authentication
of clients than access lists based on query source addresses,
and also facilitates access by authorised clients whose IP
addresses change unpredictably (e.g. roaming clients). Practical
drawbacks to this approach include the problem of key
distribution, the requirement for clients and servers to have
synchronised clocks, and the lack of deployed resolver
implementations which support either TSIG or SIG(0).
Specifically, I think that key distribution and time synchronisation
issues should be mentioned, the frequency of IP address changes is
not the real problem (it's the problem of predicting what addresses
will be used), and that the comment about running a local forwarder
is redundant given the comment about resolver implementations (and
has the slight aroma of implementation-specific advice).
However, as I mentioned above, I support -02 being published as-is
without these changes.
Please also include editorial comments; there will be a -03 anyway
since
the current draft does not yet have an IANA considerations section.
I may be procedurally out-of-touch, but in a recent draft I was
involved in editing that was also aimed at BCP and which was subject
to a lot of IESG scrutiny, I was repeatedly criticised for including
an "IANA Considerations" section which included the single sentence
"This document requires no actions of the IANA".
I was told that if no actions are required, no IANA Considerations
section is necessary.
Joe
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
