I would think that probably the l*vpn and IPsec specs might be
better precedents for telling receivers to drop packets not
from the expected source.
However, in those cases, the attacks are probably less likely
to occur (compared to the SSP case) and the amount of legitimate
traffic that'd arrive at the receiver accidentally is probably
also less that in the case with SSP. However, the relative
similarities are probably debatable.
So, there're some precedents, but of course no exact match and
hence we get to decide what we want to do (and after that the
broader IETF community get to say what they think about it).
In the end, I think "unprecedented" is really a caution
that we should sit back and think before we do whatever we
do, but should not represent a barrier to doing something new,
if that's what we think is needed.
The question of how strongly or weakly to describe the sender's
actions/wishes is IMO a separable one, so I don't think we should
be that caught up with the nitty-gritty of specific possible
precedents here.
S.
Jim Fenton wrote:
Dave Crocker wrote:
Jim Fenton wrote:
For those that are looking for a precedent, I'd like to point to RFC
2597 (Assured Forwarding PHB Group) as an example of where there is a
requirement on the recipient, in this case of a packet, to handle it in
a particular way. From Section 2: "Within an AF class, a DS node MUST
NOT forward an IP packet with smaller probability..." In any case, the
SSP draft is nowhere near as normative as this.
Jim,
1. We seem to be seeing inconsistency between whether SSP is
providing information about potential signers, versus whether it is
directing the behavior of receivers. ("providing guidance" is giving
direction.)
SSP is clearly providing information about the use of DKIM by domains.
It is also allowing those domains to express their preference about the
handling of mail that purports to come from them. The intent in this
latter regard is that domains are encouraged to do as requested by the
alleged originating domain, but that they are compliant with the
specification even if they choose not to do so.
2. RFC 2597 specifies actions relative to packets that are from the
specifier of the actions. SSP is about messages that the specifier
has not issued.
True, but I consider that just a characteristic of the different use
cases between SSP and Diffserv.
3. RFC 2597 has been at Proposed Standard for 8 years. Can you point
to some deployment discussion, so that we can see how broadly it has
been deployed and how well it works?
The point is that RFC 2597 is an IETF standards-track document, and an
example of a protocol which seeks to direct the behavior of receivers
(to use your terminology). It does this with considerably more forceful
language than the SSP draft currently uses.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html