I would like to propose an ammendment to the SPF draft. Below I list
the proposed changes, discussion threads where the issue was debated,
and references to other RFCs that require minimum and/or maximum
processing limits.
While the referenced texts are irrelevant to SPF, I'd like to point
out that where necessary for reliability or other constraints, minimum
limits are very much in the scope of an RFC.
Some of the specs (RFC 2822, for instance) a requirement for a
maximum limit (line size in characters), and a recommendation for
the implemented maximum limit.
--------------- Proposed Draft Ammendments -----------------
I would like to propose that the SPF specification publish two
limits for the number of DNS queries performed.
A. All SPF checkers MUST resolve at least 10 DNS queries,
regardless of type and recursion. It is recommended that all
clients perform only 10 queries. PermError must be returned if
the first 10 queries do not yield an authoritative SPF policy.
B. All SPF checkers SHOULD resolve at most 20 DNS queries, in
order to protect themselves from DoS attacks. The quantity of
20 is to each site's discression, and MAY be set higher or
lower.
The two limits are different as some sites may elect to perform
more than 10 queries, in order to discover whether they are
subject to a DoS attack or not. If the SPF record does not
resolve after 40 (or the locally set limit), the receiving host
may take evasive action, such as (temporarily) black listing the
source IP address.
Regardless of the local setting as to what constitutes 'DoS', the
checker MUST return PermError even if the sender IP does resolve
favourably (pass) eventually.
This is not to say that the checker MTA MUST reject such
messages. It is entirely up to the local policy as to accept or
reject and SPF result codes.
--------------- Discussion of Ammendments -----------------
I believe that with technology such as the spfcompile program (an
optimizing SPF record compiler), there is little if any need to publish
SPF records more expensive than 10 queries. I have proposed several ways
that SPF record can be reduced in 'cost'. See spf-discuss archives:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200502/0410.html
("DSN Lookup limit?")
and
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200503/0168.html
("rr.com and SPF records")
--------------- Other RFCs imposing processing limits -----------------
Here are other examples of standards that require some sort of
minimum and/or maximum processing limit.
"2.1.1. Line Length Limits
There are two limits that thisstandard places on the number
of characters in a line. Each line of characters MUST be
no more than 998 characters, and SHOULD be no more than 78
characters, excluding the CRLF."
http://ohmi.org/qlz - RFC 2822 (rfc2822) - Internet Message Format
"4. Packet Formats
This section describes the packet formats used by SRP.
Packets can be sent over any point to point link layer
(e.g. SONET/SDH, ATM, point to point ETHERNET
connections). The maximum transfer unit (MTU) is 9216
octets. The minimum transfer unit for data packets is 55
octets. The maximum limit was designed to accommodate the
large IP MTUs of IP over AAL5. SRP also supports ATM
cells. ATM cells over SRP are 55 octets. The minimum limit
corresponds to ATM cells transported over SRP. The minimum
limit does not apply to control packets which may be
smaller."
http://ohmi.org/ql10 - RFC 2892 (rfc2892) - The Cisco SRP MAC Layer Protocol
"5.0 Mapping of Reservation QoS to ATM QoS
QoS negotiation in ST-2 (and ST-2 ) is done via a two-way
negotiation.
The origin proposes a QoS for the connection in a Flow
Specification (Flowspec) associated with the CONNECT
message. Most of the network-significant QoS parameters
in the Flowspec include both a minimum and a desired
value. Each ST agent along the path to the Target
validates its ability to provide the specified QoS (at least
the minimum value for each), updates certain values in the
Flowspec, and propagates the CONNECT until it reaches the
Target. The Target can either ACCEPT the Flowspec or
REFUSE it if it cannot meet at east the minimum QoS
requirements. Negotiation takes place as part of the
process in that the Target can specify changes to the desired
QoS values as long as the new value meets at least the
minimum requirements specified by the Origin system. In
addition, both the Target and the Origin can assess actual
network performance by reviewing the values that are
accumulated along the path."
http://ohmi.org/ql11 - RFC 1946 (rfc1946) - Native ATM Support for ST2
Regards,
Radu Hociung.
Radu Hociung wrote:
Gentlemen,
Thank you all for the insight you have provided.
I would like to formally propose the draft changes I have concluded as
necessary. What is the best way to do this?
Should I list them and get a community vote, then request the council's
attention?
Thank you,
Radu.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription, please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com