I do support this document being published as BCP.
A couple of minor comments:
Section 4's reference to BCP 84, in part, creates a false sense of
useful action on part of the operator, IMO (in addition, there's a
typo; s/were/where/).
In situations were more complex network setups are in place,
"Ingress
Filtering for Multihomed Network" [BCP84] maybe a useful additional
reference.
Perhaps clarifying that Strict and Feasible methods do provide some
protection, but Loose provides zero protection from reflective attacks,
as they really only require that the target "exist" - they usually do.
You might stress that the "IP based authentication" recommendation
is pretty much useless -- unless you implement policy at all ingress
points (including from peers/providers). In particular, if you don't
filter
you're permitted-query-address-sources coming from "the Internet" or
peers, then spoofing can still be used to launch reflective attacks:
o IP based authentication. Use the IP address of the sending host
and filter them through and Access Control List (ACL) to service
only the intended clients.
Also, I'm not sure I'd call this "authentication", perhaps IP-based
access policy" is more appropriate?
Some more details and recommendations on SOHOish ORNS
might be useful for implementers.
As for the TSIG or SIG(0) recommendation, I'm not sure what
the numbers are for client support today, but I suspect it's at
best an negligible sample.
I also agree with Paul Hoffman's comments on some reasons
for ORNSs. There are many reasons why I may want to use a
specific resolver consistently, to include those outlined by
Paul/John.
-danny
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf