Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Michael Thomas]

On 10/17/2018 12:43 PM, Florian Weimer wrote:

* Laszlo Hanyecz:


On 2018-10-17 02:35, Michael Thomas wrote:

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

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[bzs]

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.)



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.



-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Florian Weimer]

* Laszlo Hanyecz:

> On 2018-10-17 02:35, Michael Thomas wrote:
>> 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.

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.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Florian Weimer]

* Scott Brim:

> On Tue, Oct 16, 2018, 22:37 Michael Thomas  wrote:
>
>> 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.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Laszlo Hanyecz]

On 2018-10-17 02:35, Michael Thomas wrote:
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.




Mike

On 10/16/2018 07:18 PM, b...@theworld.com wrote:

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.

RE: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Keith Medcalf]

>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.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Robert Brockway]

On Tue, 16 Oct 2018, Michael Thomas wrote:

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 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

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Michael Thomas]

On 10/16/2018 08:36 PM, Scott Brim wrote:



On Tue, Oct 16, 2018, 22:37 Michael Thomas > wrote:


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.




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

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Michael Thomas]

On 10/16/2018 08:20 PM, b...@theworld.com wrote:

On October 16, 2018 at 19:35 m...@mtcc.com (Michael Thomas) wrote:
  > 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.


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

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Scott Brim]

On Tue, Oct 16, 2018, 22:37 Michael Thomas  wrote:

> 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

>

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[bzs]

On October 16, 2018 at 19:35 m...@mtcc.com (Michael Thomas) wrote:
 > 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.

 > Mike
 > 
 > On 10/16/2018 07:18 PM, b...@theworld.com wrote:
 > > 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.
 > >

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Michael Thomas]

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

On 10/16/2018 07:18 PM, b...@theworld.com wrote:

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.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[bzs]

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.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Fred Baker]

On Oct 16, 2018, at 4:57 PM, Wayne Bouchard  wrote:
> 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...

Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
 Sun Tzu



signature.asc
Description: Message signed with OpenPGP

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Wayne Bouchard]

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...

On Tue, Oct 16, 2018 at 11:10:31AM -0700, Brian Kantor wrote:
> On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote:
> > 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

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Brian Kantor]

On Tue, Oct 16, 2018 at 02:01:48PM -0400, Daniel Corbe wrote:
> 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

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Daniel Corbe]

at 1:11 PM, Scott Weeks  wrote:



Wow, was it a table of folks new to network engineering?
If so, then schooling; if not, then clue bat...  :-)

scott


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.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Scott Weeks]

--- rjo...@centergate.com wrote:
From: Rodney Joffe 

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.



Wow, was it a table of folks new to network engineering?
If so, then schooling; if not, then clue bat...  :-)

scott

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Wayne Bouchard]

It is a fact that I learned much of what I initially knew about
internetworking by reading the protocols outlined in many of the
offical RFC documents. You couldn't pick one of these up without
seeing the name Postel at the top. I never met him but give due
deference and respect to his work and what it ultimately produced.

On Mon, Oct 15, 2018 at 10:00:33PM -0400, Rodney Joffe wrote:
> 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.
> 
> 
> 
> For those who care about the history of the Internet, and routing and 
> addressing. And protocols???
> 
> https://tools.ietf.org/html/rfc2468
> 
> Oct 16, 1998.

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Brian Kantor]

How soon we forget!

It was a telephone call to Jon (there was no email) in 1981 that
got my group the network that I still manage.  He was the editor
for the three RFCs that have my name on them.  I remember him as a
brilliant, kindly, efficient, helpful, and dedicated giant of the
early Internet.
- Brian


On Mon, Oct 15, 2018 at 10:00:33PM -0400, Rodney Joffe wrote:
> 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.
> 
> 
> 
> For those who care about the history of the Internet, and routing and 
> addressing. And protocols…
> 
> https://tools.ietf.org/html/rfc2468
> 
> Oct 16, 1998.

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Suzanne Woolf]

> On Oct 15, 2018, at 10:00 PM, Rodney Joffe  wrote:
> 
> 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.
> 
> 
> 
> For those who care about the history of the Internet, and routing and 
> addressing. And protocols…

And the principles  that make it “the Internet”, not just “some internets.”

> 
> https://tools.ietf.org/html/rfc2468
> 



Suzanne