There was once a fairly common saying attributed to an early
networking pioneer that went something like, "be generous in what you
accept, and send only the stuff that should be sent." Does anyone
know what I'm talking about or who said it?
Be conservative in what you send, be liberal in what you accept
^http://en.wikipedia.org/wiki/Robustness_principle
http://en.wikipedia.org/wiki/Jon_Postel
Postel's Law
Perhaps his most famous legacy is from RFC 760, which includes a Robustness
Principle which is often labeled Postel's Law: "an implementation should be
conservative in its sending behavior, and liberal in its receiving
behavior" (reworded in RFC 1122 as "Be liberal in what you accept, and
conservative in what you send").
That was quick. 
Tom Paseka wrote:
Thanks all.
Jon Postel. I'm told that it is out of favor these days in protocol-land,
from a security standpoint if nothing else.
Mike
jon postel. Jon Postel - Wikipedia
Had he lived, email and netnews would have remained usable by mere
mortals and met the challenge of extreme growth and abuse. And ICANN,
and for that netsol, wouldn't have become the ugly morass they became.
Hell, even the IETF might have remained viable.
I have few heroes. He was one of them.
I feel required to point out that Postel's Law was sage advice for its time,
but should now be amended with "but assume that all input is hostile."
Low hanging fruit.
it is true that the risk profile has changed in the last 30 years.
his core belief in interconnecting things in an open way, enabling _anyone_ to create,build, and deploy
is the core of ISOCs “permission less innovation” thrust.
crypto/security folks are green with envy … it is somewhat “sour grapes” no?
I count my time working for him as one of the highlights of my life. In some respects, I still do…
/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
Indeed. That sentiment, and his memory, deserve a toast of MacAllan 18-year.
And they shall have it momentarily.
---rsk
Robustness is desirable from a security perspective. Failure to be liberal in what you accept and not being prepared to deal with malformed input leads to such wonders as the Microsoft bug that led to unexpected/malformed IP datagrams mishandled as "execute payload with system authority". Rather than sloppiness you could also attribute the error to malice -- that it was injected at the specific request of certain government agencies, perhaps under threat, perhaps with just a wink and a nod ...
The original principle had little thought toward security, and i was there for the row for which Eric's paper was almost certainly inspired by
(started it, actually). In the early days, a lot of people to took it as trying very hard to make sense of the broken -- far beyond rfc 2119's
musts and shoulds. A lot of people regret that now for a lot of reasons, including security. I still have mixed emotions about abandoning it.
Mike
"Being liberal in what you accept" and "being prepared to deal with
malformed input" are two different concepts. Back when I was involved
with protocol design on ARPAnet, what I was taught is that one has to be
able to handle *correctly* malformed input, and not yield astonishing
results.
This is not easy, particularly in assembler language. Blowing buffer
boundaries is just plain crap code.
As for malice, I've never seen that. Not checking buffer boundaries, in
my experience, is always stupidity or laziness. This is particular true
when someone threw together a proof of concept quickly, then didn't go
in and harden the code before releasing it to the world. (Some of that
was born during the "interop" meetings, where groups of coders would
assemble in a conference room and bang implementation together --
because it was done quickly, sometimes it was very sloppy.)
"No program should leave its sanity at the mercy of its input". PJ
Plauger, I think.
Regards, K.
I have no idea where I learned it but early in my career as a programmer and later as a manager of programmers I preached that "Above all else, programmer, your duty and responsibility is to protect your program from its input and its environment."
I may very well owe that to somebody smarter than me, but I think the idea solidified in my first paid programming job I got embroiled in a battle with programmers from another district in a huge batch system,
Their allegation was that bad input from a program I was responsible-for had caused a massive and expensive outage down-stream of us. (They had amassed a collection of file-dump snap-shots that they said showed that the records from us had errors in them--we were able to show that the file-dumps were fraudulent in and of themselves, but my main argument was an early rendition to the thing quoted above.)
Parenthetically, one of my favorite management quotations came out of that when the District Manager that my boss reported to (We called him "The Senator" behind his back) stood up at his desk and announced to us and to the folks from the other District that "we would have a solution to the problem by four PM today or there will be a series of Nine O'Clock Announcements tomorrow morning." (Big company, big inventory of thoroughly distasteful assignments for ambitious managers-on-the-climb.)
I hope it was more "permission-less innovation",
and not "permission, less innovation".
Ambiguously punctuated statements are
*so* open to misunderstandings. ^_^;
Matt
As with all terse summaries, the meaning of this is easy to distort.
In the unfortunately not-so-uncommon extreme, it is used to argue for
demanding acceptance of all manner of random cruft, essentially
translating into "the protocol requires you to support anything I send you."
This, of course, is not what Jon meant.
Rather, he noted the fact that protocol specifications invariably
contain some ambiguities which, equally invariably, get interpreted
differently by different, reasonable implementers.
Hence the stricture to meant to guide the sending of what an implementer
should consider to be the most conservative interpretations, and accept
the most liberal (different) interpretations.
d/