ietf
[Top] [All Lists]

Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

2017-06-14 10:42:11
On 14.6.2017 00:03, Joe Touch wrote:
Hi, all,

...
  Title           : The Harmful Consequences of
        Postel's Maxim
https://tools.ietf.org/html/draft-thomson-postel-was-wrong-01

Before I dive into details, let me state I support this documents in its
current form.


I completely agree with John Klensin that a test suite defines the
protocol standard (warts and all).

However, I disagree with the characterization of the Postel Principle in
this doc, and strongly disagree with one of its key conclusions ("fail
noisily in response to...undefined inputs"). Failing in response to bad
inputs is fine, but "undefined" needs to be treated agnostically.

IMO, the Postel Principle is an admission of that sort of agnosticism -
if you don't know how the other end will react, act conservatively. If
you don't know what the other end intends, react conservatively. Both
are conservative actions - in one sense, you try not to trigger
unexpected behavior (when you send), and in another you try not to
create that unexpected behavior (when you receive).

That's the very definition of how unused bits need to be handled. Send
conservatively (use the known default value), but allow any value upon
receipt.

This very much depends on the the original specification.

If the spec says "send zeros, ignore on receipt" and marks this clearly
as an extension mechanism then it might be okay as long as the extension
mechanism is well defined.


On the other hand, accepting values/features/requests which are not
specified is asking for trouble, especially in long-term. Look at DNS
protocol, it is a mess.

- CNAME at apex? Some resolvers will accept it, some will not.
- Differing TTLs inside RRset during zone transfer? Some servers will
accept it and some not.
...


To sum it up, decision what is acceptable and what is unacceptable
should be in protocol developer's hands. Implementations should reject
and non-specified messages/things unless protocol explicitly says
otherwise. No more "ignore this for interoperability"!


With my DNS-software-develoepr hat on, I very clearly see value of
The New Design Principle in section 4.

Set it to stone! :-)


The principle does not setup the feedback cycle in Sec 2; a bug is a bug
and should be fixed, and accommodating alternate behaviors is the very
definition of "be generous in what you receive". "Being conservative in
what you send" doesn't mean "never send anything new" - it means do so
only deliberately.

-----
Failing noisily is, even when appropriate (e.g., on a known incorrect
input), an invitation for a DOS attack.

That behavior is nearly as bad as interpreting unexpected (but not
prohibited) behavior as an attack. Neither one serves a useful purpose
other than overreaction, which provides increased leverage for a real
DOS attack.

Sorry but I cannot agree. This very much depens on properies of "hard
fail" messages.

If "error messages" are short enough they will not create significantly
more problems than mere flood of random packets (which can be used for
DoS no matter what we). In fact, short predictible error message is even
better because it gives you ability to filter it somewhere.

Also, passing underspecified messages further in the pipeline is causing
problems on its own. (Imagine cases when proxy passes
malformed/underspecified messages to the backend because it can.)


So again, I really like this document. Thank you!

-- 
Petr Špaček  @  CZ.NIC