On 7/29/2016 7:52 AM, Theodore V Faber wrote: >> "Be liberal in what you accept, and conservative in what you send." >> > - RFC1122 >> > >> > RFC760 puts it into exactly the context I indiicated: >> > >> > The implementation of a protocol must be robust. Each >> > implementation must expect to interoperate with others created by >> > different individuals. While the goal of this specification is to >> > be explicit about the protocol there is the possibility of >> > differing interpretations. In general, an implementation should be >> > conservative in its sending behavior, and liberal in its receiving >> > behavior. >> > >> > I.e., applies when there is ambiguity. > That's a remarkable interpretation of the "In general," prefix that I > simply disagree with. (And for the record, I agree that the principle > applies when there's ambiguity; I also think it applies when there is > none - it applies "In general".) > > Beyond the textual analysis, I think restricting that idea in the > (IMHO narrow) context of resolving specification ambiguity sells it > short.
Can I then ask where you define the limit? What happens when you get an IP packet with protocol type = 18 (not 17), but it otherwise represents a well-formed UDP payload? My interpretation suggests the following: - If there is a valid behavior according to the spec, it MUST be accepted even it it does not represent the typical interpretation of the spec, or if is otherwise "unusual" (I've phrased this before as "a packet doesn't represent an attack merely because it's not what you expect"). - If a spec prohibits something, it MUST NOT be accepted (even if it "could" be) This covers all possible cases (spec is clear, spec is ambiguous). I include "spec says nothing" as "spec is ambiguous" IF there are multiple ways that the missing information could be interpreted *consistent with the explicit limits of the spec*. So I'm struggling to figure out an example where you think "in general" means what you think above (FWIW, I think it is intended to refer to the phrase - i.e., "put in a general way", not "this should be applied to all cases, not just ambiguities"). Can you give an example? Joe
