Mukund Sivaraman wrote: > Hi Robert > > On Mon, Sep 28, 2015 at 01:30:28PM -0400, Robert Edmonds wrote: > > 16 bits is an awful lot of space for the ALGORITHM field. Compare to > > the DNSSEC algorithm number field, which is only 8 bits. > > Do you suggest changing it to 8 bits too?
If you keep an algorithm field, yes, I suggest changing it to 8 bits. It seems unlikely more than one or two algorithms would ever be implemented. Is algorithm agility really needed, though, given that there are ~65000 unused EDNS0 option codes? I am also curious why a cryptographic hash function (SHA-1) is needed for this. Is a fast non-cryptographic checksum not suitable (e.g., CRC-32C, which can be computed in hardware on x86 CPUs)? Also, there is a long deployment tail for new EDNS options. If it's urgent to deploy a countermeasure against off-path fragment spoofing, why not something like Unbound's "referral path hardening", or advertising a smaller EDNS buffer size which is much less likely to result in fragmentation? (E.g., I believe OpenDNS advertises a ~1.4 Kbyte EDNS buffer size.) Those countermeasures can be deployed unilaterally by the resolver, and on a shorter time scale than a new EDNS option. -- Robert Edmonds _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
