At NANOG two weeks ago, we had an interesting discussion at
one of the lunch tables. One of the subjects we discussed
was the original IANA, and RFC Editor, Jon Postel.
Seven of the ten people at the table had never heard of him.
Maybe these days it no longer matters who he was, and what
he meant to where we are today.
The one thing I remember about Postel, other than the fact that he had his fingers in a lot of DNS pies, is be liberal about what you accept, be conservative about what you send. It’s a notion that creates undo burden on the implementor, because it places the expectation on the that you need to account for every conceivable ambiguous corner case and that’s not always the best approach when implementing a standard; and it mostly arises from the lack of adherence to the second part of that statement.
I think that his aphorism is simply a recognition that NO standard
can cover all cases that might arise when dealing with complex
matters, no matter how much thought went into it. People are
fallible, and the standards they write are inevitably flawed in
some way, so a realistic implementor has to allow some slack or be
continually engaged in finger-pointing when something doesn't work.
- Brian
Well, simply put, the idea is that you should be able to compensate
for a certain amount of deviation from accepted usage as long as its
still within what the protocol allows (or can be read to allow) but
that you yourself should act with a fairly strict interpretation. In
others, don't be the one *causing* the problems...
Indeed. To give a TCP example, the opening exchange is theoretically SYN, SYN ACK, ACK. A common case is that it is SYN, SYN ACK, data, either because the ACK got lost, or because someone cut a corner. The issue is to note that the SYN might have been duplicated in flight, and the receiver might therefore have the appearance of two sessions. Which one? The ACK (or data segment) - any segment within the sessions - clarifies that. So, if there is a minor protocol violation but the intent it clear, follow the intent.
The alternative version of the Robustness Principle: "S**t happens; deal with it."
Says someone who has implemented such things...
What it's trying to say is that you have control over your own code
but not others', in general.
So make your own code (etc) robust and forgiving since you can't edit
others' code to conform to your own understanding of what they should
be sending you.
I suppose that pre-dates github but nonetheless much of the code which
generates bits flung at you is proprietary and otherwise out of your
control but what you can control is your code's reaction to it.
And of course the bits you generate which should try to make
conservative assumptions about what they might accept and interpret as
you expect.
For example just because they sent you a seemingly malformed HTTP
request, and given that 4xx is for error codes, doesn't mean you
should return "420 You must be high!" and expect to be understood.
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Mike
I believe that the IETF party line these days is that Postel was wrong
> on this point. Security is one consideration, but there are others.
Security fits into all this, being liberal in what you accept doesn't
mean you do whatever they ask.
Quite the contrary it means make sure your code doesn't roll over dead
or misbehaving just because you received an unexpected input.
Not doing that was exactly what allowed for example buffer overflow
attacks.
The target software wasn't liberal in what it accepts which is to say
anticipated that someone might send them a very long string and should
either buffer it correctly or truncate it. They assumed they'd only be
sent reasonably short strings.
I believe that the IETF party line these days is that Postel was wrong
on this point. Security is one consideration, but there are others.Mike
I saw just a small swing of the pendulum toward the center, a nuanced meaning for “liberal”. The adage wasn’t tossed out. Operationally it can’t be.
Scott
That's not the same thing. That's never acceptable. Trying to educe what a sender really meant is a good way to create exploitable spaghetti though. But don't take my word for it, reach out to people who pay more attention to such things than me.
Mike
All of the security types were pretty unanimous when this came up during all of the dkim stuff i worked on. I was a fan, and I got schooled. Mike
Postel's Law is about robustness of network communications. As such it can *increase* network security by improving availability [CIA triad] although it could potentially reduce confidentiality and integrity in some circumstances. Whether or not Postel's Law improves or degrades security would need to be assessed on a case by case basis.
Cheers,
Rob
For example just because they sent you a seemingly malformed HTTP
request, and given that 4xx is for error codes, doesn't mean you
should return "420 You must be high!" and expect to be understood.
Actually, you can, and the sender of the request MUST understand.
The relevant part of the applicable RFC says:
HTTP status codes are extensible. HTTP clients are not required to
understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code.
I believe that the IETF party line these days is that Postel was wrong on this point. Security is one consideration, but there are others.
Postel's maxim also allowed extensibility. If our network code rejects (or crashes) on things we don't currently understand and use, it ensures that they can't be used by apps that come along later either. The attitude of rejecting everything in the name of security is what has forced app developers to tunnel APIs and everything else inside HTTP/DNS.
* Scott Brim:
I believe that the IETF party line these days is that Postel was wrong
on this point. Security is one consideration, but there are others.Mike
I saw just a small swing of the pendulum toward the center, a nuanced
meaning for "liberal". The adage wasn't tossed out. Operationally it can't
be.
I think DMARC, as it is deployed right now, pretty much killed the
“liberal” part for many people. It's sender policy, but it's
necessarily enforced at the recipient end, but many recipients aren't
given a choice to opt out when it is technically the wrong thing to
do. You can switch email providers, but as the IETF never really
designed for email address portability, that's a theoretical option
only for many.
* Laszlo Hanyecz:
I'm probably going to regret posting this but I think most of this
dispute regarding Jon Postel's advice revolves around how the words
"liberal" and "conservative" have changed over 20 years.
Liberal used to mean adaptable, open-minded, and conservative used to
mean cautious and hewing close to the rules (and I mean none of that
disparagingly.)
<IGNORE>
I won't begin to characterize how these words have changed but, um,
ach, phffft, AGHHH!...they didn't mean calling your personal
prostitute a "horseface" or arguing that point via the public
internet.
</IGNORE>
* Laszlo Hanyecz:
I believe that the IETF party line these days is that Postel was wrong
on this point. Security is one consideration, but there are others.Postel's maxim also allowed extensibility. If our network code rejects
(or crashes) on things we don't currently understand and use, it ensures
that they can't be used by apps that come along later either. The
attitude of rejecting everything in the name of security is what has
forced app developers to tunnel APIs and everything else inside HTTP/DNS.
Let's be clear: crashing is a software bug. It has nothing to do with Postel.
On the extensibility part, that is for the protocol itself to define, and it should be explicit. If the protocol says to reject, then you must reject. I'm not sure if extensibility one of the global protocol check offs, but it certainly should be part of any stander.
To be fair, a lot of these components that make extending protocols
hard are both receivers and senders. If they are asked to forward
garbage, then something has to give.
Yes, the protocol should tell you what to do. If it doesn't, its deficient.
Mike